The Statement of Applicability in ISO 27001

by Luke Irwin on October 23, 2019

The SoA (Statement of Applicability) is one of the key documents when it comes to ISO 27001 compliance.

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

Aren’t the requirements for an SoA unclear?

When ISO 27001:2013 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.

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.

Legal, contractual and regulatory requirements

An SoA isn’t just about identifying security weaknesses. ISO 27001 requires an ISMS to take into account and document your organisation’s legal, statutory, regulatory and contractual requirements for information security, and your approach to meeting them.

The SoA will record the controls that you select to meet these requirements and whether they were implemented for reasons other than the risk assessment.

Benefits of the SoA

A risk assessment report can be quite lengthy – some organisations identify thousands of risks – so the document isn’t particularly useful for everyday operational use.

The SoA, however, is relatively concise and can be used as an overview of the entire ISMS.

It’s also useful as a simple way of identifying the 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:

Identify and analyse risks

You need to identify all the events that might compromise the confidentiality, integrity and/or availability of 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.

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.

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.

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.

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 daunting, but there are tools that can help, like vsRisk Cloud.

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.