ISO 27001 Statement of Applicability
The Statement of Applicability is one table with 93 rows and four columns. It is the first document a stage 1 auditor opens, it sets the agenda for stage 2, and most of them are written in the wrong order.
The Statement of Applicability is the document required by clause 6.1.3 d) of ISO/IEC 27001:2022. For every one of the 93 Annex A controls it records four things: whether the control is necessary, why, whether it is currently implemented, and the justification for excluding it if you did. Any control you determined necessary that is not in Annex A goes in the same document, because Annex A is a reference set rather than a complete one. That is the whole requirement. Everything else on this page is about writing one an auditor can work with.
93 rows One per Annex A control, plus any control of your own
It is not a policy, it is not a risk register, and it is not a control matrix copied from a platform. It is the bridge between the two: the risk assessment says what could go wrong, the risk treatment plan says what you are doing about it, and the Statement of Applicability records which controls that decision landed on and why. Written in that order it takes a day. Written first it takes a quarter, twice.
The four columns, and what each one is for
| Column | What clause 6.1.3 wants | What auditors actually read it for |
|---|---|---|
| Control reference and title | Identifies the control, for example A.5.7 Threat intelligence | Completeness. All 93 present, using the 2022 numbering. |
| Necessary, yes or no | The determination required by 6.1.3 c) and d) | Whether the answer is consistent with the scope statement and the risk treatment plan. |
| Justification | Why the control is included, or why it is excluded | Whether the reason points at a risk, an obligation or a contract, rather than restating the control title. |
| Implementation status and reference | Whether it is implemented, and where the evidence lives | The stage 2 sampling plan. Every "implemented" is a request for evidence. |
Two columns are worth adding even though the standard does not require them. A risk identifier, so a reader can trace the control back to the risk that justified it without asking you, and an owner, so the auditor knows who to interview. Both save time in an audit that is billed by the day.
What good and bad rows look like
The justification column is where Statements of Applicability are won and lost. These rows are illustrative rather than taken from a real client document.
| Control | Weak justification | Defensible justification |
|---|---|---|
| A.5.7 Threat intelligence | Good practice | Risk R-14, exploitation of a known vulnerability in an internet-facing service. Vendor advisories and CVE feeds reviewed weekly, output feeds the patching schedule. |
| A.5.23 Information security for use of cloud services | We use the cloud | The whole product runs in one cloud account. Risk R-03 and the customer contract clause on subprocessors both land here. |
| A.8.10 Information deletion | Implemented | Required by the retention schedule and by access requests under the applicable privacy statute. Deletion runs on a documented schedule with a quarterly check. |
| A.7.1 Physical security perimeters | Not applicable, we are remote | Excluded. No premises are inside the scope statement. Data centre perimeters are managed by the cloud provider and covered under A.5.23, evidenced by their own certification. |
| A.8.11 Data masking | Not applicable | Excluded. Production data is never copied to non-production, enforced by separate accounts and checked in the quarterly access review. See risk R-09. |
Never write "not applicable" on its own
An exclusion with no reasoning is the single most common finding raised against this document. The auditor cannot verify a decision you did not record, so the finding writes itself. The test they apply is whether the exclusion follows from the scope statement or the risk assessment. If it follows from the budget, it is not an exclusion, it is an unimplemented control, and saying so honestly costs you far less than being caught.
Why the order of work decides the quality
The justification column can only be written after the risk work, because its content is the risk work. A Statement of Applicability produced before the risk assessment has nothing to put in that column except a restatement of the control title, and a stage 1 auditor spots that in about ten minutes across ninety-three rows. The sequence that works is the one clause 6.1 sets out.
- Write the scope statement, because exclusions are argued from it.
- Build the asset, data and supplier inventory.
- Run the risk assessment and give every risk an owner and an identifier.
- Decide the treatment for each risk. This is the step that names controls.
- Walk all 93 Annex A controls as the completeness check clause 6.1.3 c) asks for, and add anything the treatment plan missed.
- Write the Statement of Applicability from the treatment plan, carrying the risk identifiers across.
- Get it approved, put it under version control, and treat every later change as a change to a controlled document.
The five ways this document gets you a finding
All five are avoidable and all five are common. Work through them before you hand the document to a certification body.
The third one deserves its own sentence. Marking a control implemented when it was approved but never turned on is worse than admitting a partial state, because it is a nonconformity against your own management system rather than a gap in your controls. Auditors sample the implemented rows. An honest "planned, target date, owner" row costs you nothing at stage 1 and gets you a conversation instead of a finding.
What the auditor does with it
At stage 1 the Statement of Applicability is most of the reading. The auditor compares it against your scope statement, your risk treatment plan and your policy set, and writes down the questions for stage 2. Every exclusion is a question they have already prepared. Every control marked implemented is a request for evidence they may or may not use.
At stage 2 it becomes the sampling plan. That is the practical reason not to over-claim: a document that says everything is implemented invites evidence requests across all four themes, while an honest one focuses the auditor on what you can show. The full sequence of stage 1 and stage 2 is on the certification process page, and what happens to the document in years two and three is on surveillance audits.
Spreadsheet, platform, or the tool below
A spreadsheet is completely adequate, and plenty of certified companies use one. What matters is that it is version controlled, approved, and that the justification column contains sentences rather than ticks. A compliance platform generates the document from its own control mapping, which saves typing and produces a generic justification column that then has to be rewritten. Treat the generated version as a starting draft, not a deliverable.
If you have not started, the Annex A control selector works through the questions that decide which controls are in play for your scope and prints a first pass at the necessary and excluded split. The gap assessment scores where you sit against the four themes and the clause requirements.
Get someone to review yours before the auditor does
Tell us your scope and where you are, and we will match you with Canadian firms that do ISO 27001 readiness work.
Get matchedCommon questions
Is the Statement of Applicability mandatory?
Yes. Clause 6.1.3 d) requires it by name, and it is one of the documents a certification body will ask for before stage 1. There is no version of an ISO 27001 certification that does not include one.
How many controls have to be marked applicable?
There is no minimum. The standard asks you to decide, not to hit a number. In practice most Canadian organizations end up with the large majority of the 93 applicable, because the annex is written broadly and few controls are genuinely irrelevant to a company with staff, suppliers and software.
Can we exclude a control because we cannot afford it?
No. Cost is not a justification the standard recognises, because exclusion means the control is not necessary to treat your risks. What you can do is record the control as applicable and not yet implemented, with an owner and a target date. That is a normal state for a management system and it is far safer than an exclusion an auditor will reject.
Does the Statement of Applicability go to customers?
It can, and enterprise buyers increasingly ask for it rather than the certificate, because the certificate says nothing about scope or exclusions. Decide in advance whether yours is written to be read outside the company. Most are not, and a redacted version prepared once is better than an argument during a deal.
How often does it have to be updated?
Whenever the risk assessment, the scope or the control set changes, and at minimum it should be reviewed as part of the annual cycle before each surveillance audit. A document whose version date is two years old tells a surveillance auditor that the management system has not moved, which is itself a finding.
Is it the same as a SOC 2 control matrix?
No. A SOC 2 report describes controls you wrote against the trust services criteria, and there is no fixed reference set to exclude from. The Statement of Applicability is a decision record against a published list of 93 controls. They overlap in content and not in purpose, which is covered on the comparison page.