The Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register

Ask a certification body which single document fails more Stage 1 audits than any other and the answer is the Statement of Applicability. Not because it is hard to produce — a spreadsheet with 93 rows takes an afternoon — but because the version most organisations produce is the wrong document. It lists every Annex A control, marks each one applicable, and types "best practice" or "industry standard" in the justification column. The auditor reads that in about four minutes and reaches a conclusion that no amount of policy writing will shift: the risk treatment process required by clause 6.1.3 never actually happened.

This article is about the Statement of Applicability — the SoA — as the standard means it: what it is for, what it must contain, how it is supposed to be derived, the four ways it fails, and how to build one that an auditor trusts. If you already run ISO 9001 it is the one genuinely new document in ISO/IEC 27001, so it is worth understanding properly before you open a template.

A note on sources. This article paraphrases ISO/IEC 27001:2022 clause 6.1.3 and the Annex A structure in plain English and reproduces no standard text. Work from your licensed copy of the standard (the SANS adoption is on the SABS webstore) and from ISO/IEC 27002:2022 for control guidance. Qlause is an independent training and templates provider, not a certification body.

What the SoA is, in one paragraph

The Statement of Applicability is the written record of which information security controls your organisation has decided it needs, why it needs each one, whether each is in place, and why any of the reference controls in Annex A were left out. It is the bridge between your risk assessment and your actual security measures. Clause 6.1.3 requires it; the certification body reads it before it reads anything else at Stage 1; and your certificate's scope is only as credible as the SoA behind it. Read the Explorer's page on clause 6.1.3 for the full requirement; this article is the practical version.

Where it comes from: the five steps of clause 6.1.3

The SoA is step four of a five-step process, and understanding the sequence is most of the battle.

1. Choose a treatment option for each unacceptable risk. Your risk assessment (clause 6.1.2) produced a register of risks scored against written criteria. Every risk above your acceptance threshold needs a decision: modify it with controls, retain it with a documented acceptance, avoid it by stopping the activity, or share it through insurance or a contract. Most risks are modified, which is where controls come in.
2. Determine all the controls necessary to implement those options. Note the direction: you start from the risk and ask what would reduce it. A control may come from anywhere — Annex A, ISO 27002's guidance, NIST, your sector's rules, your own invention.
3. Compare your chosen controls with Annex A. This is Annex A's actual job in the 2022 standard. It is a list of 93 reference controls you must check your selection against, so that nothing necessary is overlooked. It is not a list of mandatory controls and it is not exhaustive. If, after the comparison, a control in Annex A is not needed for any of your risks or requirements, you may exclude it — with a justification.
4. Produce the Statement of Applicability. Every necessary control, the justification for including it, whether it is implemented, and the justification for excluding any Annex A control.
5. Formulate the risk treatment plan and get it approved. Who implements which control by when, with what resources, to what residual risk — approved by the risk owners, who also formally accept the residual risks. Not the ISMS manager: the people who own the risks.

Steps one to three are the risk treatment process. Step four records it. An SoA produced without steps one to three is a list, and the auditor can tell.

What a compliant SoA contains

For each row — 93 Annex A controls plus any you added from elsewhere — the SoA records four things.

• Applicable or not. A yes or no. Most organisations end up with 80 to 90 of the 93 applicable; a 50-person services firm with no software development and a single office may legitimately exclude a dozen.
• Justification for inclusion. The reason the control is necessary — which risks it treats, or which legal, regulatory or contractual requirement demands it. "Treats risks R-014 (ransomware encrypts file server) and R-022 (laptop theft); required by customer security schedule, clause 7" is a justification. "Best practice" is not.
• Implementation status. Implemented, partially implemented, planned (with a date), or not implemented. This must be true when the auditor goes and looks.
• Justification for exclusion. For every Annex A control marked not applicable, a reason that survives a follow-up question. "A.8.4 Access to source code — not applicable: the organisation develops no software and holds no source code; spreadsheets with macros are covered under A.8.19" is a reason. "Not applicable" on its own is a finding.

Good SoAs add two more columns that the standard does not require but every auditor appreciates: a pointer to where the control is described (the policy or procedure) and a pointer to where the evidence lives (the register, the console, the log). Those two columns turn the SoA from a compliance artefact into the index of your ISMS.

The four ways an SoA fails Stage 1

1. Justifications not linked to risks

The classic failure, described above. The register and the SoA were built independently, often by different people, and the SoA's justifications mention no risk. The fix is mechanical: every inclusion justification must cite at least one risk reference from the register or one requirement from the legal and contractual register. If you cannot cite either, ask whether the control is actually necessary — or whether the risk register is missing a risk.

2. Exclusions with no reason, or the wrong reason

Auditors test exclusions deliberately, because a wrong exclusion is a gap in your security, not just in your paperwork. The reasons that fail are "not applicable" with nothing after it; "handled by our IT provider" (that makes the control applicable and shared, not excluded); and "no budget" (that is a planned control, not an inapplicable one). The reasons that pass describe why the risk the control addresses does not exist in your organisation.

3. Implementation status that is not true

The SoA says implemented; the auditor asks to see the access review from last quarter and there is none. In 2022 the SoA explicitly records whether each control is implemented, and auditors sample it against reality. Mark controls honestly. A planned control with a realistic date and a risk owner who has accepted the interim exposure is not a nonconformity; a false "implemented" is.

4. An SoA that was never updated

Risks change, controls are added, suppliers change, the cloud migration happens — and the SoA still carries the date of the certification audit three years ago. The standard treats the SoA as a living document that follows the risk assessment. Version it, date it, and update it in the same sitting as the risk register.

Annex A in 2022: what changed, and why it matters for the SoA

ISO/IEC 27001:2022 restructured Annex A from 114 controls in 14 domains into 93 controls in four themes — organizational (37), people (8), physical (14) and technological (34). Eleven controls are new, and these are where the gaps cluster in SoAs that were migrated from the 2013 edition by renumbering:

• 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

Each control in ISO 27002:2022 also carries five attribute tags — control type, security property, cybersecurity concept, operational capability and security domain. They are not required in the SoA, but they are useful in it: a column for the cybersecurity concept lets you show a NIST-speaking customer how your controls cover Identify, Protect, Detect, Respond and Recover without a second document. Every control page in the Clause Explorer shows its tags.

How to build an SoA that an auditor trusts

The method below assumes a risk register exists. If it does not, stop and build one first — the SoA cannot be derived from nothing.

1. Start from the risk register, not from Annex A. Add a column to the register: "controls that treat this risk". Fill it risk by risk in a workshop with the process owners. Name controls by Annex A number where they exist and by your own name where they do not.
2. Pivot the register into the SoA. A control is applicable because it appears against at least one risk, or because a legal or contractual requirement demands it. The justification writes itself: the list of risk references and requirement references.
3. Walk Annex A once for completeness. For each of the 93 controls not yet selected, ask: is there a risk in our register this would treat, or a requirement that demands it? If yes, you have found a gap in step one — add the risk and the control. If no, write the exclusion reason now, while the reasoning is fresh.
4. Record implementation status honestly and link each control to its policy and its evidence location.
5. Write the treatment plan in the same workbook — control, owner, date, resources, expected residual risk — and have each risk owner sign their rows. Keep the signed acceptance of residual risk with the SoA.
6. Version-control the SoA and update it whenever the register changes. Put "SoA current?" on the management review agenda.

The whole thing fits in one linked workbook for most organisations, which is why the compliance-automation platforms that charge from seven thousand dollars a year are not the only route. The Qlause Risk Assessment and SoA Toolkit is built on exactly this pattern — risks in, SoA out: a documented method, a register that takes both ways of finding risks, and a Statement of Applicability for all 93 controls whose suggested justifications are written from the register.

Two questions people always ask

Can we exclude a whole theme, such as all of A.8 Technological? No organisation that uses computers can. Even a firm that outsources all its IT still has user endpoint devices, authentication, malware exposure and backups to govern — shared with the provider, but applicable. What you can exclude are specific controls whose underlying risk does not exist, and the development controls (A.8.25 to A.8.31) are the usual candidates, with the caveat that in-house scripts, low-code apps and outsourced development bring them back into scope.

Is the SoA public? No. It is normally treated as confidential, because it describes your security posture in detail. Customers and auditors see it under agreement; the certificate they can see publicly carries the scope and the standard, not the SoA. Treat the document itself under your classification scheme — it is one of the records clause 7.5.3 asks you to protect.

Free download: the ISO/IEC 27001:2022 Gap Analysis Checklist

The checklist's Annex A tab is a working first draft of your SoA: all 93 controls with an Applicable? column, a status column, owners and dates, and a reason field for every exclusion, with the eleven new-in-2022 controls flagged. Its Summary tab counts your exclusions — each one needs a written reason — and the new controls still open. Enter your email below and it is on its way, and start from the risk register when you fill it in.

Qlause is an independent training and templates provider. It is not a certification body and this article is not a substitute for the standard. Sources: ISO/IEC 27001:2022 clause 6.1.3 and Annex A, ISO/IEC 27002:2022 (iso.org); Cyberday — the ten most common nonconformities in ISO 27001 audits (2025); Elevate Consult — fixing risk treatment issues before Stage 1 (2026); SureCloud — ISO 27001 implementation challenges (2026); Advisera — explanation of the eleven new controls.