Have you ever been tasked with writing a security policy and feel completely lost as to where to start?

This feeling is a normal one that we have seen time and time again in our respective consulting careers while doing security assessments. At some point, a member of the security team is tasked with writing a policy for the organization in order to fill a compliance need, but aren’t given any further guidance or framework to the content and format. Uncertain of how to fully complete the policy, one usually starts with Google looking for templates and examples of policy from other organizations they can borrow from. This results in a pasted together collage of policies and standards which may meet compliance requirements, but aren’t integrated with daily practices.

While this scenario is all too common, it doesn’t have to be. Given a little time and care, it is possible to create a set of policy and procedural documents without a lot of headache.

An Overview of Document Types

Before we get into the meat of what should go into a security policy document, let’s differentiate between policies, procedures, standards, and guidelines. Each one of these items can be used to satisfy a host of documentation requirements, but there is commonly some confusion as to what information should be going into each document type.

At a high level:

• Policy: A policy is a high-level document that should be easy to read and understood by every member of the organization since it states things people are and are not allowed to do.
• Standard: A standard is a quantifiable description of what the organization feels is an acceptable level of attainment in order to meet their policy objectives.
• Procedure: A procedure is a lower-level document that should include steps on how to complete a task (access provisioning and de-provisioning, how alert reviews are to be performed, etc.).
• Guideline: A guideline is a recommended step that can be taken and failure to follow the guideline does not necessarily constitute a violation of a procedure, standard, or policy.

Writing Your First Policy

We aren’t quite ready to put pen to paper yet, as we have a little more to consider first. Something we have seen repeatedly when discussing documentation is their sole existence is to satisfy audit requirements in addition to providing management coverage when something goes awry. This commonly results in a low percentage of users whom have actually read the document with little to no initial buy-in of executive management.

Therefore, we highly recommend that you keep the following in mind as you set out to write your policies:

• Culture of the Organization and Teams: Although you may be wondering what culture has to do with writing policies, it makes sense if you think about it for a moment. If you are working in a start-up, why would you copy policy statements from a bank or university? There is more or less rigidity depending on the type of organization you work for, the industry it operates in, and the people who make up the company. Keeping those things in mind should make it easier to get buy-in from executive management.
• Legal and Regulatory Compliance Requirements: Even though something may not ring true to the culture of your organization or was specifically called out by executive management when you were discussing their goals and objectives for the security program, it is important to consider what you must put in your policy from a legal perspective as well as what compliance frameworks you adhere to call for.
• Sensibility and Actionability of the Mandates: When writing your security program documents, you will want to keep in mind the people who will have to adhere to what you’re writing. It can be difficult for smaller teams to perform things in accordance to a documented procedure that was written originally for a team twice their size or more. Additionally, you should ideally consult the teams you are writing procedural documents for in order to make sure that it makes sense for them as well as whether or not they can do what is being described in the document.
• Human Readable: Ideally, your policy documents should be in a language that can easily be understood by most, if not all, of your employees. Otherwise, how can you expect them to read and agree to it?

Format of a Policy

As you start looking at examples of policies and procedures, you’ll see that they all seem to follow the same pattern of Title, Versioning, Overview, Purpose, Scope, Policy/Procedure/Standard/Guideline usually in the form of “Thou shalt/shalt not do x”, Exceptions/Violations, and sometimes references to other policies. Contrary to popular belief, very little outside of the actual policy statements are a regulatory requirement. It is always possible to get creative with the formatting and phrasing while still meeting the intent of the framework that you either are planning to adhere to.

While doing research on this topic, we looked at a variety of frameworks and reached out to others in our network and were hard-pressed to think of examples outside of ISO 27001:2013 that explicitly called out sections that should be in your policy document.

• NIST mostly states you should have certain policies and procedures and what should be included in those documents.
• HIPAA states that you should outline what happens when someone violates the policy as well as what kind of policy/procedural information should be included in your documents.
• PCI has requirements as to what sorts of policy and procedural language should be in the document.
• ISO 27001:2013 stands out slightly as it discusses the need for identification and description (title or reference number, for example), review and approval, and version control on top of language that should be included in the documents.

Now, let’s get writing! The next post in our “Back to the Basics” series will cover how to best socialize your newly written policies in a way that will get the people who need to read them to actually read them. We will also touch on how to incorporate your policies into your awareness training process.