ISO 27001 Statement of Applicability

A central component of becoming compliant with ISO 27001 is creating a Statement of Applicability (SoA). This is a document in which a vast number of controls (defensive policies, procedures, techniques and mechanisms) are considered, and the applicability of each one is weighed up against your organisation’s risks.

While a deeply useful process, it is also labyrinthine. This guide is designed to help you successfully navigate that maze.

Whether your organisation is using ISO/IEC 27001:13 or 22, there will be a vast number of controls for you to consider. In the 27001:13 iteration, there are 114, divided into 14 domains, whereas the updated 27001:22 version has 93 Annex A controls, 11 of which are new.

That’s a whole lot of controls.

So, What Does This All Mean For Your Organisation?

It means that for every single one of ISO 27001’s controls, you must consider each in your Statement of Applicability. But that’s not all.

Your SoA must include:

• A description of every single control from Annex A (the identical text)
• A short description of all additional controls you have applied
• Justification for each applied control
  • For all applied controls, whether they are currently implemented (or not)
  • For all excluded controls, justification of why they have been excluded.

In short, for each control you must adopt a ‘comply or explain’ approach: you must comply with the control …or explain why you don’t. Although this may seem fairly straightforward, it’s worth illustrating what that would look like in practice.

Sample Statement of Applicability: January 2024

In the example above, only the numbers and titles of the Annex A controls are mentioned. However, Clause 6.1.3d requires that you include ‘the necessary controls’ in the SoA. This means the full description of the controls as stated in Annex A.

Your justification for inclusion should match previously identified risks and/or relevant legislation. Justification for exclusion should be that a control ‘does not contribute to modifying a risk’.

Benefits of a Statement of Applicability

Creating a Statement of Applicability serves a few purposes beyond being a requirement for certification.

Your SoA not only acts as a useful register, tracking whether each control has been applied (or not) and implemented (or not), but also allows an at-a-glance method of communicating your information security status with stakeholders, without divulging specific implementation details. Ideally, your SoA won’t reveal specific information that your organisation would be safer not sharing.

Do remember, however, that you are under no obligation to share your SoA with others – although withholding it could raise questions with potentially interested parties.

Finally, your SoA will also be useful as input for your risk treatment plan.

Is ISO 27001 Annex A Sufficient?

You might think that given the horde of controls included in Annex A, the official list would be all you will ever need. But you’d be wrong.

There may be additional controls you might want to include – ones particular to the unique risks your organisation faces.

Often, for smaller companies, the existing Annex A controls are sufficient, but larger organisations sometimes supplement the existing set with many more of their own.

A thorough risk assessment will help you understand for which risks additional controls might be needed. Always start with identifying the risk before deciding on the right control.

Justification for Inclusion

Clause 6.1.3 states that you must justify the inclusion of Annex A controls in your SoA.

You must show ‘correspondence’ between risks and the use of Annex A controls. During stage 2 of an ISO 27001 certification audit, the auditor will want to see ‘correspondence between the determined controls, the Statement of Applicability, the results of the information security risk assessment and risk treatment process, and the information security policy and objectives.’

What to Do If a Specific Annex A Control Cannot Be Linked to One of Your Identified Risks

If this is the situation you find yourself in, you should work on any missing risks (in your risk assessment), then link the newly identified risk to the relevant control.

Doing so can restore the coherence between controls and risks that the standard demands. Any control that does not contribute to modifying a risk should be excluded, along with justification for its exclusion given.

Justifying every control in the SoA might seem time-consuming, but it’s a useful and valuable process. The information can be used for internal audits, as well as help an external auditor assess the suitability and effectiveness of deployed controls.

You should state, as directly as possible, the reason for applying each control. Doing so, helps find correspondence between risks and the controls designed to manage them.

What Does Exclusions Mean in ISO 27001?

Excluding a control doesn’t mean it isn’t in the SoA. The standard asks us to justify any excluded controls.

If you have not been able to identify risks within your scope for which you can apply the control, you may exclude that control. This might mean that the activity or circumstances mentioned in the control, i.e., ‘Delivery and loading areas’, are not present in your scope.

However, if you have identified a ‘low risk’ in your organisation’s risk assessment, this is not a reason to exclude the relevant control. In such a situation, you can express this low risk by translating the generally formatted Annex A control to your own specific control that better suits your organisation.

Implemented: Yay or Nay?

For each control, you must state whether that control has been implemented (or not).

However, this is not as binary as it might appear. The SoA implementation guide states that control can be ‘fully implemented’, ‘in progress’, or ‘not yet started’. What matters is that the implementation of the control is in progress, is being monitored and has been logged as so. It’s all about awareness and the SoA is a record of that awareness.

To claim conformity with the Standard, specifically requirement 6.1.3d, your SoA document must indicate whether each control is implemented or not. To comply, all necessary controls should be fully implemented.

Partial Controls in ISO 27001

If a given control is only partially relevant to your organisation, you should reference your information security risk assessment results along with the risk treatment plan. Follow this up with the expected information security risk modification derived from implementing the modified control.

For example, a company might modify control: A.11.2.9 ‘clear desk and screen policy’, because they have no paper documents and only need a clear screen policy. That’s absolutely fine.

In the justification, all that would be necessary is a brief description of how paper documents and removable media are never used, and therefore not applicable. It’s just that simple. The controls are there to suit your organisation – make them work for you.

Can You Include Information in Your Statement of Applicability

Don’t hesitate to include supplementary relevant information in your SoA. It can be useful for interested parties if you include information such as ‘owners of controls’, or details on how controls are implemented.

ISO 27001 Statements of Applicability for Suppliers

Interested parties can ask to see your SoA, and you can equally ask to see suppliers’. This aids a mutual assurance of how information security is managed.

When you request the supplier’s SoA, remember to check:

1. The certificate’s expiry date – is it still valid? If not, why not?
2. The scope: Are the services and products you receive covered?
3. Which Annex A controls have been excluded and why?

You’re now SoA  Aware – to Get Ready for Compliance

Although we recommend you seek the help of an experienced consultancy team, you’re on the right path to understanding SoA process before you set out on your compliance journey.

In short, it is crucial to remember that each control should be meticulously evaluated for its relevance, effectiveness and alignment with the specific risks your organisation faces.

Whether a control is included or excluded, the justification for the decision is what matters and should reflect your risk assessment outcomes.

Your SoA’s importance extends beyond mere compliance. It’s an effective tool for internal audits, risk treatment planning, and a communication bridge with stakeholders — providing them with a snapshot of your information security status without divulging specific details.

As much as it can seem daunting, developing a robust Scheme of Applicability is a valuable process that ensures a robust and tailored approach to managing information security, enabling your organisation to navigate the ever-evolving cyber security landscape with confidence.