Write a Statement of Applicability that passes stage 2
The most scrutinised document in a certification audit, because it is the only one that has to reconcile your risk assessment to the 93 Annex A controls. Most drafts fail because they were built in the wrong direction.
By Parminder Kumar Sharma · · 8 min read
Why this document gets so much attention
The Statement of Applicability is where an auditor checks whether your control set follows from your risk assessment, or whether somebody downloaded a template and ticked most of it.
It is the most scrutinised artefact in a certification audit for a simple reason: it is the only document that has to reconcile two other things. Your risk assessment says what could go wrong. Annex A lists 93 controls. The SoA is where you explain, control by control, why the ones you chose are the ones your risks required.
What the SoA has to reconcile
- InputRisk assessment
- ReconcilesStatement of Applicability
- Input93 Annex A controls
- 1Risk assessment The input the control set has to follow from
- 2Annex A 93 controls across four themes
- 3Applicable A decision on every control, none left blank
- 4Implemented A separate column, because applicable and not yet done is a plan
The mistake that produces most findings
Choosing controls first, then writing risks that justify them.
Auditors detect this quickly, because the risk assessment reads as though it were written to fit a conclusion. A useful test on your own draft: pick three controls you have marked applicable and trace each back to a specific risk. If the trace is "it is good practice", you have a template rather than a statement.
What the document is actually evidence of
It is easy to treat this as a form to complete, and that framing is why it takes so long and reads so badly.
An assessor does not read the Statement of Applicability to learn what controls exist. They already know; the list is published. They read it to find out whether somebody in your organisation made a decision about each one, and whether that person understood what they were deciding.
That is why a document where every applicable control says "implemented via our information security policy" fails on its own. It is one decision written ninety-three times, which is indistinguishable from no decision at all. And it is why an honest "not yet implemented, owner named, target date set" is a better answer than a vague claim of compliance: the first shows a working management system, the second shows a document.
The practical consequence is that the justification column is the document. Everything else is bookkeeping.
Building it
Fix the scope first
Every applicability decision depends on scope. If the scope changes later, the SoA is invalid rather than merely out of date, so settle it before you start.
You should see: A scope statement you would be willing to show a customer.
Work from your risk treatment plan, not from Annex A
Take the risks you decided to treat, and record which controls treat them. This produces your applicable set. Only then open Annex A and go through the remainder.
Doing it in this order is the difference between a document that follows from your analysis and one that was reverse-engineered from a list.
You should see: Every control you have selected traces to at least one identified risk.
Go through all 93 and decide each one
Every control gets a decision. The 2022 edition has 93 across four themes: 37 organisational, 8 people, 14 physical, 34 technological. Silence on a control is itself a finding, because it reads as an omission rather than a judgement.
You should see: No control is left blank, including the ones that are obviously not relevant.
Justify every exclusion in terms an auditor accepts
Exclusions are normal and expected. What is not acceptable is an exclusion with no reasoning that traces back to your scope or your risk assessment.
"We have no on-premises data centre, so physical controls for it are excluded" is a justification. "Not applicable" is not.
You should see: No exclusion whose justification is only 'not applicable' or 'we do not do that'.
Record implementation status honestly
An SoA where all 93 applicable controls are fully implemented on the first pass invites scrutiny, because it is rarely true. Partial implementation with a plan is a normal, defensible position.
You should see: At least one control is marked applicable and not yet fully implemented.
Reference the evidence
Point at the policy, the procedure, the log, the ticket queue. You do not need to embed the evidence in the SoA; you need to be able to produce it without a search.
You should see: For any control an auditor picks, you can reach the evidence in under a minute.
What the columns should be
Minimum viable SoA
- Control reference and title.
- Applicable: yes or no.
- Justification.
- Implementation status.
What makes it defensible
- Which risk or requirement drove the decision.
- Who owns the control.
- Where the evidence lives.
- Date of the decision, and who made it.
The right-hand column is what turns the SoA from a snapshot into something that can be maintained. Without an owner and a date, the next review starts from scratch.
The four exclusions that get challenged, and the wording that survives
Almost every argument in a stage 2 audit about this document is about an exclusion, and almost every one of them is about the same four controls.
Common exclusions, and why they usually fail
| Control area | The exclusion that fails | The exclusion that holds |
|---|---|---|
| Development security | We do not develop software | No code is written, commissioned or modified by us; all applications are bought as a service and configured only |
| Physical and environmental | We are remote first | We hold no premises and no equipment on any premises we control; devices are owned by staff and covered under the endpoint controls |
| Supplier relationships | Not applicable to us | Rarely defensible. Almost everybody has suppliers, and the control is about how you manage them rather than whether you have any |
| Cryptography | We use standard cloud encryption | This is not an exclusion. It is an implementation, and it belongs in the justification column instead |
Two of those four are worth pausing on. Supplier relationships is excluded far more often than it can be, because an organisation reads it as "we do not run a vendor management function" when the control is asking how supplier risk is handled at all. And cryptography is not excluded so much as mislabelled: using a provider's encryption is a decision about implementation, and writing it in the exclusion column invites a question you did not need to answer.
The test for any exclusion is whether it describes your organisation or your intentions. "We have no premises" is a fact an auditor can verify. "We do not think this applies" is a position, and positions get examined.
How long it takes, honestly
Two to three weeks of elapsed time for a first version, of which perhaps four days is your own writing. The rest is waiting for control owners to answer, and that is the part that determines the date rather than the drafting.
The sequence that goes fastest is counterintuitive. Draft a first pass alone, deliberately including answers you know are wrong, then send each owner the rows that belong to them and ask them to correct it. Correcting a wrong answer takes somebody two minutes; producing an answer from nothing takes them a week of not getting round to it. The corrections also arrive with reasoning attached, which is exactly what the justification column needs.
Do not send the whole document to everybody. An owner sent ninety-three rows reads none of them.
One more reason to draft wrong answers first: it surfaces the controls nobody owns. A row that comes back uncorrected, twice, is not a row somebody agreed with. It is a control with no owner, and finding that in week two is worth more than the document itself.
Keeping it alive
Take this with you
What a maintained SoA looks like
- Every one of the 93 controls has an explicit decision, with none left blank.
- Each applicable control traces to a risk or a legal or contractual requirement.
- Every exclusion has a justification tied to scope or risk, not merely a note that the control is inapplicable.
- Applicability and implementation are separate columns.
- Each control has a named owner who knows they own it.
- Evidence locations are recorded, so any control can be evidenced quickly.
- The document carries a date and a version, and the last review is recent.
- It is reissued when scope changes, rather than amended quietly.
Verified
Control counts and themes are from ISO/IEC 27001:2022 Annex A. Written 5 August 2026. Control numbers and short titles are identifiers; no standard text is reproduced here.
