The Statement of Applicability in ISO 27001

by Julia Dutton on October 8, 2020

When it comes to ISO 27001 compliance, the SoA (Statement of Applicability) is one of the key documents you must complete.

It identifies the controls you have selected to address information security risks, explains why those controls have been selected, states whether they’ve been implemented, and explains why any Annex A controls have been omitted.

Although ISO 27001 doesn’t require you to use Annex A controls exclusively, you do have to check the controls you select from elsewhere against those in Annex A to ensure that each risk is appropriately mitigated.

This means there will be at least 114 entries in your SoA – one for each Annex A control – each of which will include extra information about each control and, ideally, link to relevant documentation about each control’s implementation.

As such, you can think of your SoA as the index for your ISMS (information security management system).

Sponsorships Available

What are your requirements?

When the 2013 version of ISO 27001 was published, many people struggled to understand what the requirements of an SoA were.

ISO/IEC responded by releasing a technical corrigendum (ISO 27001 Technical Corrigendum 2: ISO/IEC 27001:2013/Cor.2:2015), which does a much better job of explaining how to implement an SoA.

It clarifies that, as part of the risk treatment process, organisations must produce an SoA that contains:

the necessary controls;
justification for their inclusion;
whether the necessary controls are implemented or not; and
the justification for excluding any of the Annex A controls.

Technical Corrigendum 2 can be downloaded free of charge direct from the ISO website, as can Technical Corrigendum 1, which replaces subclause A.8.1.1.

We suggest that you download both corrigenda when you buy your copy of ISO 27001. When you purchase the Standard from IT Governance, you’ll automatically receive a copy of both.

Legal, contractual and regulatory requirements

ISO 27001 requires an ISMS to take account of – and to document – the organisation’s legal, statutory, regulatory or contractual requirements, and its approach to meeting them.

The SoA will record information about controls that relate to these requirements, and indicate whether they were implemented for reasons other than the risk assessment.

Benefits of the SoA

The main benefit of an SoA is that provides a concise summary of your risk management process.

It is much easier to understand than the risk assessment report, which can be quite lengthy (some organisations identify thousands of risks) and therefore unwieldy when it comes to everyday operational use.

The SoA, however, enables you to quickly review your information security policies, procedures and other documentation or systems that have been applied in order to treat the identified risks.

How to develop your Statement of Applicability

The process of developing the SoA can be mapped to five steps:

1. Identify and analyse risks

You need to identify all the events that might compromise the confidentiality, integrity and/or availabilityof an asset that is within the scope of your ISMS. You also need to analyse how the risk might occur, which usually requires you to identify a vulnerability in your asset and a threat that might exploit that vulnerability.

2. Select controls to treat risks

As part of your risk assessment you will need to mitigate the risks to reduce them to an agreed, acceptable level.

ISO 27001 suggests four ways to treat risks: retain (tolerate), avoid terminate), share (transfer) or modify (treat).

Modifying the risk means that you will apply security controls to reduce the impact and/or likelihood of that risk.

These controls can be drawn from Annex A of ISO 27001, as well as those contained in other frameworks, such as the PCI DSS (Payment Card Industry Data Security Standard) or NIST SP 800-53.

3. Plan your risk treatment

The RTP (risk treatment plan) needs to be produced as part of a ISO 27001-compliant ISMS. This provides a summary of each of the identified risks, the responses that have been determined for each risk, the risk owners and the target date for applying the risk treatment.

4. Implement controls

Your SoA should set out a list of all controls recommended by Annex A, together with a statement of whether the control has been applied or not, along with a justification for its inclusion or exclusion.

Implementing your selected controls can be a time-consuming task, depending on the gap between your organisation’s actual security level and your risk appetite.

5. Maintain the SoA

ISO 27001 requires the organisation to continually review, update and improve the ISMS to make sure it is functioning effectively, and that it adjusts to the constantly changing threat environment.

Clause 8.2 of ISO 27001 states that risk assessments should be performed at planned intervals or when significant changes occur.

In doing this, you might find that your organisation reduces its risk appetite and plans to reduce the impact and likelihood of identified risks by identifying new controls.

You will need to produce a new SoA each time your organisation carries out a risk assessment. However, the SoA should be maintained between risk assessments so that you have an accurate record of the controls you have selected and whether or not they have been implemented.

How to create an SoA

Developing an SoA can be seem daunting, but there are tools that can help, like vsRisk.

This online tool produces an SoA while you complete your risk assessment, providing all the information you require in an audit-ready format. You can export the report into XLS, PDF or CSV, where you can customise it as you like.

With our help, you can create consistent, repeatable risk assessments that ensure your organisation addresses every threat that it faces.