Statement of Applicability (SoA): what it is and how to build it in ISO 27001
By Kike Gandia · Co-Founder & CEO, OSCP
The Statement of Applicability — SoA — is, along with the security policy, the document most scrutinized by any ISO 27001 auditor. It's the written proof that your company has reviewed all 93 Annex A controls one by one and decided, with reasoning, which apply and which don't. An SoA copied from a generic template is the fastest signal that the rest of the ISMS isn't real either.
What the standard requires of the SoA
Clause 6.1.3.d) of ISO/IEC 27001:2022 requires producing a Statement of Applicability that contains: the controls deemed necessary based on the risk assessment, the justification for their inclusion, whether they are implemented, and the justification for excluding any Annex A control that does not apply. It is not optional or a decorative appendix: it is an auditable requirement.
The 93 Annex A controls (2022 edition) and their four categories
The 2022 revision reorganized the previous 114 controls into 93, grouped into four themes: organizational (37 controls: policies, roles, supplier relationships...), people (8: remote working, training, terms of employment...), physical (14: secure perimeter, equipment, cabling...) and technological (34: access control, cryptography, vulnerability management, secure development...). The SoA must walk through all 93, not just the ones that are convenient to apply.
How it is built: from the risk assessment to control-by-control justification
The correct process starts from the risk assessment, not from Annex A: first you identify which risks exist and what treatment you decide to give them (mitigate, transfer, avoid or accept); then, for each mitigated risk, you identify which Annex A controls address it. Only then do you fill in the SoA, marking that control as applicable with a justification that cites the specific risk it addresses — not a generic template sentence.
Excluding a control (with justification) is just as valid as including it
A common mistake is assuming "more controls marked" is better. It is not: a cryptography-in-transit control that does not apply because no data flow requires it should be excluded, with that exact justification. An experienced auditor immediately spots an SoA where everything is marked applicable with no exceptions: it signals that nobody did the real analysis exercise, only ticked boxes.
What columns an SoA that survives an audit actually has
The standard says what information it must contain, not how to lay it out. In practice, the structure that raises the fewest questions in an audit is a five-column table, and what makes it credible is the fourth and fifth columns. An example using real Annex A controls from the 2022 edition:
| Control | Applies? | Justification | Status | Evidence |
|---|---|---|---|---|
| 5.7 Threat intelligence | Yes | Risk R-04: targeted attacks on the internet-facing service | Implemented | Advisory monitoring procedure and review log |
| 5.23 Information security for use of cloud services | Yes | The entire platform is hosted with a cloud provider | Implemented | Shared responsibility matrix and provider contract |
| 7.4 Physical security monitoring | No | No own data centre; the office hosts no in-scope systems | Not applicable | ISMS scope and hosting contract |
| 8.11 Data masking | Yes | Risk R-11: use of real data in test environments | Being implemented | Treatment plan, milestone with date and owner |
| 8.23 Web filtering | No | Workstations do not reach the in-scope internal network | Not applicable | Network diagram and device policy |
Two details make the difference. First: the justification cites the specific risk by its identifier, letting the auditor walk backwards from the SoA to the risk assessment in seconds. Second: the status column distinguishes implemented from being implemented, with a date in the treatment plan. Declaring everything implemented when it is not is a guaranteed finding, because the auditor will ask for evidence on two or three controls at random.
The SoA and the risk treatment plan are not the same document
They get confused constantly, and they are two separate deliverables the auditor will ask for separately. The SoA is a snapshot per control: for each of the 93 Annex A controls, whether it applies, why, and what state it is in. The risk treatment plan is a snapshot per risk: for each identified risk, what decision was made (mitigate, transfer, avoid or accept), what concrete actions will be taken, by whom, by when, and with what expected residual risk. One looks at controls, the other at risks, and the two must be coherent: every control marked applicable in the SoA should trace to at least one risk in the plan, and every mitigated risk should point to the controls that mitigate it. Incoherence between the two is among the most frequent findings in a first certification, and also among the easiest to avoid if they are built together rather than one after the other.
FAQ
Is the SoA reviewed once, or does it need updating?
It's reviewed whenever something relevant changes: a new asset, a newly identified risk, a change in ISMS scope, or at minimum during each annual system review. An SoA that's out of sync with the current risk assessment is a typical finding in surveillance audits.
Can we use an SoA template as a starting point?
As a structure, yes. As content, no: every justification must reflect your organization's real risk assessment. A template with generic, copied justifications is exactly what an experienced auditor spots and questions in the first review.
Who must sign off or approve the Statement of Applicability?
Top management, as part of their accountability for the ISMS (ISO 27001 clause 5.1). It's not a purely technical document: it involves a business decision about which risks are accepted and which are mitigated.
What format is it delivered in, and how long is it?
The norm is a spreadsheet with one row per control and version control, because that is the format the auditor works with and the one that allows filtering and commenting. Length depends on how long the justifications are, not on company size: it is always 93 rows. What does vary is the depth: in a small organisation, a one- or two-line justification per control is enough if it cites the risk and the evidence.
Can we show the SoA to a client who asks for it?
You can, but think it through first: the SoA describes precisely which controls you have not implemented and why, which is sensitive information in a third party's hands. The usual approach is to share it under a confidentiality agreement, or to provide the certificate and its scope instead, which normally settles the request. If the client insists on the SoA, it signals they are running a serious vendor assessment, and it is worth asking what exactly they need to verify.
What happens if we add a new service mid-cycle?
First check whether the service falls inside the certified scope. If it does, the risk assessment has to be updated, you have to check whether the change activates controls that were excluded — the classic case being processing data in a new country or bringing in a cloud provider — and reflect it in the SoA with a date. The surveillance auditor compares the SoA against last year's: an architecture change leaving no trace in the SoA is exactly what makes them look closer.
How long does it take to build from scratch?
Walking through all 93 controls with real judgment takes several working sessions spread over weeks, not days, and the reason is not the writing: it is that each control forces you to check what actually happens and who does it. That walkthrough is, in practice, the most complete diagnostic the organisation will get, which is why it belongs at the start of the project rather than as the last formality before the audit.
Related service
ISO 27001 implementation consulting