The Statement of Applicability is the document a certification auditor opens first and returns to most. It lists every Annex A control, says which ones your ISMS includes, and says why. It is also a document many teams fill in from a template in an afternoon, with "Applicable: Yes" on every row and a justification column that repeats the control name.
That version passes a quick glance and fails a careful one. The auditor uses the Statement of Applicability to trace from a control back to the risk that required it and forward to the evidence that it operates. If the justifications are generic, the trace breaks at the first step.
This article covers what ISO/IEC 27001:2022 requires the Statement of Applicability to contain, the extra columns that make it useful, how to write justifications that hold up, and how to keep it current.
What the standard requires
Clause 6.1.3 d) requires you to produce a Statement of Applicability that contains four things:
The necessary controls, meaning the controls you determined in your risk treatment, whether they come from Annex A or elsewhere.
The justification for including them.
Whether the necessary controls are implemented or not.
The justification for excluding any Annex A controls.
Every one of the 93 Annex A controls must appear, because the standard requires a justification for each exclusion, and you cannot justify an exclusion you have not listed. Controls you added from other sources, such as a cloud privacy code of practice or your own design, appear too.
The Statement of Applicability is an output of risk treatment. That ordering matters. It records decisions that the clause 6 risk process already made. Writing it before the risk assessment, and then building risks to match, is the most common way to end up with a document that does not hold together.
The columns worth having
The four required elements fit in four columns. A few more make the document work as an index to the ISMS rather than a list.
| Column | What goes in it | Required by 6.1.3 d)? |
|---|---|---|
| Control reference and name | The Annex A number and title, such as 8.13 Information backup | Yes, implicitly |
| Included | Yes or no | Yes |
| Justification for inclusion | The risks, legal, regulatory, or contractual requirements that make the control necessary, by reference | Yes |
| Justification for exclusion | Why the control is not necessary in your context | Yes, for Annex A controls |
| Implementation status | Implemented, partially implemented, or not yet implemented | Yes |
| How it is implemented | One or two sentences, with references to the policy or procedure | No, but auditors use it |
| Owner | The person accountable for the control | No |
| Evidence | Where the auditor can see it operating | No |
The last three columns are not required, and some organizations keep them in a separate control register instead. Either works. What matters is that an auditor can get from the Statement of Applicability to the owner and the evidence without asking you to find them.
Writing justifications that hold up
A justification answers the question "why is this control here, in this organization". The answer should be specific enough that it could not be pasted into another company's document unchanged.
Justifying inclusion
The strongest inclusion justification points to your own records. Reference the risk register entries the control treats, and any interested party requirements from clause 4.2 that demand it. A hypothetical example:
5.23 Information security for use of cloud services. Included. Treats risks R-07 (misconfiguration of hosting provider services) and R-12 (provider outage affecting customer service). Required by customer contracts that specify approved hosting arrangements.
Weak justifications restate the control ("to ensure cloud services are secure") or cite the standard ("required by ISO 27001"). The standard does not require any specific Annex A control, so the second one is incorrect.
Justifying exclusion
An exclusion is a claim that the risk the control addresses does not exist in your scope, or is fully addressed another way. Auditors test exclusions harder than inclusions, because a wrong exclusion leaves a real gap.
Exclusions that tend to hold up describe a fact the auditor can check. For example, 8.30 Outsourced development may be excluded where no development is outsourced, if that is true and stays true.
Exclusions that tend to fail rely on a provider. A fully remote company with all infrastructure in the cloud may reasonably exclude some physical controls for premises it does not have. It cannot treat "the cloud provider handles it" as a justification on its own, because using that provider is itself a risk you manage through the supplier controls, 5.19 to 5.23. And several physical controls still apply to laptops in homes: 7.9 Security of assets off-premises, 7.10 Storage media, and 7.14 Secure disposal or re-use of equipment.
Implementation status and the treatment plan
The standard requires you to state whether each necessary control is implemented. It does not require every included control to be fully implemented before certification. A control that is included but not yet implemented is a recorded decision with a plan behind it.
That plan is the risk treatment plan. Every control marked partially implemented or not implemented should appear in it, with an owner and a target date. An auditor who finds a "planned" control with no corresponding plan entry, or a plan entry whose date passed a year ago, will raise it.
Be honest in this column. Marking a control implemented when it is not is the fastest way to lose an auditor's trust in the rest of the document.
Versioning and keeping it current
Treat the Statement of Applicability as a controlled document under clause 7.5. It needs a version number, a date, an approver, and a change history. Your certification body will typically reference a specific version in your certification documents, so it should be possible to say exactly which version was in force on a given date.
Update it when any of these happen:
A risk assessment adds, removes, or changes a risk that a control treats
The scope of the ISMS changes
A new legal, regulatory, or contractual requirement is identified
A control's implementation status changes
A previously excluded control becomes relevant, or the reverse
Review it in full at least as often as you repeat the risk assessment. A Statement of Applicability last edited before the previous audit is a strong signal that the risk process is not running.
Mistakes auditors find
These come up often enough to check for before your auditor does.
- Not done:
Every Annex A control is listed, including excluded ones
- Not done:
Every inclusion cites a risk or requirement, not the control's own wording
- Not done:
Every exclusion states a checkable fact
- Not done:
No exclusion rests on a provider without the supplier controls included
- Not done:
Every control not fully implemented appears in the risk treatment plan
- Not done:
Additional non-Annex A controls are listed if you use them
- Not done:
The document has a version, date, approver, and change history
For how the 93 controls are organized, see the Annex A themes explained. The ISO 27001 framework page summarizes the wider set of requirements.
How TrustLynce helps
TrustLynce builds your Statement of Applicability from your risk register and control set, with justifications, implementation status, and version history in one place. Each control links to its owner and its evidence, so the trace an auditor follows is already there.