ISO 27001 Statement of Applicability: how to write one
The Statement of Applicability is the first document a certification auditor opens and the last one most implementation teams write properly. That order is the problem. It is treated as a deliverable to be produced once the real work is finished, when it is actually the document that proves the real work happened at all — the single place where your risk assessment, your control decisions and your implementation status are visible in one view.
Get it right and stage 1 goes quickly, because the auditor can see the logic of your system without asking for it. Get it wrong and you spend the audit explaining yourself, which is a bad position to argue from.
Most articles on this topic explain what an SoA is. This one shows what a good row looks like next to a bad one, and which exclusion justifications get rejected.
Building the documented set from scratch? The ISO 27001 Total Kit includes the SoA with all 93 Annex A controls pre-structured, alongside the mandatory documents for clauses 4 to 10. €590 excl. VAT.
What the standard actually requires
Clause 6.1.3(d) of ISO/IEC 27001:2022 is short, and every argument about SoA content is settled by reading it carefully. It requires you to produce a Statement of Applicability that contains four things.
The necessary controls, meaning those you determined in 6.1.3(b) and verified against Annex A in 6.1.3(c). The justification for their inclusion. Whether those controls are implemented or not. And the justification for excluding any of the Annex A controls.
Four elements. Not five, not twelve. Everything else you see in commercial SoA templates — control owner, ISO 27002 attributes, links to procedures, implementation dates, residual risk — is optional. Some of it is useful. All of it is your choice, and adding columns you cannot maintain is worse than omitting them.
The word doing the most work in that clause is justification, and it appears twice. The standard asks you to explain both inclusion and exclusion. Most SoAs answer only the second, and answer it badly.
The SoA is downstream, not upstream
The SoA is one of seven documents the clauses require to be available, alongside eight records that must be retained — the distinction decides what an auditor asks you for.
The most common structural error is filling in the SoA first and calling the result a risk treatment plan. It runs backwards.
The sequence the standard sets out is: identify risks, evaluate them, choose treatment options, then determine the controls necessary to implement those treatments. Only then do you compare that set against Annex A to check nothing necessary has been overlooked, and produce the SoA to record the outcome.
Annex A is a checklist for completeness, not a menu you shop from. Clause 6.1.3(c) is explicit that its purpose is to verify no necessary controls have been omitted. The standard even allows controls that are not in Annex A at all, if your risk assessment produced them — a point almost nobody exercises, though it is a strong signal of a real system when an auditor sees it.
The practical test of whether your SoA is downstream: pick any included control and ask which risk it treats. If the answer is a risk ID from your assessment, the chain holds. If the answer is “because it’s in Annex A”, you have a compliance artefact rather than a management system, and an experienced auditor will find that out within twenty minutes.
The anatomy of a row
The 2022 edition organises 93 controls into four themes: organizational (A.5.1 to A.5.37), people (A.6.1 to A.6.8), physical (A.7.1 to A.7.14) and technological (A.8.1 to A.8.34). Your SoA covers all 93, including the ones you exclude — a table listing only the controls you applied is not a Statement of Applicability, because the exclusions and their justifications are half of what the clause requires.
A workable structure needs six columns. The four the standard requires, plus two that make the document usable rather than merely compliant.
| Column | What goes in it |
|---|---|
| Control reference and title | A.5.7 Threat intelligence — as written in Annex A |
| Applicable | Yes or No |
| Justification | Why included, or why excluded. One or two sentences, specific |
| Implementation status | Implemented, partially implemented, planned with a date |
| How it is implemented | The procedure, system or record that realises the control |
| Risk reference | The risk ID from your assessment that this control treats |
The last column is the one that turns an SoA from a list into evidence. It is not required. It is the fastest way to demonstrate that the chain in the previous section is real, and it costs one column.
Keep justifications to one or two sentences. An SoA is a control document, not a narrative — if the justification needs a paragraph, what it actually needs is a reference to the procedure where the reasoning lives.
Worked rows: what good and bad look like
The difference is easier to see than to describe.
Take A.5.7, threat intelligence, one of the eleven controls new in the 2022 edition.
A weak row says: applicable, justification “required by ISO 27001”, status “implemented”, implementation “we monitor threats”. Every field is technically populated and none of it can be verified. What does “we” mean, monitor how often, and where is the output?
A strong row says: applicable, justification “supports risk R-014, targeted attacks against our public API”, status implemented, implementation “SOP-08 section 4; weekly review of vendor advisories and national CSIRT feeds, output recorded in the threat register”, risk reference R-014. An auditor reading that knows exactly what to ask for next, and you know exactly what to hand over.
Now take A.7.4, physical security monitoring, for an organisation with no premises of its own.
A weak exclusion says: not applicable, justification “we are a remote company”. That is an assertion about your working model, not about the control, and it invites the obvious follow-up about the data centre your servers sit in.
A strong exclusion says: not applicable, justification “the organisation operates no physical premises within the ISMS scope; all production infrastructure is hosted with providers assessed under A.5.19 to A.5.23, whose physical security controls are verified through their ISO 27001 certificates and SOC 2 reports, reviewed annually”. The exclusion now rests on a scope fact and points to where the risk is actually managed.
That is the shape of every defensible exclusion: a statement about scope or context, plus where the concern is handled instead.
Which exclusion justifications hold
Auditors accept exclusions all the time. They reject a fairly predictable set.
Accepted, because they are facts about scope or context:
- The activity does not exist in the organisation. A.8.25 to A.8.31 on secure development, where no software is developed in scope and no code is modified.
- The asset type does not exist. A.7.7 clear desk and clear screen has a physical component that does not arise where there are no offices in scope, though the screen half usually still does.
- The relationship does not exist. A.5.20 addressing security in supplier agreements, where there are genuinely no suppliers with access to information within scope — rare, and worth double-checking before claiming.
- The obligation falls to another party and you can show the transfer, with the assessment of that party recorded.
Rejected, reliably:
- “Not applicable because we are small.” Size affects how a control is implemented, never whether it applies. This is the single most common rejected justification.
- “Not applicable because we have no budget.” A resourcing statement. If a necessary control is not implemented, it is applicable and not yet implemented, with a date — that is an honest SoA and a finding-free one.
- “Not applicable because the risk is low.” Low risk means the control is scaled down, not excluded. Exclusion requires the control to be irrelevant, not the risk to be small.
- “Not applicable because the cloud provider handles it.” Shared responsibility does not remove your obligation; it changes what your obligation looks like. You still assess and monitor the provider, and that assessment is the evidence.
- “Not applicable because it duplicates another control.” Overlap between controls is normal by design. Two controls addressing the same concern are both applicable.
- Silence. A blank justification field is a nonconformity against an explicit clause requirement, and it is the easiest one for an auditor to raise.
The pattern is straightforward once you see it. A control is excluded because it does not apply to your organisation, never because implementing it would be inconvenient.
The mistakes that come back as findings
Beyond individual rows, a handful of structural problems account for most SoA findings.
The SoA that contradicts the ISMS. It says A.8.16 monitoring activities is implemented; the internal audit report from four months ago says logging coverage is partial. Both documents are in the same evidence pack. This is the most damaging failure because it puts every other statement in the document in doubt.
The SoA against the 2013 Annex. Migration from ISO/IEC 27001:2013 closed in October 2025, and certificates against the old edition are no longer valid. An SoA with 114 controls in fourteen clauses is against a superseded edition of the standard.
The SoA nobody updated. A control was decommissioned, a system replaced, a procedure renumbered, and the SoA still describes the previous arrangement. Because it is the reference point for so much else, a stale SoA quietly invalidates the documents that point at it.
Everything marked implemented. In a real implementation, a few controls are partial or planned at any moment. An SoA showing 93 out of 93 fully implemented on the day of stage 1 reads as aspirational rather than accurate, and auditors treat it that way — they will pick the least likely three and ask for evidence.
The SoA with no owner. Nobody is responsible for updating it, so it is updated once a year in a rush before the surveillance audit. Assigning it to whoever runs the risk register solves this permanently.
Keeping it alive
The SoA is also what defines the control side of your internal audit scope. How to run an internal audit when nobody in the organisation is independent covers the arrangement that most small organisations get wrong.
One trigger is easy to miss: the standard itself changes. The European adoption carries amendment A1:2024, which added a climate change determination to clause 4.1, and a context analysis written before 2024 will not have it.
The SoA changes whenever the risk assessment changes, whenever the scope changes, and whenever implementation status moves. Treat those three as the triggers rather than the calendar.
Version it properly with a date and a change record, because the auditor will compare this year’s against last year’s and ask what moved. Differences are expected. Being unable to explain them is not.
Review it at management review under clause 9.3 alongside the risk assessment. And once a year, take the ten controls where the justification is thinnest and check whether it still describes what you do. That check takes an hour and it is where the contradictions surface, before someone else finds them.
If you are still assembling the rest of the documented set, which ISO 27001 documents are mandatory works through the clause and control requirements, and the risk register the SoA traces back to sets out the nine columns that keep the two documents in sync. If you also fall under NIS2, the four gaps an ISMS leaves open covers what the SoA cannot help you with.
Frequently asked questions
Is the Statement of Applicability mandatory? Yes. Clause 6.1.3(d) requires it explicitly, and it is one of the documents certification bodies request before stage 1. There is no route to certification without one.
Does the SoA have to list all 93 Annex A controls? Yes. The clause requires justification for excluding any Annex A control, which is only possible if every control appears with a decision recorded. A document listing only applied controls is incomplete.
Can I exclude controls and still be certified? Yes, and most organisations do. What matters is that the justification is a fact about your scope or context rather than a preference, and that the exclusion does not contradict something else in your ISMS.
How many controls do organisations typically exclude? There is no target and auditors do not have one. Excluding a large number invites scrutiny of your scope; excluding none in an organisation that plainly develops no software suggests the SoA was not thought through. Neither is a rule.
What is the difference between the SoA and the risk treatment plan? The risk treatment plan says what will be done, by whom and by when. The SoA records which controls are necessary, why, and their current status. They are related and they are not interchangeable — the standard requires both.
Does it need to be a spreadsheet? No. It needs to contain the four required elements and be under document control. A spreadsheet is the common choice because 93 rows are easier to filter than to read as prose.
Where to go from here
An SoA is a day of work if the risk assessment is sound, and a week of archaeology if it is not. That asymmetry is the real message: when the document is hard to write, the difficulty is telling you something about the system underneath it.
The ISO 27001 Total Kit includes the Statement of Applicability with all 93 controls pre-structured and the columns above, plus the mandatory documented information for clauses 4 to 10 and the registers the Annex A controls produce. €590 excl. VAT — one policy per process rather than a folder of overlapping files.
Sources
- ISO/IEC 27001:2022, in particular clauses 6.1.2, 6.1.3 and 9.3, and Annex A
- ISO/IEC 27002:2022 for control guidance and attributes