Ask an experienced ISO 27001 auditor where they start, and many will say without hesitation: the Statement of Applicability. The SoA is the document that ties your whole information security management system together, and getting it right matters more than almost any other single artefact you will produce. Understanding what it is — and, more importantly, what it is for — is one of the most useful things a team pursuing certification can do early.
What it is
The SoA lists the Annex A controls and, for each one, records three things: whether it applies to your organisation, the justification for including or excluding it, and its implementation status. In effect, it is the bridge between your risk assessment — what could go wrong — and your controls — what you actually do about it. Where the risk assessment identifies problems, the SoA records your deliberate decisions about which safeguards you will apply, and why. It is, in a real sense, the summary of your security thinking made explicit and auditable.
Why auditors focus on it
The SoA is the auditor’s map, and they use it exactly as a map. At a glance it tells them what you have decided to do and why, and it gives them a checklist to test against reality. If a control is marked applicable and implemented, they will look for evidence that it genuinely operates. If it is marked excluded, they will scrutinise your justification for excluding it. A clear, honest, well-maintained SoA makes the whole audit smoother, because it demonstrates that your security decisions are deliberate, reasoned and traceable rather than ad hoc. A weak SoA has the opposite effect: it invites deeper probing everywhere, because if this central document is sloppy, the auditor reasonably wonders what else is.
Common mistakes
- Excluding controls without real justification. “Not applicable” needs a defensible reason genuinely tied to your risk assessment and context — not convenience or a wish to avoid the work.
- Marking controls implemented when the evidence is thin. If you claim a control operates, an auditor will expect to see it operating; overstating status is one of the fastest routes to findings.
- Letting it go stale. The SoA should reflect the real, current state of your controls, not last year’s intentions. As controls and risks change, the SoA must change with them.
- Disconnecting it from the risk assessment. The SoA is supposed to be driven by your risk assessment; when the two do not line up, the logic of your whole ISMS appears broken, and an auditor will notice.
How to keep it strong
Treat the SoA as a living summary of your security decisions rather than a document produced once, in a hurry, for the auditor. Review it whenever your risk assessment changes, when you add or retire controls, and as a standing item in your regular management review. Keep the justifications honest and specific rather than generic, and make sure the implementation status genuinely matches reality on the ground. Maintained this way, the SoA becomes a true asset that speeds the audit and actively helps you manage security — rather than a liability that quietly unravels under the first serious question.
The SoA is where your risk assessment and your controls meet. Keep it honest, current and connected to your risks, and it becomes the clearest single piece of evidence that your ISMS is deliberate, reasoned and under control.
The takeaway
Far from being administrative box-ticking, the Statement of Applicability is the heart of an ISO 27001 ISMS — the document that connects why you are worried to what you are doing about it. Invest in getting it right, keep it genuinely current and tied to your risk assessment, and you strengthen both your audit outcome and, more importantly, your actual security posture.