ISO 27001 Statement of Applicability: How to Write One

The Statement of Applicability is the most scrutinised document in an ISO 27001 audit and one of the most often templated. Here is how to write one that holds up.

ISO/IEC 27001 clause 6.1.3(d) asks for a Statement of Applicability: a document listing the controls you need, why you included them, whether they're implemented, and why you excluded any of Annex A's 93 controls. It sounds administrative. In practice it's the bridge between your risk assessment and your controls, and certification auditors read it closely, because a weak SoA usually means a weak risk process behind it.

What it must contain

For every control in Annex A, and any controls of your own:

Applicable or not.
The justification for inclusion: usually the risks it treats, a legal or contractual requirement, or a business decision.
Implementation status: implemented, partly implemented or planned.
The justification for exclusion, if excluded.

Most SoAs add a short description of how each control is implemented and a reference to the policy or procedure. That isn't strictly required but makes audits much faster.

Justifying inclusion

Tie each control to something concrete: a risk in your register, a legal requirement (GDPR Article 32, NIS2, sector regulation), a contract or a customer requirement. "Best practice" is a weak justification; "treats risks R-12 and R-17 and required by our NIS2 obligations" is a strong one. Linking controls to legal requirements also helps when you answer to several frameworks: our requirement pages show which other frameworks each Annex A control maps to, for example A.8.24 use of cryptography.

Photograph of a slim closed ring binder on an empty meeting table beside a closed laptop and a pen — Short and specific beats long and generic.

Justifying exclusion

Exclusions are allowed but each needs a reason auditors can test. Good reasons:

The activity doesn't happen in scope. No outsourced development: A.8.30 excluded.
The risk doesn't exist in scope. A fully remote organisation with no offices may exclude some A.7 physical controls, though not those covering equipment and media wherever they are.

Weak reasons: "not relevant", "handled by IT", "cloud provider does it". If a supplier performs the control, it's still applicable; you manage it through supplier controls.

Common audit findings

The SoA doesn't match the risk treatment plan. Controls chosen in risk treatment must appear in the SoA, and vice versa.
Implemented controls with no evidence. Marking a control implemented invites a request for proof.
Template language. Descriptions copied from a template that don't match what you actually do.
Stale versions. An SoA still listing 2013 Annex A numbering, or not updated after a significant change.

A practical structure

One row per control: ID and title, applicable (yes/no), reason (risks, legal and contractual requirements), status, a one-line description of how it's done, the owner, and the reference to evidence. Keep it in a spreadsheet or your GRC tool under document control, and review it with every risk assessment.

Keeping the SoA alive

An SoA written for the first certification and never touched again becomes a finding at the next audit. Keep it current by updating it whenever:

the risk assessment changes the selected controls;
the scope changes (a new product, office or cloud provider);
a control's implementation status changes;
a new legal or contractual requirement applies (for example NIS2 or a customer's contract).

Record the version, date and approver each time.

Key takeaways

Every Annex A control needs a decision and a reason, including exclusions.
Link inclusions to specific risks and legal or contractual requirements.
Keep the SoA consistent with the risk treatment plan, and current.

Doing several frameworks at once

If you also answer to SOC 2, NIS2 or PCI DSS, add a column for the matching requirements in each. The SoA then becomes the backbone of a common control set; our post on one control set for SOC 2 and ISO 27001 shows the approach, and the gap analysis lists every Annex A control against any other framework. The ISO 27001 guide covers the rest of certification.

Questions

Can you exclude Annex A controls in ISO 27001?

Yes, if the exclusion is justified, typically because the risk doesn't exist in your scope (for example outsourced development when you don't outsource development). Exclusions must be justified in the Statement of Applicability.

What must a Statement of Applicability contain?

ISO 27001 clause 6.1.3(d) requires the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A controls.

Is the Statement of Applicability shared with customers?

Not usually in full; it's an internal document reviewed by the certification body. Some organisations share a summary with customers under NDA to show which controls apply.

Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.

Writing a Statement of Applicability that survives the audit