editione1.0.0
Updated October 9, 2023If 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.
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.
Assumption 1: You will hire people (and make sure they aren’t a high risk).
Assumption 2: Responsibilities are explained to new team members.
Assumption 3: Team members will understand these responsibilities and act accordingly.
Here is an excerpt from our standard:
example1.1 Hiring and Onboarding
1.1.1 Background Screening & Checking ACME Limited must ensure that all people working for the organization are screened to minimize risks to the security of the organization’s information and systems, including verifying their:
Identity and right to work
References and qualifications
Record with the Ministry of Justice
The recruitment process for roles that are expected to have access to sensitive information or to have financial responsibilities should include additional pre-employment checks appropriate to the risk level of the role.
1.1.2 Terms & Conditions of Employment
ACME Limited must provide documentation that defines and explains the information security responsibilities for all staff, including contractors. This documentation is usually called an “Acceptable Use” guideline.
All staff must read and acknowledge they agree with these responsibilities before they are assigned any access to data or systems.
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.
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.
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.
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.