How to Document Your Security Strategy

🚀 As explained by Laura

If risk management is the mechanism we use to decide what risks to deal with in our organization, our policy, standards, procedures, and playbooks are the guidelines we set in place so that everyone on the team knows how we reduce the impact and likelihood of these risks.

They are our guidebooks, our instruction manuals, and in some cases, our North Star. They turn our security decision-making into a repeatable process based on agreed expectations rather than a subjective process based on our feelings, instincts, or current context.

I know that “policy” has a reputation for being as dry as sawdust, and about as much fun, but stay with me here—the right amount of policy, standards, and procedures can mean the difference between security being complex or simple, and confrontational or collaborative.

What Are Security Strategy Documents and Why Do They Matter?

​confusion​ One of the common misconceptions about policy, standards, procedures, and playbooks is that these words are synonyms—and probably amount to boring tomes of legalese that are best left rotting in a drawer.

Although the legalese part has some element of truth in it (especially in older, more formal security and governance circles), policy, standards, procedures and playbooks are all very different types of document, each with an important part to play in leading security in your company.

Policies set the company’s high-level expectations of how systems, data, processes, and technology will be protected within an organization.

Standards are the implementation guidelines that turn policy from principle to practice.

Procedures and playbooks are documents that turn your policies and standards into actions, and may include tools and step-by-step instructions.

Let’s take a deeper look.

Figure: A visualization of the different kinds of security strategy documents.

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.

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.

An Example Security Standard

Security standards are often structured quite differently from our higher-level policy, breaking down into named or numbered sections. Don’t be alarmed if this looks like your idea of policy. Many teams starting out with documenting their security strategy will naturally jump to writing standards first. It’s important to take a step back, however, and set your policy first. Let’s take a look at what that means.

This is the policy fragment we’re making a standard for:

“All staff are taught what their responsibilities are within the organization before they start.”

As we mentioned before, policy documents are infrequently changed. They are documents that should be stable and predictable, not coupled too tightly to how our organization looks or operates today. This allows us to adapt our approaches to security over time but retain our high-level expectations and principles (which are unlikely to change).

As a result, our policy principle fragment doesn’t talk about how staff are hired or what that process looks like. It simply assumes that we will need staff, they will start their employment, and as part of that process we expect them to have their security responsibilities explained to them.

Our standard takes these assumptions and makes them concrete for the operating processes of your organization.

Here is an excerpt from our standard:

As you can see, we have turned a high-level principle into something that can be implemented into our processes and can be measured. This measurement allows us to check we are compliant (or aligned) with the company’s security policy.

Security Standard Style

Style-wise, the standard is a little more verbose and a little more structured, but on the whole the language remains simple and clear. Once again, there is no wasted wordage here. It is succinct and can be tied clearly back to the principles defined in our policy.

Standards are more frequently changing than policy. They reflect the operating practices, culture, and constraints of your team now, and as that changes, they too will need updating.

One thing that is worth digging into a little more as part of this style discussion is the use of two keywords, each highlighted in bold in our standards excerpt above: must and should.

Mandatory and Recommended Security Standards

Standards define how we are expected to meet our policy principles. As part of this, it is important to communicate clearly where things are mandatory (must) and where they are recommended (should).

​confusion​ It can be tempting in security to say that everything in a standard is essential and therefore use must much more than should. This can be a poor strategy in the long term. Remember that security is about pragmatism and balance. There are always more risks to address than you have time and budget to solve. If you make everything in your standard mandatory, you are committing your limited time and budget to ensure they are all implemented. Sometimes, we will need to compromise and prioritize, choosing to make some standards mandatory (must), if they pose a high risk in terms of likelihood and impact, and making the rest recommended (should), where the risk is more moderate or unlikely.

One of the reasons that standards change more frequently than policy is this decision between what must be done and what should be done. As your business grows and your risk profile changes, things that previously would have been a “nice to have” or posed a low risk, may become more important or risky. In this case, when reviewing your standards you may change your approach and make more must than should.

Security Procedures and Playbooks

To recap: our policy defines our security principles, and our standards define the requirements we need to align with those principles.

That brings us to procedures and playbooks, which turn the standards into action. They give our team the tools and instructions they need to meet the security expectations placed on them through our policy suite in a way that can be measured, repeated, and iterated on as our business evolves.

​important​ Procedures and playbooks are living and evolving operational documents that should be collaborated on across your team. They exist to teach teams how to carry out their responsibilities, to reduce the chance of key person risk, and to ensure that whenever these important tasks are carried out, that they are done consistently.

What’s the difference between a procedure and a playbook?

​Definition​ A procedure is a singular action or set of steps that define how you consistently complete a task. For example, you may have a procedure for how to refill the coffee machine in your office.

​Definition​ A playbook is a set of actions or steps you would follow to navigate a more complex scenario. They will often include multiple decision points and paths that are based on the context.

Do You Need a Procedure or a Playbook?

When deciding whether you can define a simple procedure or need a more comprehensive playbook, start with the following three questions:

1. Is the action we need to take singular or simple to define?

   • If yes, then it’s probably a procedure you need to develop.

2. Does it have different pathways or variations depending on some form of context?

   • If yes, then you probably need a playbook that can advise the person or team taking action what to do in a variety of situations.

3. Does this action fit in with other, non security actions or processes?

   • If yes, then it’s probably an existing procedure you need to adapt or add to (while respecting the original purpose).

Once you decide what you need, take a set of requirements defined by a standard, and turn them into easy-to-understand, repeatable steps that can be completed by someone on your team.

Example Procedures and Playbooks

Let’s go back to our example standard and pick out one of the actions that we created to support our policy.

Using our guide above, we should be able to determine that it’s a procedure we need to develop rather than a playbook, since:

• Our requirement here is short and concise.

• There are very few variations on how it will happen or how it applies to different situations.

In this case, our procedure is to ensure that all new hires read and accept the “Acceptable Use” guidelines we have developed.

The easiest way to implement this is to add this to our “New Hire Onboarding Checklist” as per the example below. As there are many different things a new employee is expected to do in their first few days, this will fit with the existing processes without causing disruption or breaking the cultural flow of the new team member’s first week.

Now let’s take a look at a potential playbook scenario from the same security standard:

This time the requirement is more complicated and includes a number of different configurations or pathways depending on the role and location of the new employee.

• Employees working remotely or in subsidiaries may require different background checks.

• Roles handling sensitive information or financial transactions may require credit checks or additional character references.

• Temporary employees may need a cut down set of checks proportional to their intended period of employment.

In this case, a playbook is needed. This playbook will walk through step-by-step instructions for each of these scenarios and make it easy for the hiring manager to decide which checks are needed and action them.

As you can see, whether it’s as a procedure or a playbook, our policy principles are defined in our standards and implemented in our procedures and playbooks. They are a linked hierarchy of documents that outline our security expectations as a company and give our team the tools and instructions they need to meet them (and if you do it well, there isn’t a bit of legalese in sight).

Pros and Cons of Information Security Templates

All of this may seem overwhelming and like a huge commitment of time and resources. As a result, many people turn to their handy local search engine and type “Information Security Policy Templates” in the helpful little box. Often you will find dozens of collections of policy templates, often referred to as “policy suites.”

I get it; we have all been there. You never want to solve a problem that has already been solved, and why invest this time and effort if you can simply buy, download, and customize a policy suite.

Are Off-the-Shelf Policy Templates Worthwhile?

There is a lot to this question, but let’s dig into the pros and cons.

Advantages of off-the-shelf policy suites:

• They are very often written by consultants and have been used in dozens, if not hundreds, of organizations before. As a result, you can expect them to have had a certain level of scrutiny.

• They may come with a support package that can help you navigate and customize the templates for your environment.

• They may have been specifically written to comply with certain commercial or national regulations and can help with compliance audits.

Disadvantages of off-the-shelf policy suites:

• These are likely to be very generic policies and making them work for your fast-moving environment may be challenging. If you are a cloud native team and don’t have a big on-premise IT infrastructure, for example, these policies may not fit your operational or technical architectures at all.

• They may be outdated. The nice thing about selling policy online is that you write it once and sell it over and over again. While some providers will commit to updates on a regular basis, some will not. Check carefully for signs of outdated or antiquated policy built long ago.

• They won’t be aligned with your company’s communications style and culture. As we have discussed previously in this chapter, this is key to getting people to buy in and help with their implementation. Without this, you may spend a lot of time lost in translation when socializing them with your team.

No book can tell you whether buying existing templates and customizing them or writing your own is the better strategy for your company. However, if you are considering this plan, do your due diligence and make sure you are investing wisely in something that suits your technical environment and operating culture.

Turning Policy into Action

A policy, standard, or playbook that sits unloved and unimplemented does nothing for your company’s security.

It’s important to remember that creating these documents isn’t the end of the process, it’s the beginning. From here it’s up to you and your team to ensure that the requirements and processes defined in this document suite are understood, widely known in the team, and most importantly, put into practice across every area of your business.

There is no one-size-fits-all approach to how you do this. Your business and operations will be unique to your context, and so you will need to weave your new security practices through your culture. As you begin to do this, there are a few things you may want to consider that will help maximize your chances of success.

• Security should not be a block or an obstacle. People (and growing companies) will avoid blockages and obstacles at all costs. It’s in our nature. If your new process or practice is going to slow things down or block something from happening, consider what people may do to avoid it. Instead, work with your teams to explain why the process is needed and what it is trying to accomplish, and then seek their help in finding a solution that won’t cause unexpected detours.

• Security should be respectful. If you need a team to change their processes or take on new security responsibilities, you need to understand and respect the time and resources you are asking them to commit and the impact it will have on their existing commitments. Without this respect, you may find that conflicting priorities arise and tempers fray as people find themselves torn between too many requirements with not enough resources.

• Security should be simple and obvious. Whenever you are implementing a process, ask yourself: is this the simplest process that will solve this problem? If it isn’t then keep working on it—security shouldn’t be complex or painful. It should be easy to navigate, understand, and get done.

  Similarly, if your team isn’t finding security tools or processes easy to find or engage with, make them easier and more obvious. It’s not up to your team to work hard to find them—it’s up to us to make security so easy our team can’t help but be involved.