ISO 27001 Statement of Applicability: how auditors read it
When your ISO 27001 certificate arrives, it will typically name two things: the scope of your ISMS and the version of the Statement of Applicability it was audited against. Not your policies, not your risk register. The SoA. It's the one document every stage of the audit is conducted against, the sampling frame your auditor works from at Stage 2, and the artefact most companies produce last, in a hurry, from someone else's template.
This piece is about doing it properly: what the SoA has to contain, how it connects to your risk assessment, and the specific ways auditors test it. If you're earlier in the process and want the full certification path first, start with our complete certification guide and come back.
The SoA is an output, not a checklist
The most common way to produce a bad SoA is to treat Annex A as a menu: open a spreadsheet with 93 rows, mark each control "applicable" or "not applicable", and call the result a Statement of Applicability. That gets the direction of the standard backwards.
Clauses 6.1.2 and 6.1.3 define the actual sequence. You assess your risks, choose treatment options, and determine the controls those treatments require. Only then do you compare your determined controls against Annex A, and the comparison runs as a completeness check, to verify you haven't missed a control your risks demand. The SoA is the document that records the outcome: every necessary control, the justification for including it, whether it's implemented, and the justification for every Annex A control you've excluded.
Two things follow from that sequence, and auditors test both.
First, your controls must trace to your risks. If your SoA says A.8.16 (monitoring activities) is applicable and implemented, somewhere in your risk register there should be a risk whose treatment relies on monitoring. An SoA whose inclusions can't be traced to the risk assessment reads as exactly what it usually is: a template filled in without reference to the business.
Second, Annex A isn't a ceiling. If your risk treatment requires a control that doesn't appear in Annex A (sector-specific obligations are the usual source), it belongs in your SoA too. Most SaaS companies never need this, but the auditor's question "did you determine your controls or just adopt the reference set?" is answered by whether your SoA shows any evidence of independent thought.
The 2022 revision of the standard restructured Annex A into 93 controls across four themes (organisational, people, physical, technological). If your SoA template has 114 rows in 14 clauses, it's built on the superseded 2013 control set; replace it before your Certification Body flags it.
Applicability and implementation are different questions
Each SoA row carries two separate judgements, and conflating them causes trouble in both directions.
Applicability is about your business, not your maturity. A.7.10 (storage media) is genuinely not applicable to a company with no removable media in scope. A.6.7 (remote working) is applicable to almost everyone since 2020, whether or not anything formal is in place. Marking a control "not applicable" because you haven't implemented it yet is the single most damaging SoA error: it converts an honest gap into a false statement, and auditors are practised at spotting it. The test for exclusion is whether the control's subject matter exists in your scoped environment at all, not whether you've addressed it.
Exclusions need written justification, and the justification needs to survive contact with your actual operations. "No physical offices in scope" is a defensible basis for excluding parts of the physical theme, right up until the auditor asks where the founders' laptops get repaired. Expect every exclusion to be probed. A short, factual justification grounded in how the business operates will hold; a one-word "N/A" will not.
Implementation status is the other axis, and it demands honesty. The standard explicitly allows the SoA to record controls as not yet implemented: the row points at your risk treatment plan, which shows the owner and the timeline. That's a coherent, auditable position at Stage 1. What's not coherent is an SoA that claims "implemented" for a control whose evidence doesn't exist. At Stage 2 the auditor samples controls from your SoA and asks for records. Every row marked implemented is a claim you've volunteered to prove.
The three-way consistency test
Auditors rarely fail an SoA for formatting. They fail it for inconsistency, and the inconsistencies they hunt live between three documents: the risk register, the SoA, and the evidence.
The sampling works in every direction. Pick a risk, trace it to its treatment, and check the controls that treatment requires appear in the SoA as applicable. Pick an SoA row marked implemented, and ask for the records that show the control operating. Pick an exclusion, and test the justification against what the business observably does. A few examples of how each direction goes wrong:
- Risk → SoA. Your register treats "unauthorised access to production" with role-based access control, but A.5.18 (access rights) sits in the SoA with a template justification that never mentions your environment. The control is probably fine; the SoA's account of it isn't.
- SoA → evidence. A.5.23 (cloud services) is marked implemented. The auditor asks for your supplier security assessments. There's a vendor list, but no assessment records. The claimed status was aspiration, and it's now a finding.
- Exclusion → reality. A.7.10 excluded on "no removable media", while the office runs weekly backups to a USB drive. One sentence of justification, contradicted by a walk past the server cupboard.
This is why template SoAs fail even when the underlying security is sound. The template's justifications describe a generic company; the auditor is comparing them against yours. Every mismatch costs credibility, and credibility is the currency that determines how deep the auditor decides to dig everywhere else.
The consistency requirement also runs into the clause-level machinery of the standard. Your internal audit (clause 9.2) and management review (clause 9.3) are expected to catch SoA drift before the external auditor does. An internal audit that never looked at the SoA is a common minor non-conformity in its own right.
The SoA moves when the business moves
Because the certificate typically references your SoA by version and date, the document has a lifecycle that outlasts the certification project. Surveillance audits, which run annually across the three-year certificate cycle, check that the SoA still describes the business being audited.
The changes that should trigger an SoA review are ordinary ones. A new critical supplier changes the supplier-management picture (A.5.19–A.5.22). Launching a mobile app or adding a data centre shifts applicability across the physical and technological themes. An incident that exposes an untreated risk feeds back through the risk assessment into new applicability decisions. Teams that treat the SoA as a certification deliverable rather than an operating document arrive at their first surveillance audit with a statement describing the company as it was eighteen months ago, and spend the audit explaining the differences one by one.
The pattern that avoids this is unglamorous: the SoA gets a named owner, applicability decisions get revisited whenever the risk register changes, and version history records what changed and why. The version history matters more than it looks. When an auditor sees an SoA that has moved three times in a year, each with a dated justification, they're looking at evidence the ISMS is alive. A document untouched since the last audit says the opposite.
How scoper.io builds the SoA
scoper.io generates the Statement of Applicability from the assessment rather than beside it. The platform interrogates your uploaded evidence against each Annex A control and produces cited verdicts; the SoA draws on that work directly. Applicability decisions and justifications sit per control, and implementation status reflects what the evidence assessment actually found: a status of "implemented" traces back to specific cited documents, not to a spreadsheet cell someone marked green in a hurry.
The consistency problems above are the ones the design targets. When your declared applicability disagrees with what your evidence shows (a control marked not applicable while relevant evidence sits in your vault), the platform surfaces the conflict for a human decision instead of letting the contradiction ride into the audit. And the finished SoA lands as a table in the assessor-ready dossier, alongside the gap analysis it's consistent with, because both were derived from the same underlying verdicts.
The applicability judgement stays yours, and so does the risk register: excluding a control is a decision about your business that you record with your justification. What the platform removes is the version of the job where you maintain the statement-to-evidence consistency by hand, and discover the mismatches when the auditor does. Those are the legs auditors sample hardest. There's more on the full assessment flow on the ISO 27001 product page.
The short version
The Statement of Applicability records the outcome of your risk treatment: every necessary control, justified inclusions, honest implementation status, and defensible exclusions, across all 93 Annex A controls plus anything your risks require beyond them. Auditors read it as the map of your ISMS and sample against it in every direction: risk to statement, statement to evidence, exclusion to observable reality. It fails on inconsistency, not formatting, and it keeps mattering after certification because surveillance audits test whether it moved when your business did.
If you want to see an SoA derived from your actual evidence rather than assembled in a spreadsheet, book a demo. We'll run the assessment against your documents and show you what comes out.
See it run on your own evidence.