The document everyone dreads
The Statement of Applicability, explained with a worked example
The SoA is the mandatory document that maps all 93 Annex A controls to your organisation: applicable or not, why, and how. It is the first thing many auditors read, and the document that most reliably exposes a copy-pasted ISMS. Here is how a good one is built.
The anatomy
What every SoA must contain
Four things, control by control: whether the control is applicable; the justification for including it, traced to a risk, a contract or a legal obligation; the justification for any exclusion; and how each applicable control is implemented. The standard does not mandate a format, so a disciplined spreadsheet is perfectly acceptable and usually the most maintainable choice.
What auditors are really checking: does this document trace to your Annex A control decisions and your risk assessment, or was it written the week before the audit?
Worked example
Four rows from a real-shaped SoA
A fictional 40-person SaaS company, fully remote. Note the shape: justifications reference numbered risks and real obligations, and the exclusion is argued, not asserted.
| Annex A control | Applicable | Justification | Implementation |
|---|---|---|---|
| 5.1 Policies for information security | Yes | Required by the risk assessment and by every interested party; the ISMS policy set implements it. | Information security policy suite, approved by the board, reviewed annually. |
| 6.1 Screening | Yes | Employees and contractors handle client data; risk R-014 (insider misuse). | Referencing and right-to-work checks at hire, enhanced checks for privileged roles. |
| 7.4 Physical security monitoring | No | No premises in scope: fully remote organisation, infrastructure in accredited cloud data centres (see 5.23). | Not implemented; excluded with justification. |
| 8.24 Use of cryptography | Yes | Client data in transit and at rest; risks R-003 and R-021; contractual requirements from two customers. | TLS 1.2+ everywhere, provider-managed encryption at rest, key management via the cloud KMS. |
Repeat for all 93 controls of ISO 27001:2022. The full control list, in plain English, is on the Annex A page.
Where SoAs go wrong
The three failures auditors see weekly
Everything marked applicable
All 93 controls ticked "yes" to avoid writing justifications. Now every one must be evidenced at Stage 2, including the ones you do not actually operate.
Justifications that reference nothing
"Best practice" is not a justification. Auditors trace to risks, contracts and laws; a column of generic phrases signals a template.
The SoA nobody updates
A new supplier, a new product, a new office, and the SoA still describes last year's business. Surveillance audits check the date and the delta.
Quick answers
SoA questions, answered
What is the Statement of Applicability in ISO 27001?
The Statement of Applicability, usually shortened to SoA, is the mandatory document that lists every control in Annex A and states, for each one, whether it applies to your organisation, why, and how it is implemented if it does. It is the bridge between your risk assessment and your actual controls, and one of the first documents any auditor opens.
Can we exclude Annex A controls?
Yes, and most organisations exclude several. What you cannot do is exclude silently: every exclusion needs a justification that survives scrutiny, like having no physical premises in scope. Exclusions driven by inconvenience rather than genuine inapplicability are the fastest way to a Stage 1 finding.
How long should an SoA be?
One row per Annex A control, 93 rows for the 2022 standard, plus columns for applicability, justification and implementation. A well-structured spreadsheet is the usual and most maintainable format. Anything dramatically shorter is missing required content; anything dramatically longer is usually padding.
Does the SoA have to reference the risk assessment?
In practice, yes. Auditors trace controls back to the risks or obligations that justify them, and inclusions without a traceable reason read as box-ticking. The justification column in the worked example above shows the pattern: risk references, contractual requirements or legal obligations.
Dreading the spreadsheet?
We write SoAs that survive auditors
The SoA is built as part of every readiness engagement, traced to your real risks. A free 45 minute scoping call starts it.