Security Policy

5 minutes


Updated October 9, 2023
Now Available
Security for Everyone

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 objective of information security is to effectively and properly secure our assets to prevent the misuse, loss, damage, or compromise of our hardware, software, and data.[Section 1: Objective]
The following policy principles are captured in this policy:
• Information Security Governance and Risk Management
• Staff Security and Training
• Operations Management
• Access Management
• Asset Management
• Physical Security
• Business Continuity Management
[Section 2: Principles]
This policy document is owned by the Chief Information Officer.[Section 3: Owner]

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.

Unlock expert knowledge.
Learn in depth. Get instant, lifetime access to the entire book. Plus online resources and future updates.
Now Available

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

Principle 2: Staff Security and Training
Everyone has a role when it comes to information security. All staff are taught what their responsibilities are within the organization before they start. Security awareness and role-specific security training help make sure everyone understands how they carry out those responsibilities.

Related Standards:
• Hiring and Onboarding
• Security Training

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.

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.

Security Standards

If our policy outlines the high-level expectations and principles guiding your organization’s approach to security, then our standards are where we get specific about what this means.

Standards tell us the specific requirements our team must meet if we are to say we have successfully followed our security policy. One security policy may result in ten or more standards, each tackling a part of the overall security landscape and all linked back to root policy principles.

Let’s take a look at an example standard, in this case supporting the principle we used in the example previously, relating to the security of our people.

You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.
If you found this post worthwhile, please share!