Glossary
Statement of applicability
Also called: SoA
A statement of applicability lists every Annex A control in ISO/IEC 27001, states whether each one is applicable, and justifies the decision either way. It is the document an auditor reads first, because it defines the scope of everything else that follows from it.
Statement of applicability explained
What it must contain
For each Annex A control: whether it applies, the justification for including or excluding it, and whether it is currently implemented. Exclusions need reasoning — "not applicable" without a reason is the most commonly raised observation on a statement of applicability.
Why consistency is the risk
The statement says which controls you adopted. The risk treatment plan says why, by reference to identified risks. The policy set implements them. Those three documents are usually written by different people at different times, and any inconsistency between them is a finding.
An auditor will pick a control from the statement, ask which risk it treats, and then ask to see the procedure that implements it. A gap anywhere in that chain is visible immediately.
How document control helps
Tagging each policy, procedure and piece of evidence with the Annex A control reference it supports turns that chain into a filter. It also makes the reverse check possible: a control marked applicable with no linked documentation is a gap you can find before an auditor does.
Keeping it current
It changes whenever the risk assessment changes, the scope changes, or a control's implementation status changes. A statement of applicability that has not been revised since certification is either a very stable organisation or an unmaintained document.
FAQ
Statement of applicability: common questions
Can controls be excluded?
Yes, with justification. Excluding controls for activities the organisation genuinely does not perform — application development, for instance — is normal and expected. Excluding one because it is inconvenient is not.
Should we share it with customers?
Many vendors do, under NDA, and it is a reasonable request from an enterprise buyer. Some provide a summary instead. Either is acceptable; refusing without explanation is not.
Related terms
- 21 CFR Part 1121 CFR Part 11 is the FDA regulation governing electronic records and electronic signatures in regulated life sciences.
- Business associate agreementA business associate agreement is the contract HIPAA requires between a covered entity and any vendor that creates, receives, maintains or transmits protected health information on its behalf.
- Data processing addendumA data processing addendum is the contract between a controller and a processor governing how personal data is handled.
- eIDASeIDAS is the EU regulation establishing a framework for electronic identification and trust services.
- ESIGN ActThe ESIGN Act is the US federal statute giving electronic signatures and records the same legal effect as paper, provided the parties intended to sign and consented to transact electronically.
- GDPRThe General Data Protection Regulation governs the processing of personal data in the EU, with an equivalent UK regime.
Dernière revue: 28 août 2026. Browse the full glossary.