If a policy is wrongheaded feckless and corrupt I take it personally and consider it a moral obligation to sound off and not shut up until it’s fixed.
David Hackworth
Most people find the topic of IT Security Policies to be about as exciting as a term paper on IT Security Policies. Most CIO’s get them written as fast as possible and move on to “more important” things. The reality is that without the policies, staff either have to guess about what’s expected or they learn ad-hoc processes and procedures from their peers. Even worse, if policies are written in such a way that it is not possible to follow them, he staff will ignore them altogether. Robust policies that can be followed decrease risk to the organization.
Never forget the purpose of the policy
Simply put, any given policy should define what is expected of the person reading the policy. That means that the person reading it must understand it. We find too many instances where a policy was written with a non-technical person in mind but gets loaded with tons of technical jargon. That simple act violates the ability for the policy to be successful. Save the jargon for procedures rather than policies.
Longer is not better
We frequently read policies that are 8, 10, even 15 pages long. How long should the policy be? Simple is always best. It only has to be as long as required to give the reader what they need to make good decisions. You don’t get special points for making the policy longer. There is no need to justify your education or training with long convoluted policies. It is impossible to describe every single situation where a given policy may need to be applied. Resist the temptation to make your policy unnecessarily long.
For example, consider a common data destruction policy. What should it include? (1) The scope of the policy may simply be all systems, disk drives, or devices capable of storing information at the organization. (2) The reason for the policy is simply to ensure sensitive data cannot be recovered after a device has been disposed of. (3) Possibly a procedure for removing the device from inventory, storing in a secure area, instructions for securely wiping the disk or physically destroying it. (4) Consequences for not following the policy.
In short, that policy could be a single page in length. Is that too short? Not if it conveys what is expected from each person expected to adhere to the policy.
Organizing your policies
There may be many IT Security related policies in an organization. If not well managed, those policies could overlap or even conflict with one another. A simple way to ensure that doesn’t happen is to make each policy simple in scope and simple to read. Have a single primary policy that provides a synopsis of each policy and where to find them. Annually, start your review with the primary security policy, then review each policy referenced. All IT personnel would get a copy of the single primary policy that includes information relevant to everyone with references all the other more scoped policies. Then, based on their subject matter expertise, each person could read a more in depth policy covering topics that directly impacts them and would know where to find it.
Impossible policies are useless and a risk to audits
There are times when we come across well crafted and well thought out polices where the organization simply doesn’t have the resources to follow the policy as written. An example we frequently see are “Change Control” policies. Often they reference a CAB, approvers, testing environments, and the like, but the organization is a 2-person IT shop with a test environment that simply doesn’t match production. The policy sounds good but impossible to achieve with the resources at hand. Each policy should reflect the real-world state of affairs. Otherwise, it serves no useful purpose other than to look good on paper. Any further examination by an auditor or customer would reveal the policy is not capable of being followed resulting in potential lost business or audit exceptions.
Use policies to the advantage of your organization and staff
Your IT Security policies should exist only to reduce risk to the organization and staff members. If they don’t match the real day-to-day reality, then they are just paper being pushed and a waste of time to maintain. Never implement policies that impede productivity of staff without a corresponding decrease in organizational risk. Otherwise, your staff will not follow the policy making it about as useful as an origami tiger. A decoration.