Ask an experienced ISO 27001 auditor which document they turn to first, and many will say the Statement of Applicability. The SoA ties together the whole ISMS: it links your risk assessment to your controls and signals, at a glance, how seriously and deliberately you have approached security. A weak SoA undermines confidence in everything else.
This guide explains what the SoA is, what it must contain, how to build one that holds up, and the common mistakes to avoid on the path to iso 27001 certification.
What the Statement of Applicability is
The Statement of Applicability (SoA) is a document that lists every Annex A control and, for each one, states whether you have included or excluded it, the justification for that decision, and — for included controls — their implementation status.
It is a mandatory output of ISO 27001 (required by Clause 6.1.3) and arguably the central artefact of the ISMS. Where the risk assessment identifies what could go wrong, the SoA records what you are doing about it.
In effect, it is the index of your entire control environment — which is exactly why auditors lean on it so heavily.
Why it matters so much
The SoA is where the logic of your ISMS becomes visible. It demonstrates that your controls are chosen deliberately, driven by risk, and complete relative to Annex A. A clear, well-justified SoA tells an auditor that you understand your risks and have responded to them rationally.
Conversely, a sloppy SoA — vague justifications, controls excluded without reason, no link to risk — raises immediate doubts and invites deeper scrutiny of the whole system. It is the first impression your ISMS makes.
Because it is reviewed at Stage 1 and every subsequent audit, the SoA is a document worth real care.
Free resource
The Complete Guide to ISO 27001
A practical, plain-English guide to building your ISMS and earning ISO 27001 certification.
What the SoA must contain
A complete SoA covers all 93 Annex A controls (for the 2022 edition). For each control it records: whether it is applicable, the justification for inclusion or exclusion, a reference to how it is implemented, and often its current status and owner.
It should also identify the version of the standard and the date, and be approved and version-controlled like any key ISMS document. Many organisations add columns linking each control to the risks it treats and to the evidence that proves it.
The exact format is flexible — a spreadsheet is common — as long as it contains these essentials clearly.
How it connects to the risk assessment
The SoA is not created in isolation; it is the output of your risk assessment and treatment plan. Each control you include should exist because it treats one or more identified risks, and that linkage is what makes the SoA defensible.
This connection is what auditors probe: they pick a control and ask ‘why is this here?’, expecting an answer that traces to a risk. They also pick an excluded control and ask ‘why not?’, expecting a sound justification.
Building the SoA directly from the risk treatment plan, rather than as a separate exercise, keeps these links intact.
Justifying inclusions
For included controls, the justification is usually straightforward: the control treats a risk you identified, or it meets a legal, regulatory, or contractual obligation. Keep justifications concise but specific — ‘treats risk R-12, unauthorised access to customer data’ is far better than ‘good practice’.
Specific justifications demonstrate genuine risk-based thinking and make audits faster, because the auditor can see your reasoning without interrogation.
Where a control meets an external obligation, cite it; this is valuable evidence of compliance with interested-party requirements.
Justifying exclusions
Exclusions are legitimate but must be justified properly. A sound exclusion explains why a control genuinely does not apply — for example, ‘no in-house software development, so secure-development controls are not applicable’, or ‘all infrastructure is cloud-hosted, so controls for owned data-centre facilities do not apply’.
What auditors will not accept is exclusion for convenience: ‘too expensive’ or ‘too much effort’ are not valid reasons to drop a control that treats a real risk. Each exclusion should withstand the question ‘are you sure this risk genuinely does not exist for you?’
Honest, specific exclusions actually strengthen the SoA by showing you have considered every control deliberately. Getting this right is a significant part of a smooth path to iso 27001 certification.
Keeping the SoA current
The SoA is a living document, not a one-time deliverable. As your organisation, risks, and controls change, the SoA must be updated to match — a new product line, a new supplier, or a move into software development can all change which controls apply.
Surveillance audits will check that the SoA still reflects reality. An SoA frozen at initial certification while the business has moved on is a reliable source of findings.
Treat SoA review as part of your maintenance rhythm, revisiting it whenever the risk assessment is updated.
Common SoA mistakes
Several mistakes recur. The first is generic justifications (‘best practice’) that show no real thought. The second is excluding controls without sound reasons to reduce workload. The third is an SoA disconnected from the risk assessment, so the two documents tell different stories.
A fourth is letting the SoA go stale, and a fifth is confusing ‘applicable’ with ‘implemented’ — a control can be applicable but still in progress, and the SoA should say so honestly.
Avoiding these keeps the SoA credible and the audit smooth.
Using the SoA as a management tool
Beyond satisfying auditors, a good SoA is genuinely useful internally. It gives leadership a single view of the control environment, highlights which controls are still in progress, and shows how security maps to risk — useful in board reporting and in answering customer security questionnaires.
Treated this way, the SoA stops being mere paperwork and becomes a live dashboard of your security posture, worth keeping accurate for your own benefit, not just the auditor’s.
Many teams find it becomes their go-to reference whenever a security question arises.
Building your SoA efficiently
The most efficient way to build an SoA is to generate it directly from your risk treatment plan, using a template that already lists the 93 controls and prompts for justification, status, owner, and linked risks. This avoids omissions and keeps the structure consistent.
Compliance automation tools can maintain the SoA dynamically, updating control status as evidence flows in — which keeps it current with little manual effort and ready for any audit.
However you build it, the goal is the same: a clear, risk-linked, honest record of your controls.
The bottom line
The Statement of Applicability is the keystone document of your ISMS: a complete record of every Annex A control, its inclusion or exclusion, the justification, and its status. Auditors read it first because it reveals whether your security is deliberate and risk-driven.
Build it from your risk assessment, justify every decision specifically, keep it current, and use it as a live management tool, and it will carry your audits rather than complicate them.
ISpectra produces risk-linked, audit-ready Statements of Applicability as a standard part of every engagement — with free VAPT and a multi-framework discount — so your most important document is also your strongest.
Free consultation
Need help with ISO 27001?
Talk to our certified compliance team — we’ve supported 200+ audits.