ISO 27001 Statement of Applicability: Deciding What Applies and What Doesn't

Of all the documents in your ISMS, the Statement of Applicability (SoA) is the one your certification auditor will spend the most time with. It is a mandatory document under Clause 6.1.3 of ISO 27001:2022, and it answers a deceptively simple question: of the 93 controls in Annex A, which ones apply to your organisation, which ones don't, and why? Get it wrong and you will face major nonconformities at audit. Get it right and it becomes a genuinely useful map of your security programme.

What the Statement of Applicability Actually Is

The SoA is not a policy, a plan, or a risk assessment — it is a decision record. It lists every Annex A control and, for each one, states:

Whether the control is applicable to your organisation (included) or not (excluded)
The justification for that decision, traced back to your risk assessment or another explicit reason
Whether the control is implemented, and often how (a brief description or reference)
The version of Annex A you are working against — the 2022 revision reorganised and renumbered the controls, so this matters

The requirement comes from Clause 6.1.3 (information security risk treatment), which says you must compare the controls you have determined as necessary against Annex A and verify that nothing essential has been overlooked. In practice, most organisations treat the Annex A list as the starting universe and justify each control in or out.

Where the SoA Fits in Your Certification Journey

The SoA is not written in isolation. It sits downstream of two earlier pieces of work:

Your risk assessment — the risks you identified and the treatment options you chose drive most applicability decisions
Your risk treatment plan — the SoA is essentially the control-level view of that plan

This ordering matters. A common mistake is drafting the SoA before the risk assessment is finished, which produces a document full of guesses that contradicts the risk register. Build your risk register first, agree the treatment approach with management, and then let the SoA fall out of that work. Auditors trace this chain of logic — risk identified, treatment chosen, control selected, control implemented — and any break in the chain is a finding waiting to happen.

Deciding What Applies: The Decision Framework

1. Start From Risk, Not Habit

Why It Matters: Applicability decisions that aren't anchored to risk are impossible to defend at audit.
How to Do It: For each control, ask whether it treats a risk you identified, satisfies a legal or contractual obligation, or addresses a business requirement. If the answer to all three is no, the control is a candidate for exclusion.

2. Be Ruthlessly Honest About Exclusions

Why It Matters: Excluding controls is legitimate — ISO 27001 is not a checklist where more is better. But weak or boilerplate justifications are a red flag for auditors.
How to Do It: Write a specific, factual reason for every exclusion. "Not applicable — we do not operate any cloud services" is defensible. "Not applicable" with nothing behind it is not. Common legitimate exclusions include physical controls for fully remote organisations, secure development controls for businesses that write no code, and teleworking controls for fully office-based teams.

3. Don't Confuse "Excluded" With "Not Yet Done"

Why It Matters: A control that applies but hasn't been implemented yet is an inclusion with an honest implementation status — not an exclusion.
How to Do It: Record it as applicable, note that implementation is in progress, and make sure your risk treatment plan shows the timeline. Auditors respect an honest work-in-progress; they do not respect exclusions that are really just admissions of an unfinished control.

4. Watch the Tricky Controls

Why It Matters: A handful of controls trip up almost every organisation.
How to Do It: Pay particular attention to controls around supplier relationships, secure development, and cloud services. Even if you develop no software, you probably configure SaaS platforms — that can still bring parts of the secure development theme into scope. "We don't do that" deserves a second look before it becomes an exclusion.

---

Confirming the Control Set With Your Certification Body

One step organisations routinely skip is agreeing the ground rules with their certification body before the audit. Since the 2022 revision of the standard, both the 2013 and 2022 editions of Annex A have been in circulation during the transition period, and certification bodies moved to the new edition on different schedules.

Confirm which Annex A version you will be assessed against — for any new certification today this will be ISO 27001:2022, but if you are transitioning from a 2013 certificate, confirm the transition timeline with your certification body in writing.
Share your draft SoA early — most certification bodies are happy to review it during a Stage 1 audit and flag concerns before Stage 2, when findings carry more weight.
Check for scheme-specific expectations — some certification bodies and industry schemes expect certain controls to be included by default. Knowing this upfront avoids an argument in the audit room.

---

Keeping the SoA Alive After Certification

The SoA is not a write-once document. It should be revisited whenever something material changes: a new office, a new cloud platform, an acquisition, a new risk assessment cycle, or an incident that exposes a gap. Many organisations schedule an annual SoA review alongside their management review meeting. An internal audit is also an ideal trigger — auditors will check whether the SoA still reflects reality, and "last updated three years ago" is an awkward answer.

If the gap between your Annex A control set and your actual practice is unclear, a structured ISO 27001 gap assessment will show you which controls need attention before you commit your decisions to paper. For organisations that want ongoing senior oversight of the SoA and the wider ISMS, our vCISO service can own that maintenance for you.

The Statement of Applicability rewards honesty and punishes vagueness. Anchor every decision in your risk assessment, write real justifications for exclusions, confirm the control set with your certification body early, and treat the document as a living record rather than certification paperwork. Do that, and the SoA stops being a bureaucratic hurdle and becomes the clearest single-page view of your security programme you own.

Assess your ISO 27001 readiness with our FREE ISO 27001 Gap Assessment Tool — instant results, no sign-up required.