In an early post I gave some Tips for Writing Information Security Policies. I’d like to continue with this topic and provide a frame work that will hopefully make it easier for you to develop all policies, standards & procedures needed for an Information Security Program.

There are many different ways to approach policy documentation. What I have found to be the most effective for users, auditors & management to read and understand what is being written, is to create a separate policy, standard and procedure for each topic. Let me explain by using the example “Password Policy“.

The first document is the Policy. These are the overall statements that gives the “marching orders” to your users. Policies should not change that often. Using our example the password policy a policy statement might be:

• Passwords must be complex.

Next there is Standards. This document will list out the technical details to support the policy. Using our example, the standards may be:

• Passwords must be 8 characters long & contain upper case, lower case, number, symbol.

Following standards is Procedures. Your procedures are basically “How To’s“, creating these documents could be beneficial in cutting down support calls on how to do certain tasks. Again using our example of the password policy, one procedure document could be:

• Changing Passwords

Finally there is what I call Supporting Documentation. Basically what these documents are forms or checklists. Supporting documentation may not be needed for each topic covered, but could be helpful for users that are required to follow these documents.

Okay, you’re probably thinking WOW this guy just quadrupled my documentation! Well it does, however once this project is underway it really does make sense and enables you to manage documentation more effectively.

If you document everything in one document that document will probably include policies, standards, and maybe some procedures. As I said earlier policies shouldn’t change that often, however standards can change fairly regularly. So if you change one item in your large document that contains all IT Policies & Standards, you now have to get that entire document approved again (could take awhile, depending who all first approved the document).

However, if you had one standards document for that specific topic, the approver would only need to review and approve that one item, not the policy or other policies and standards that doesn’t even apply to what was modified.

Using our example you might have the following for Passwords.

• Password Policy – CIO or Sr. Management approval depending on the organization
• Password Standards - Sr. Management approval, depending on organization
• Password Procedures - Department Manager, or Team Lead approval, depending on organization

I have successfully used this documentation framework many times to help develop IT Policies, Standards and Procedures for Corporate IT department with great success. In my next post on regarding IT Documentation (Policies) I will talk about Document Management. If you have comments or questions please post a comment.