Guides › Statement of Applicability
Statement of Applicability (SoA): content, structure, examples.
The Statement of Applicability (SoA) is one of the most important documents in an ISMS. For every control in Annex A of ISO 27001, it shows whether you apply it and why. No auditor will certify without it.
What the standard requires.
ISO 27001 requires the SoA in clause 6.1.3 d. It connects your risk treatment with the catalogue of controls in Annex A and must contain four things:
Necessary controls
All controls you need to treat your risks, including those that do not come from Annex A.
Justification for inclusion
Why a control is applied: because of a risk, a legal or contractual obligation or a business requirement.
Implementation status
Whether the control has already been implemented or is still being implemented.
Justification for exclusion
Why a control from Annex A is not applied. An exclusion without a comprehensible justification is a nonconformity.
What an SoA looks like.
In practice, the SoA is a table with one row per control. All 93 controls from Annex A of ISO 27001:2022 must appear in it, including the excluded ones. Three example rows:
| Control | Applicable | Justification | Status | Evidence |
|---|---|---|---|---|
| A.5.15 Access control | yes | Risk R-012 unauthorised access to customer data; contractual requirement from customers | implemented | Access control policy, access matrix |
| A.8.13 Information backup | yes | Risk R-004 data loss due to ransomware | in progress | Backup concept, measure M-031 restore test |
| A.8.28 Secure coding | no | No in-house software development within the scope | – | – |
Additional columns for the owner and the date of the last review have also proven useful. The SoA is a controlled document: it gets a version number and is approved.
Creating the SoA in 5 steps.
The SoA is not created at the beginning but emerges from risk treatment. If you fill it in beforehand, you are guessing.
Assess risks
Without a risk assessment there is no sound justification for inclusion or exclusion.
Select controls
Define the appropriate controls for every risk you treat.
Compare with Annex A
Go through each of the 93 controls: is it needed? Has anything been overlooked?
Justify and evidence
Justify inclusion or exclusion for every control and enter the status and evidence.
Approve and maintain
Approve the version and update it whenever risks or controls change.
What auditors find in the SoA.
SoA and risk treatment do not match
The treatment plan contains a measure, but the matching control is excluded in the SoA, or vice versa. This is the most common finding.
Exclusions without justification
“Not relevant” is not enough. The justification must make clear why the control plays no role in your scope.
Everything set to “implemented”
If every entry says “implemented”, the auditor will want to see the evidence. Honest entries saying “in progress” with a target date are more credible.
The SoA is out of date
Created once for certification and never touched again. This will be noticed at the latest in the surveillance audit.
The SoA that keeps itself up to date.
In WolfISMS you link every control to risks, measures and documents. WolfISMS generates the Statement of Applicability from this automatically, with justification, implementation status and evidence. If a risk changes, the SoA is still correct.