Security Policy

For most people, their experience of policy has been the documents you receive from an insurance company or finance team. Pages and pages of very complex, multi-clause sentences that cover the rules and regulations governing every possible permutation of a scenario. These are long, impenetrable documents that have left an entire generation scared of policy.

Thankfully, policy doesn’t have to be like that at all.

A good security policy outlines the domains that are expected to be considered throughout the organization and sets guiding principles to which all standards, procedures, and playbooks are expected to align.

Good policy is easy to understand, concise, and easy to digest.

The following is an example introduction to a company-level information security policy.

Example: A Security Policy Introduction

The first thing you should notice is that this isn’t flamboyant or complex language. It is simple, concise, and easy to understand. It doesn’t waste characters in the preamble.

The first section is the objective of the policy. A simple statement of intent that captures what this policy (and its associated standards and playbooks) are aiming to achieve.

The second section is the high-level list of the principles that are covered in this document. As you can see, there are only seven principles. This isn’t a long, complex list, it focuses on simple groups of objectives that can later be tied to standards.

The third section gives the policy an owner within the business. If you are large enough to have a chief information officer (CIO) like in the example, then that’s great, if not this could be your CTO, CEO, or whomever is the overall leader for security within your organization. Remember, this ownership isn’t necessarily the person doing the implementation, it is the person who owns security, its management, and its risk for your team. This is likely to be someone senior, as per the example.

The following is an example security principle from the same policy document. As you can see, once again, it’s short and to the point, with each principle having a similar structure and tone.

Example: A Policy Principle

The aim of each principle is to describe the reason that this principle exists and, at a high level, define the expected behaviors associated with it. In this case, the principle makes it clear that security is a responsibility for all team members and that the company expects that team members will be supported in order to understand how to carry out their responsibilities.

Following on from this description, the principle then links to any associated standards documents. We will dig into these further when we look closer at standards.

Policy Style and Storage

​important​ Your policy should be part of your culture and communications style, not separate from it. A policy that is radically different from the normal voice and style of your organization will feel disconnected and difficult for the team to adopt. Avoiding excess formality will make the policy documents more usable.

Related, consider your organization’s culture when it comes to where to store your policy and how to store it. Gone are the days where policy was stored in paper or PDF format somewhere locked away. Collaboration tools are now everywhere in our companies and your policy should be part of that same information structure.

In many organizations, these documents are electronically linked, allowing you to move from policy to standard to playbook as you read. Thinking about the architecture of your documentation and making it easy to understand and navigate goes a long way to making it an active tool in your organization.

Policy documents are designed to stand apart from the operational details of your business at the moment, and set direction and tone that can be applied as your company evolves. As a result, it is unusual to make frequent changes to a policy—other than annual reviews, these documents are an investment that will last your team for years to come.