How to Write the Best IT Security Policies

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.

More Posts

Getting Started with Vanta’s Private Integrations

“Vanta’s Private Integrations are poised to be a game changer! Finally, all organizations can integrate Vanta’s automated compliance platform with any application in their portfolio regardless of whether it’s hosted in a private cloud, custom developed, or even a SaaS app that is restricted by source IP or doesn’t have

Vanta Private Integrations – Integrating Active Directory (PowerShell)

“With PowerShell being supported on Windows, Linux, Azure Functions, AWS Lambdas, PowerApps. and elsewhere, it is our favorite scripting runtime. It is very easy to integrate with Vanta Private Integrations.“ Eric Shoemaker – Advisory CISO – Genius GRC Private integrations – An Overview Before you read this post, you should

Improving the Audit Experience: Producing Effective Evidence

The best way to make an audit a positive experience for all individuals involved is for the auditee organization to make it as easy as possible for the auditor to draw a positive conclusion from the evidence being presented. This is best accomplished by providing high quality evidence for each