How to write an ISO 27001 Statement of Applicability

A Statement of Applicability, or SoA, is a table with one row per Annex A control. For each row you record whether the control applies, why it was included or excluded, and its implementation status. It comes out of your risk treatment work, and the certification auditor uses it as a map for the audit.

What the SoA must contain

Clause 6.1.3 d) of ISO 27001 sets four required elements. You list the controls you have decided to apply. You give a justification for including each one. You state whether each is implemented. And you justify excluding any Annex A control you leave out.

Annex A is comprehensive but not exhaustive. If your risk treatment calls for a control that Annex A does not contain, you can add it from another source, such as a NIST special publication or ENISA guidance.

Build it from the risk assessment

The SoA is the link between the risk assessment and the controls you actually run. That means you should not start by reading Annex A top to bottom and ticking boxes. Start with the risks you decided to treat, pick controls for them, and then walk the full control list to catch controls required for other reasons, such as law or customer contracts.

A useful column set looks like this:

• Control number and name
• Applicable (yes or no)
• Reason for inclusion, tied to a risk, a legal duty or a contract
• Implementation status, for example implemented, partly implemented or planned
• How it is implemented, with a link to the policy, procedure or tool

Describe how, not just whether

Good practice is to say how each applicable control is implemented. You can point to a policy or procedure, write a short description of the procedure right in the SoA, or name the equipment used. A short procedure can live in the SoA itself, so you do not have to create a separate document for every control.

Expect this to take longer than planned. Filling in the "how" column forces decisions about new tools, changed procedures and sometimes hiring, and those decisions are the real work.

Handle exclusions carefully

Only Annex A controls can be excluded, and every exclusion needs a justification. Auditors read exclusions closely. A reason like "no physical office, the team is fully remote" explains a risk that does not exist for you. A reason like "too expensive" does not explain anything about risk.

Also check that the new 2022 controls are not silently missing. If your SoA still reflects the older structure, the auditor is likely to raise it.

Keep it alive

The SoA is a living document. When you add a system, change a supplier or close a risk, update the row. The certification auditor uses it as the central document on site, checking whether controls work the way the SoA says they do. A SoA that describes a process nobody follows is worse than a short one that is accurate.

Safeguard can help with the evidence side. Its compliance and evidence automation collects proof for controls you have already chosen, so each "how" cell can link to something current. The choice of which controls apply stays with your risk process.

Quick check

Sources

• The importance of the Statement of Applicability for ISO 27001

Last reviewed: 19 October 2026.