Statement of Applicability (SoA)
ISO 27001's central document: a complete listing of the Annex A controls stating, for each, whether it applies, why, and its implementation status. The bridge between your risk assessment and your actual security program.
What it must contain
Per clause 6.1.3, the SoA must contain: the necessary controls (from Annex A's 93, plus any you added from other sources), justification for each inclusion, implementation status, and justification for every exclusion. In practice it's a table: control, applicable yes/no, justification, status, and a pointer to where the control lives — policy, system, owner.
It is a living document: every risk assessment update, scope change, or new system should ripple into it. An SoA last touched at certification two years ago tells the auditor the ISMS froze the day the certificate arrived.
Writing exclusions that survive audit
Exclusions must trace to reality, not convenience. Strong: “A.7.4 physical security monitoring — excluded; the organization operates no physical premises; all infrastructure is AWS, addressed via A.5.19–5.23 supplier controls.” Weak: “not applicable” with no reason, or excluding secure development while shipping software weekly.
The auditor's method is triangulation: risk assessment says X matters → SoA should include controls for X → evidence should show them operating. Breaks in that triangle are where 27001 findings come from.
Go deeper, free.
Every standard this term appears in has a free clause-by-clause guide on ReadSafety.com — and when you're ready for certification, USQC provides accredited third-party audits.
Browse the guidesCertify with USQC