Lesson 4 of 10 · Track A · · Updated
The Statement of Applicability, explained
The Statement of Applicability (SoA) lists every control in Annex A of ISO 27001, says whether each applies to your ISMS, gives the reason for including or excluding it, and records whether it is implemented. It is the document auditors use to plan what they test.
Why does the SoA matter so much?
The SoA is where your risk assessment becomes a testable list. An auditor reads it to understand your scope and control set, then samples controls and asks for evidence. A clear SoA shortens the audit, because the auditor does not have to guess. An inconsistent one, for example a control marked as not applicable while your risk register relies on it, produces findings.
What goes in each row?
For each Annex A control: whether it is applicable, the justification for including or excluding it, whether it is implemented, and a pointer to the policy, procedure or evidence. Justifications should refer to your risks, legal or contract requirements, or the nature of the business. 'Not applicable because we do not operate on-premise data centres' is a good justification; 'not relevant' is not.
How do you keep it current?
Treat the SoA as a living record. Update it when the risk assessment changes, when you add a product or location to scope, and when a control is implemented or retired. Keep the version history, because auditors may ask what changed since the last audit. Many companies review it as a standing item in management review.
Where do platforms help?
Platforms usually hold the control list, map it to evidence and show implementation status, which covers most of the SoA's content. Ask in a demo whether the SoA can be exported in the format your auditor prefers, whether justifications are free text you control, and whether the mapping to evidence updates automatically when an integration reports a failure. If you will add SOC 2 or the Essential Eight later, ask how the same control appears in each framework, because that is where cross-mapping saves or costs time. Sprinto describes a common control framework, Scrut a Unified Control Framework and Scytale control cross-mapping across 80+ frameworks.
What is the fastest way to start one?
Start from the risk treatment plan, not from Annex A. List the controls your treatments require, then walk through Annex A to catch anything missing and write the exclusions last. Keep justifications short and specific. The first version will not be perfect; it has to be honest and consistent with your risk register.
What do auditors most often question in an SoA?
Exclusions without a reason, justifications that contradict the risk register, and controls marked as implemented with no evidence behind them. A second common issue is scope drift: a product or office added to the business but not to the SoA. Before the audit, read the SoA side by side with the risk treatment plan and the scope statement, and fix any row where the three disagree. It is a slow hour that saves a finding.