Statement of Applicability (SoA) in ISO 27001: what it must contain and how to draft it

The Statement of Applicability (SoA) is the document in which you record which controls your organization needs, why, and whether they have been implemented. ISO 27001 makes it mandatory in clause 6.1.3 d. In a certification audit it is usually one of the first documents the auditor asks for, because it shows how the risk assessment led to concrete controls. Below is what the standard actually requires, how to build an SoA and where it tends to go wrong in practice.

What clause 6.1.3 requires

The SoA is the final step of risk treatment. Clause 6.1.3 sets out a sequence. You choose a treatment option for each risk, you determine which controls are needed to carry out that treatment, and you compare those controls with Annex A to check that you have not left out anything necessary. Only then do you produce the SoA.

Under 6.1.3 d the SoA contains four things: the necessary controls, the justification for including them, whether they are implemented or not, and the justification for excluding any Annex A controls. The third point is often missed. An SoA may list controls that are needed but not yet fully in place, as long as that is stated honestly and the risk treatment plan says when and by whom the gap will be closed.

Something else that is often overlooked: Annex A is not an exhaustive list. The standard itself says you can use controls from other sources, for example ISO 27017 for cloud environments or requirements that apply to your sector. Those belong in the SoA as well.

Annex A in the 2022 version

ISO 27001:2022 has 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). The 2013 version had 114 in fourteen domains. The revision merged many controls and added eleven new ones: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28). If you converted an SoA from the 2013 era, check those eleven in particular: is the justification substantive, or was it copied from a mapping table? The other changes are covered in the article on the ISO 27001:2022 update.

What an SoA entry looks like

A table with fixed columns works best: control number and name, applicable yes or no, the reason for inclusion or exclusion, the implementation status, and a reference to the policy, procedure or system where the control is embedded. Many organizations add a column with the risks the control addresses. The standard does not ask for that, but it makes the link to the risk assessment visible at a glance.

Take control 5.15, access control. A weak justification reads: applicable, we have an access policy. A useful one names the risks from the register that the control addresses, refers to the access policy with its version number and to the process for granting and revoking rights, and states the status. From that single entry the auditor can ask for evidence, for example a sample of the employees who left the organization over the past year.

Justifying exclusions

You may exclude a control, but the reason has to follow from your scope and your risks. Not relevant is not a justification. There is no in-house software development within the scope and all applications are bought as SaaS: that is one. An auditor will still check whether nobody within the scope builds scripts, integrations or low-code applications, because that is where an exclusion of development controls 8.25 to 8.28 regularly falls apart. Note too that 8.26, on application security requirements, applies to acquiring software just as much as to building it.

The opposite is at least as common: marking everything applicable out of caution. It feels safe, but every control you list as applied must be demonstrable at the audit. A well-justified exclusion carries less risk of a finding than a control that exists on paper and not in practice.

Physical controls are a recurring grey area. An organization that runs entirely in the cloud and has no server room of its own still cannot exclude theme 7 as a whole. There are still offices, workstations and equipment used off-premises (7.9). For the data centre the control shifts to the supplier, and the SoA should then refer to how you assess that supplier, for example on the basis of its ISO 27001 certificate or ISAE 3402 report.

The SoA and the risk assessment belong together

The order is risk assessment, risk treatment, SoA. Starting by filling in Annex A and then looking for risks to match reverses the logic. An auditor spots this in an SoA where every control is marked applicable with the same stock sentence, and in a risk register that never mentions a control that is not also literally in Annex A. How to build the risk assessment itself is covered in the risk assessment guide.

The SoA, the risk treatment plan and the risk register must still line up after every change. If the scope changes, an important supplier is added or a system is retired, update all three. Give the SoA a version number and a date, and make the approval traceable. ISO/IEC 27006, the standard certification bodies work to, requires the certificate to reference the version of the SoA. An SoA that lags behind will therefore stand out at the next audit.

What an auditor checks in the SoA

In stage 1 of the certification audit the auditor mainly looks at completeness. Are all 93 controls listed, is every exclusion justified, and does the SoA match the defined scope? In stage 2 and in surveillance audits the SoA becomes the sampling frame. The auditor picks controls marked as implemented and asks for evidence that they work. A gap between what the SoA claims and what the organization can show then leads to a finding. The rest of the certification process is described in the ISO 27001 certification roadmap.

The internal audit should test the SoA as well, with the same question: does what is written match what is in place? An internal auditor who goes through the SoA line by line against the actual setup finds the gaps before the certification body does.