Although there are clear boundaries of document types in theory, what a type of document actually is and should be can vary depending on who you talk to. There are some people who add procedures in with policies and add standards to procedures. These types of people want to make available the least number of documents to read as possible. If this is your goal, you may end up with a document titled something like IT Server Procedure Policy Manual that’s the size of a small phonebook.
Surely, no one wants to read that right? Maybe you do and don’t call you Shirley?
Hyperbole aside, I’ve actually come across many people who have combined their entire security program into one document. In one particular case, this information security officer I met inherited an information security program to maintain that’s over 60 pages long. This professional admitted having difficulty drudging through the program. If this person has difficulty reading through it, how does everyone else fair that’s not as invested in security?
Moving along, I’ve noticed 3 major types of IT documentation:
Table of Contents
Policies
Policies are high-level guidelines. Guidelines by themselves are mere suggestions and not mandatory. If an organization has an approval process, the pending policies could be referred to as guidelines. Some educational institutions perform this practice.
Policies are generally thought of as a compliance floor instead of a ceiling. For example, the FBI CSP (CJIS Security Policy) describes itself as a minimum standard of security to be followed. Policies need to be concise, cover topics at a high level, and be non-restrictive in regards to technology. Policies should be open enough to allow different types of technology to be used. A standard, on the other hand, can be more specific.
Standards
Standards are compliance requirements for policies, as well as laws and regulations. The process for approving standards and guidelines generally aren’t as involved as full-blown policies. As a result, there aren’t as many stakeholders and if there’s an approval process, it’s much easier to go through. Technical specifications may be included in standards, as well as software and hardware preferences.
For example, your standard for an operating system could be as simple as the current, supported version of Windows.
It’s pretty common to have standards published along with or supplemental to policies.
Another example, think of an organization’s Acceptable Use Policy (AUP) that references the organization’s software standards document. The link between the 2 documents is essentially a list of approved software for doing business. This could also tie into a software blacklist or whitelist but it doesn’t necessarily have to.
Procedures
The ever important procedures are how to documents. They are specific and step-by-step. Some policy writers include a procedure section in their main policy, which is great until you need to add or remove a step in the procedure. Procedures should be able to change as needed and not be stuck in the approval process policies go through.
The goal for this style of documentation is to get those steps out of your department’s collective heads and on paper. You want specific steps to be available when working knowledge is either forgotten or when key personnel is not available. This is especially helpful in emergency situations.
I’m interested in your thoughts. Do these overviews match your understanding or practice of IT documentation? How do you specify your documentation types?
