The ISO 27001 Statement of Applicability, explained

Of all the documents in an ISO 27001 management system, the Statement of Applicability is the one your auditor will open first. It is also the one most teams fill in last, in a hurry, and get wrong. Here is what it is really for.

What the SoA actually is

The Statement of Applicability — usually just called the SoA — is a single document that lists every control in Annex A of ISO 27001 and states, for each one, whether you apply it, why, and whether it is currently in place. ISO 27001 requires it explicitly in clause 6.1.3. It is not optional, and it cannot be replaced by a policy pack or a control spreadsheet from your compliance tool.

The 2022 version of the standard has 93 Annex A controls grouped into four themes: organisational, people, physical, and technological. Your SoA has to account for all of them. "Account for" does not mean implement all of them — it means make a deliberate, documented decision about each one.

Why auditors read it first

The SoA is the bridge between your risk assessment and everything else you have built. An auditor reading it can see, on a few pages, what you decided to protect, what you chose not to do, and whether your reasoning holds together. From there they know exactly which evidence to ask for.

That also makes it the fastest place to expose a weak management system. If your risk register says third-party access is a top risk but your SoA marks supplier controls as not applicable, the contradiction is visible in about ten seconds — and it is a finding.

What each entry needs to contain

A defensible SoA gives five things per control:

• Control reference and name — e.g. A.5.15 Access control, taken straight from Annex A so nothing is silently dropped.
• Applicable: yes or no — a clear decision, not a maybe.
• Justification — why. For applicable controls this points to the risk it treats, a legal or contractual obligation, or a business requirement. For excluded controls it explains why the risk genuinely does not exist for you.
• Implementation status — implemented, partially implemented, or planned with a target date. Being honest here is safer than claiming completeness you cannot evidence.
• Reference to how it is implemented — the policy, procedure, system or record that proves it, so the auditor can follow the thread.

Exclusions: the part people get wrong

You are allowed to exclude controls. What you are not allowed to do is exclude them because they are inconvenient. The justification has to rest on the nature of your organisation, not your appetite for work.

A fully remote company with no offices can reasonably exclude several physical security controls — as long as it has thought about home working and equipment instead, which are separate controls. A company that writes no software of its own can exclude secure development controls. But "we're small", "we don't have the budget yet" or "our cloud provider handles it" are not justifications on their own. That last one is especially common: your provider may operate the control, but you still own the decision, the contract and the oversight.

Every "not applicable" in your SoA is a claim you will be asked to defend out loud. Write each one as if the auditor is already asking why.

Building it in the right order

The most common cause of a messy SoA is building it too early. The sequence that works:

1. Define your scope. Which parts of the business, which systems, which locations. Everything downstream depends on this.
2. Run the risk assessment. Identify risks to your information, and assess them consistently — ISO 27005 is the usual reference for how.
3. Decide on treatment. For each significant risk, decide what you will do about it and which controls achieve that.
4. Then write the SoA. Map those decisions across all 93 Annex A controls, catching anything your risk assessment missed and documenting genuine exclusions.
5. Keep it alive. Review it whenever scope, risks or systems change, and at least annually.

Done this way, the SoA writes itself from work you have already done. Done backwards — starting from a template of 93 rows and reverse-engineering reasons — it produces a document that reads exactly like what it is.

Five mistakes worth avoiding

• Copy-pasted justifications. Forty controls justified with "required for information security" tells the auditor you did not think about any of them.
• No version control. The SoA is a controlled document. It needs an owner, a version, an approval and a review date.
• Drift from reality. The SoA says implemented; the system says otherwise. This is where most findings come from.
• Silent gaps. Controls left blank rather than decided. An unanswered control is worse than an excluded one.
• Treating it as a one-off. A SoA that has not changed in two years while the company doubled in size is not credible.

If you are also doing ISO 42001

ISO 42001 has its own Statement of Applicability covering its Annex A controls for AI. The logic is identical, and if you are running both standards it is far easier to build them as one integrated exercise than to repeat the whole process a year later. Our guide to building an AI Management System covers how the two fit together, and if you are earlier in the journey, ISO 27001 for startups sets out the wider path to certification.

How long it takes

Writing the SoA itself is a matter of days once the risk assessment is done. The work is in the thinking that precedes it. Teams that treat it as a documentation task budget a week and lose a month; teams that treat it as the output of their risk decisions find it takes almost no extra time at all.