.png)
%20(1).png)
.svg)
The short answer: The Statement of Applicability (SoA) is the document ISO 27001 clause 6.1.3 requires you to produce: a list of every Annex A control, whether it applies to your organisation, why it is included or excluded, and whether it is implemented. Under ISO 27001:2022 that means 93 controls across four themes. It links your risk assessment to the controls you operate, and it is the first document an auditor asks for at Stage 1 and the sampling list they work from at Stage 2.
Most SoAs start life as a spreadsheet: 93 rows, a justification cell that says "best practice" 80 times, and a version history recorded in file names ending _FINAL_v3. With the transition deadline of 31 October 2025 behind everyone, auditors expect an SoA that maps to the 2022 control set, reconciles with a current risk assessment and shows honest implementation status. The renamed spreadsheet does not survive that.
{{snapshot}}
The Statement of Applicability at a glance
- Mandated by clause 6.1.3(d). No SoA, no certificate. It is one of the few documents the standard names outright.
- 93 Annex A controls in four themes. Organisational (37), People (8), Physical (14), Technological (34). Every one needs a line, including the ones you exclude.
- Four facts per control. Applicable or not, the justification, implementation status, and what it traces back to: a risk, a law, a contract or a business decision.
- It is not the risk treatment plan. The SoA records which controls and why. The treatment plan records who does what by when. Auditors expect the two to reconcile.
- Checked at Stage 1, sampled at Stage 2. Many certification bodies print the SoA version and date on the certificate.
{{/snapshot}}
What the Statement of Applicability is, and what it is not
Clause 6.1.3 sets out risk treatment in five steps: select treatment options, determine the controls needed, compare them with Annex A to check nothing has been overlooked, produce a Statement of Applicability, formulate a risk treatment plan. The SoA is step four, and the order matters. It is an output of risk treatment, not a checklist you fill in before you have assessed anything.
Annex A is a reference list. You can source controls from NIST, Cyber Essentials or a customer contract, provided you compare the result against Annex A and justify any control you leave out. The clause 6.1 guide covers the full requirement, and clause 8.3 is where you prove you carried it out rather than planned to.
The SoA gets confused with two neighbouring documents. The risk treatment plan is the action list: which risks get treated, with which controls, by whom, by when. The SoA is the resulting state: the control is in, here is why, here is whether it works. Then there is the ISMS scope, which defines the boundary the SoA applies inside. Change the scope and the SoA changes with it: a physical control excluded for a fully remote firm stops being excludable the day you sign an office lease.
What an SoA must contain
The standard names four things: the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control. Everything else is convention, but the conventions exist because auditors ask the same follow-up questions every time. A usable SoA carries:
- Control reference and name, using the 2022 numbering (5.1 to 8.34).
- Applicable: yes or no.
- Justification for inclusion. A risk from your register, a legal obligation (UK GDPR, the Data Protection Act 2018), a contractual clause, or a documented business decision. "Best practice" alone tells an auditor you have not read your own risk assessment.
- Justification for exclusion, where applicable. Specific, and traceable to scope or context.
- Implementation status. Implemented, partially implemented, planned (with a date), or not applicable.
- Control owner, policy reference and evidence location. Not required by the clause, but the next three things the Stage 2 auditor asks for.
The inclusion column is where the risk assessment pays for itself. If risk R-014 (credential theft via phishing) is treated by controls 5.17, 8.5 and 6.3, those three SoA rows cite R-014. An auditor picking any control at random should be able to walk from the SoA to the risk register to the policy to the evidence. For a starting structure, the ISO 27001 SoA template is laid out this way with all 93 controls pre-loaded.
A worked Statement of Applicability example
An excerpt for a fictional 40-person UK consultancy: hybrid working, one London office, Microsoft 365 plus a dozen SaaS tools, client data under NDA, no in-house software development. Eight controls out of 93, chosen to show the range of decisions a real SoA makes.
| Control | Name | Applicable | Justification | Status |
|---|---|---|---|---|
| 5.1 | Policies for information security | Yes | Clause 5.2 requirement; top-level policy approved by the board and reviewed annually | Implemented |
| 5.7 | Threat intelligence | Yes | Risk R-003 (targeted phishing of client-facing staff); NCSC alerts and MSP threat feed reviewed monthly | Implemented |
| 5.23 | Information security for use of cloud services | Yes | Risks R-009 and R-011; all client data held in Microsoft 365 and two SaaS platforms; supplier assessment done, exit terms outstanding | Partially implemented |
| 6.7 | Remote working | Yes | Risk R-015; most staff work from home at least two days a week; remote working policy and MDM enforced | Implemented |
| 7.7 | Clear desk and clear screen | Yes | Risk R-015 and client NDA obligations; applies at the office and at home, enforced by automatic screen lock and annual policy attestation | Implemented |
| 8.9 | Configuration management | Yes | Risk R-021 (unmanaged laptop configuration); baseline to be applied through MDM with weekly deviation reports | Planned, Q4 2026 |
| 8.16 | Monitoring activities | Yes | Risk R-004 (undetected account compromise); Microsoft 365 audit logging and alerting reviewed by the MSP | Implemented |
| 8.28 | Secure coding | No | No software development takes place within the ISMS scope; all applications are procured SaaS, governed under 5.19 to 5.21 and 5.23 | Not applicable |
Three things to notice. Every included control cites a risk, a clause or a contract. The one exclusion explains what is absent (development) and where the related risk is handled instead (supplier controls), which is the shape every exclusion should take. And 8.9 is honestly marked as planned. An SoA that says "implemented" against all 93 controls is the most suspicious document an auditor can receive.
The four Annex A themes and the 11 new 2022 controls
ISO 27001:2022 reorganised Annex A from 114 controls in 14 domains into 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). Most of the change was merging and renaming. Eleven controls are genuinely new, and they are the ones that catch out an SoA lifted from a 2013 template:
- 5.7 Threat intelligence
- 5.23 Information security for use of cloud services
- 5.30 ICT readiness for business continuity
- 7.4 Physical security monitoring
- 8.9 Configuration management
- 8.10 Information deletion
- 8.11 Data masking
- 8.12 Data leakage prevention
- 8.16 Monitoring activities
- 8.23 Web filtering
- 8.28 Secure coding
If your SoA has 114 rows, or a row numbered A.12.1.2, the transition did not happen, whatever the file name says. Most UK organisations will find 5.23 and 8.16 applicable almost by definition, because they use cloud services and need to know when something goes wrong in them. Fully remote firms most often exclude 7.4; firms that do not write code exclude 8.28. The control set is published by ISO, and your numbering should match it exactly.
How to justify an exclusion without it coming back at Stage 2
Excluding a control is allowed, expected, and under-used. Small firms in particular treat every "No" as a confession and implement controls for risks they do not have. A nervous "Yes" with no evidence behind it is a non-conformity waiting to happen. The small business guide makes the same point about scope.
A defensible exclusion traces to something concrete: the scope statement, the risk assessment, or the plain absence of an activity. It names where the related risk is handled instead, and it is written down. "No development within scope" passes. "Not relevant to us" fails, and so does "our cloud provider handles this". If AWS or Microsoft does it for you, the control applies and you implement it through supplier management. That is an inclusion.
Two justifications get rejected every time. Cost ("we cannot afford data leakage prevention tooling") is accepted risk, and belongs in the risk register with an owner's signature. "IT already covers it" describes who implements the control, not whether it applies. Run a gap analysis before you draft the SoA so that the status column reflects what you found rather than what you hope.
How auditors use the SoA at Stage 1 and Stage 2
At Stage 1 the auditor reviews documentation. They check that the SoA covers all 93 controls, is approved and version-controlled, and reconciles with the scope, the risk assessment and the risk treatment plan. The commonest Stage 1 finding is a mismatch: a control marked applicable that no risk requires, or a risk treated by a control the SoA excludes. The Stage 1 versus Stage 2 explainer covers what each visit examines.
At Stage 2 the SoA becomes the sampling frame. The auditor picks controls marked applicable and implemented, then asks for the evidence that they operate: the access review, the log, the training record. "Implemented" with nothing behind it is a major non-conformity. "Planned" with a date and an accepted interim risk is usually fine if the treatment plan agrees.
CloudPass, a UK and EU access-control cloud provider, ran its ISMS from OneDrive folders and paid roughly £5,000 a year for consultants to visit twice a year and reconcile everything. After moving the whole system, SoA included, onto Hicomply, they went through audit with zero non-conformities. The security had not changed much. The traceability had.
Keeping the SoA live without a 93-row spreadsheet
The SoA is dated the day it is approved and out of date the day after. It changes when the scope changes, when the risk assessment is reviewed, when a new supplier or system arrives, when an incident shows a control was not working, and at least annually at management review. A document unchanged for two years tells a surveillance auditor the ISMS is a filing exercise.
The spreadsheet fails here for a structural reason. The SoA, the risk register, the policy set and the evidence folder are four files maintained by different people, and they drift. The fix is to generate the SoA from the control set rather than maintain it by hand. In Hicomply, the controls monitor holds each control's status, owner and evidence, and the SoA is generated from that data, so the document you hand the auditor is the current state, not a snapshot someone remembered to refresh.
{{snapshot}}
Hicomply's take
We have read a lot of SoAs, and the ones that fail share a tell: every control is applicable and every control is implemented. Auditors do not read that as diligence. They read it as a document written the week before the visit by someone who did not want an argument. Write fewer, better justifications. Cite the risk. Exclude what does not apply and say why in one sentence. Mark the honest status, including "planned": an SoA that admits three gaps with dates is more credible than one that admits none. Then stop maintaining it by hand.
{{/snapshot}}
Build your Statement of Applicability from your controls, not a spreadsheet
The SoA should be the easiest ISO 27001 document to produce, because everything in it already exists elsewhere in the ISMS: the controls, the risks they treat, the owner, the status. The work is keeping those joined up for a three-year certification cycle. That is a data problem, and spreadsheets are the wrong tool.
Try the free ISO 27001 SoA builder to draft your applicability decisions across all 93 controls, then book a demo to see the SoA generated from a live control set, with risks, policies and evidence attached to each row.
