Awards
- Community Pick
- Experts Exchange Approved
In an early article I gave some Tips for Writing Information Security Policies. I’d like to continue with this topic and provide a framework 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 is to create a separate document for policy, standard and procedure for each topic. Let me explain by using the example “Password Policy“.
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 is to create a separate document for policy, standard and procedure for each topic. Let me explain by using the example “Password Policy“.
So at the top of the pyramid there is Policy. This is the overall policy 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 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, that's true; 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 big document that document will probably include policies, standards, and maybe some procedures. As I said earlier, policies shouldn’t change very 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 a while, depending on 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 used this framework many times to help develop IT Policies, Standards and Procedures for Corporate IT department with great success. In my next article I will talk about Document Management. If you have comments or questions please post a comment.
Reposted from my personal blog http:\\www.thesecuritypub.
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 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, that's true; 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 big document that document will probably include policies, standards, and maybe some procedures. As I said earlier, policies shouldn’t change very 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 a while, depending on 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 used this framework many times to help develop IT Policies, Standards and Procedures for Corporate IT department with great success. In my next article I will talk about Document Management. If you have comments or questions please post a comment.
Reposted from my personal blog http:\\www.thesecuritypub.
by: seaninman on 2010-07-14 at 18:04:11ID: 17018