Exploring 3 Different Types of IT Documentation

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. Some people add procedures with policies and 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 well would everyone else who's not as invested in security?

The 3 Major Documentation Types

Moving along, I've noticed 3 major types of IT documentation:

Policies

Policies are high-level guidelines. Guidelines are mere suggestions and are 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 regarding technology. They should also 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, laws, and regulations. The process for approving standards and guidelines is generally less involved than that of full-blown policies. As a result, there are fewer stakeholders, and if there's an approval process, it's much easier to go through. Technical specifications, software, hardware preferences, and other information may be included in the standards.

For example, your standard for an operating system could be as simple as the current, supported version of Windows.

Having standards published along with or supplemental to policies is pretty common.

Another example is an organization's Acceptable Use Policy (AUP), which 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 policies' approval process.

The goal of this style of documentation is to get those steps out of your department's collective heads and on paper. You want specific steps 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?

3 Types of Questions to Answer for Writing Proper Documentation

Seeing the types of documentation and producing them are two different areas.

There's a trend in bringing in outside personnel to assist with documentation efforts. IT departments know they lack proper documentation and lack the time to concentrate efforts on documenting their systems.

So it's understandable to want to hire specialists who either know the systems or specialize in an area like disaster recovery and can deliver quick, specific knowledge for the premium they charge. This could get a little pricey, but why not outsource this task to a professional and keep your IT team doing what they do best?

Makes sense, right? But what about those who are hired or contracted to document systems they've never seen before?

Both the IT department and the new hire needs to understand there has to be a high level of information sharing. How can you expect to secure computer systems when you don't have all of the information at your fingertips? You get this information by capturing details that either haven't been thought of in a while or have become second nature by experienced IT department personnel.

Here are 3 sample topics with possible questions to have answered in order to create helpful documentation:

Network Information

• What are the device/server names?
• What is the make and model for each device/server?
• WhatOS / firmware version are these servers running?
• Do we have a list of settings for each network infrastructure device?
• What are the assigned IPs (or range) for each network device?
• Who has access to network infrastructure devices?
• Who has access to private or encrypted connections?
• What ports are required to be open? What are the services that communicate via these ports and what are they used for?
  • HTTP, SQL, etc.
• Are there any required file shares? Which user groups are authenticated to access these shares?

Backup and Retention Information

• When and how often are backups scheduled?
• Are backups automated or manual? Why?
• How long do backups take for both file and virtual?
• How long do restores take for both file and virtual?
• Where are the backups stored?
• Is there a redundant offsite backup?
• Do you let end users know what is and what is not backed up?
• Is there a designated server, either physical or virtual, where you can test restores?
• When was the last time you tested a restore from backup?
• What reporting features do you use? Are they reliable?
• What is the total data of the company?
• What procedures are in place for systems not requiring a backup?
• Do you have a disaster recovery plan made?
• What is your RPO and your RTO?
• How far along in the life of the backup system are you? If you're already at the end of life for this system, are you already looking for another backup solution?
• What are the qualities that are important in a backup solution?
• What vendors are you working with? What is their contact information for support?

Software Information

• What software is mandatory (business critical or daily driver)?
• What software is required for a particular job or business unit?
• What software is completely optional?
• Who determines which software is used in each of the above categories?
• How is software customized, configured, or installed?
• How is software distributed?
• How often do software requirements change?
• How do you upgrade existing software?
• How is new software tested or evaluated?

Another way to separate software standards is by deployment. Consider the following setup of computers within your organization:

1. A standardized configuration of the operating system (basic drivers, network shares, Windows security settings).
2. A minimum number of installed corporate-standard applications (MS Office, Adobe Acrobat, etc.).
3. Additional software needed to perform job duties (Adobe Dreamweaver, Corel Paint Shop Pro, etc.).
4. The ability or inability to allow additional applications and features. Additional software installations could either be only on an approval basis, frowned upon, or forbidden.
5. Procedures to obtain permissions, access, and/or procurement of additional software or licenses.

Once the answers needed to develop software standards are determined, you need to make a conscious decision on how to describe your current software. Depending on your organization it may not be wise to disclose your exact version of applications and operating systems. This could be for security reasons, but it’s mostly due to updating your software standards as your organization adopts new software. For some organizations, it’s as simple as the release of new software. For others, upgrading software may be as rare as an eclipse.

For example, we’ll use the Windows operating system. Think of the distinction of Windows 7 Professional x64 versus a supported version of Windows x64. The level of detail will all depend on how often your software changes and of course, how detailed you want the software standards document to be.

Source
Idea modeled from the old software standards found on page Defining Software Standards at Microsoft TechNet.

Are your software standards generic or specific? Why?

Conclusion

The questions would depend upon the system environment but the main goal is to have enough information to quickly solve a problem. Otherwise, you may be fumbling around and saying things like "what was that trick we had to do last year when we patched this server?"

At this point, you may realize it's probably better off to document these information systems in-house, with people who use them every day. If you did make this realization, hopefully, it wasn't by doing it the hard way. The in-house specialists, analysts, and coordinators can take a page from their technician friends at the helpdesk by doing the following:

1. If a particular subject, system, etc. is not documented, document it as you're working on it or immediately after.
2. If a document contains wrong or outdated information, update it as you're working on a system or immediately after.
3. Write the document in a way that any IT professional can carry out the tasks during an emergency.

Are you comfortable with your system documentation? If you're lacking proper documentation, get started today!