Posted on by

Information Security Policies and Procedures Part 7

Information Security Policies and Procedures

This is part of an ongoing series on documentation development.

Please be sure to read the previous posts in this series. Part 1 , Part 2 , Part 3 , Part 4 , Part 5, Part 6

Do words matter? Of course they do. There are few places where this statement is as true as in documentation. When developing policies and procedures, we must be very clear about the rules. Must and shall mean, as the name implies, that the action is not optional. May means that the action is allowed, but not required. This is an essential difference. Take for instance: sharing passwords. A policy statement should be in place saying something like “users shall not disclose passwords to others.” This clearly dictates that passwords must not be disclosed. May, on the other hand, allows a bit more flexibility. For example, take the statement “users may bring in their own monitors.” In this case, users are allowed, but not required, to use their own monitors.

Procedures have many of the same rules. Again, must and shall are for required actions, while may is for optional actions. Precision of language becomes especially important in procedures. “I walked into the yard carrying a small dog barking.” Who is barking, you or the dog? For the nitty gritty technical steps, you should either develop an internal style guide, or use something such as the Microsoft Manual of Style for Technical Publications. The MLA, AP, and Chicago style manuals are great, but the Microsoft Manual of Style defines when to use terms like click, select, highlight, choose, etc. This is very important in a technical environment. Want a great test of your procedures? Take a vacation. If procedures are not clear, you will be receiving phone calls asking for clarification. In my opinion, it is better to test procedures prior to when they are needed, especially those that are rarely used. Have someone who is not familiar with the procedure attempt to follow it using only the documentation, and then have them provide feedback.

In our next installment, we will get more detailed on the concept of language.

 

Leave a Comment...

Your email address will not be published. Required fields are marked *


*