The ISO 27001 Statement of Applicability: 93 controls and justified exclusions
The spreadsheet has 93 rows, one per Annex A control, and a column headed "Applicable?". Somebody has filled in 91 of them with Yes, because saying no felt like admitting a gap, and the two No answers have justifications reading "not relevant to our business".
Both halves of that are wrong, and the second is the one that produces a finding. An iso 27001 statement of applicability is not a compliance declaration. It is a record of decisions, and a decision without a reason is indistinguishable from not having decided.
What the iso 27001 statement of applicability is for
Three jobs, and it is the only document that does all three.
It records which controls apply. Which is a consequence of your risk assessment, not an independent judgement.
It justifies the exclusions. This is the part the standard specifically asks for and the part done worst.
It maps controls to implementation. So an auditor can go from "control 8.12 applies" to "here is how, and here is the evidence" without asking you.
The document that does all three is a table with six columns: control reference, control name, applicable yes or no, justification, how it is implemented, and where the evidence lives. Anything less and you will be answering questions verbally at Stage 2 that the document should have answered.
Excluding a control without getting a finding
An exclusion needs a reason that refers to something factual about your organisation. Compare these.
Bad: "Not relevant to our business." This states a conclusion with no premise. An auditor cannot verify it and will ask, at which point you are improvising.
Bad: "We are too small for this." Size is not a justification. Plenty of controls apply to a company of three.
Good: "No control applies because the ISMS scope excludes physical premises. All personnel work remotely and no company location stores or processes in-scope information. See scope statement section 2." That is checkable, it refers to another document, and it is consistent with the rest of your ISMS.
Good: "No software is developed for sale or distribution outside the organisation; the platform is operated as a service. Development controls are addressed under 8.25 to 8.31 for the platform itself."
The pattern: name the factual circumstance, refer to the document that establishes it, and where a related control does cover the risk, say which.
The exclusions that are usually genuine for a small remote-first SaaS company involve physical and environmental controls, physical media handling, and sometimes controls about development environments if you have a single one. The ones people wrongly try to exclude are supplier controls, because they feel like someone else's problem, and they are not.
Where the numbers come from
Annex A in the 2022 revision has 93 controls across four themes: organisational, people, physical and technological. That structure changed from the 2013 version's fourteen domains, and a template you find online may still be on the old structure, which will confuse an auditor and cost you an explanation.
Check the revision. The ISO 27001 standard is the authority, and the control text is copyright, which is why this note describes what controls are about rather than reproducing them. Your SoA should reference the control by number and name and describe your implementation in your own words, not paste the standard's text.
Keeping it in sync
The SoA is a document people write once and never update, which is exactly how it becomes a liability.
Three things have to stay consistent, and drift between them is what an auditor finds.
The risk register and the SoA. Every applicable control should trace to a risk that requires it, per the risk assessment note. A control marked applicable with no corresponding risk raises the question of why you selected it. A risk with no control is either accepted or untreated.
The SoA and reality. If the SoA says access reviews happen quarterly and they happen when somebody remembers, the SoA is now the document that proves you knew what you should be doing. That is worse than a gap: it converts an operational shortfall into a documented one.
The SoA and the evidence location. The sixth column should point somewhere that exists. A reference to a folder that was reorganised is the kind of small failure that consumes twenty minutes of an audit and undermines confidence in the rest.
Review it whenever the risk register changes materially, and formally at management review. Record the review date on the document itself.
The version that survives an audit
What works, and it is duller than most templates:
5.7 Threat intelligence Applicable
Justification: Risk R-04 (unpatched vulnerability exploited)
and R-11 (targeted phishing) require awareness of current threats.
Implementation: Vendor advisories and NCSC alerts monitored;
vulnerability data from Defender reviewed weekly.
Evidence: A-5-7_threat-review_YYYY-MM.md, weekly, in ISMS library.
7.1 Physical security perimeters Not applicable
Justification: ISMS scope excludes physical premises (scope
statement s.2). All personnel work remotely; no company location
stores or processes in-scope information. Cloud data centre
physical security is a provider responsibility, covered under
5.19 to 5.22 supplier controls and evidenced by the provider's
own certification.
The second one is doing real work. It excludes the control, states the factual basis, points at the document establishing it, and explains where the underlying risk is addressed instead. An auditor reading that has no follow-up question, which is the entire objective.
Partially applicable, and how to say it
Some controls apply to part of your scope and not the rest, and the binary column forces a choice that misrepresents the position.
The honest treatment is Applicable, with the boundary stated in the implementation column. For a control about secure development, if you build the platform but buy the corporate tooling, the control applies to what you build and the bought-in part is covered by supplier assurance. Writing that down is better than either a Yes that overclaims or a No that is wrong.
The same applies to controls you are part way through implementing at the time of Stage 1. Marking one Applicable while its evidence stream starts next month is fine, provided the treatment plan carries a date and an owner. What produces a finding is an SoA describing a control as implemented when Stage 2 samples it and finds three months of nothing.
So the practical rule: the SoA describes the intended state with dates, and the treatment plan carries anything not yet operating. Auditors are used to seeing a system mid-implementation at Stage 1. They are unforgiving about a document that claims a state the evidence contradicts, because that is a question about honesty rather than about maturity.
The mistake of marking everything applicable
Marking all 93 applicable feels safe and is the opposite.
Every applicable control is a control the auditor may sample, and for which you need an implementation and evidence. Ninety-three applicable controls means ninety-three things to evidence, forever, including the ones about physical media you do not have.
A well-justified exclusion reduces permanent workload and demonstrates that you understood the control rather than defaulting. Auditors read a thoughtful exclusion as competence. They read 93 out of 93 as a template nobody engaged with, and then they start sampling to find out which is true.
The book works through the SoA control by control, and the security and compliance work is the alternative if you would rather the first draft came from somebody who has defended one.