In ISO/IEC 27001:2022, what does the Statement of Applicability contain, and how do you justify excluding an Annex A control?
answer
- one row per Annex A control
- included, why, implemented?
- exclusion needs a reason
- reason comes from risk or scope
- auditor reads it first
basics
~20 sThe Statement of Applicability lists the necessary controls, why each is included, whether it is implemented, and why any Annex A control is excluded. An exclusion is justified by the risk assessment or scope showing no risk the control would treat.
solid answer
~50 sThe **Statement of Applicability (SoA)** is a required ISMS document produced during risk treatment. For each of the 93 Annex A controls, plus any additional controls, it records: whether the control is **necessary**, the **justification for inclusion** (usually the risks it treats, or a legal or contractual requirement), whether it is **implemented**, and the **justification for excluding** any Annex A control. A sound exclusion traces to the risk assessment or the scope: Annex A 8.30 *Outsourced Development* can be excluded by a SaaS company that does no outsourced development, if that is true and stays true. A weak exclusion is "not relevant" with no reason, or excluding a control because it is hard — excluding 8.28 *Secure Coding* at a company that writes its own product would not survive the audit. Auditors read the SoA first and use it to plan what they test.
go deeper
Recall the four elements of an SoA row and that it covers all 93 Annex A controls in four themes.
Explain how an exclusion is justified from scope and risk, and how applicable-but-planned differs from excluded.
Show how you would defend a contested exclusion in an audit and keep SoA, risk register and treatment plan consistent as scope changes.
Discuss how the SoA doubles as the customer-facing statement of control coverage and how much of it to share in security questionnaires.
## What the Statement of Applicability is The **Statement of Applicability (SoA)** is one of the documents ISO/IEC 27001 explicitly requires. It is produced during risk treatment and links three things: the organization's **risks**, the **controls** it has chosen to treat them, and the reference set in **Annex A**. Certification auditors use it as their map: it tells them which controls to test and where to look. ## What each row contains | Element | Meaning | Example | |---|---|---| | **Control** | An Annex A control, or an additional control the organization chose | 5.23 *Information Security for Use of Cloud Services* | | **Applicable?** | Is it necessary to treat the risks in scope? | Yes | | **Justification for inclusion** | Risks treated, or legal, contractual or business requirements | Production runs on third-party cloud infrastructure; risks R-07, R-12 | | **Implementation status** | Implemented, partly, planned | Implemented | | **Justification for exclusion** | Why an Annex A control is not needed | — | Many organizations add a pointer to the policy or procedure that implements the control, which makes the audit faster. ## The 93 controls it covers In the 2022 edition Annex A has **93 controls** in four themes: - **Organizational** — 5.1 to 5.37, 37 controls (policies, roles, supplier relationships, incident management, cloud services, continuity). - **People** — 6.1 to 6.8, 8 controls (screening, awareness and training, remote working). - **Physical** — 7.1 to 7.14, 14 controls (perimeters, monitoring, clear desk, equipment disposal). - **Technological** — 8.1 to 8.34, 34 controls (authentication, logging, backup, cryptography, secure development). ## Justifying an exclusion An exclusion is sound when it follows from facts about the scope and the risk assessment: 1. **No activity** — Annex A 8.30 *Outsourced Development* excluded because no development is outsourced; the auditor may check contracts to confirm. 2. **No asset in scope** — some physical controls may be excluded or limited when the scope contains no premises of the organization's own, provided home working and the hosting provider's facilities are covered through 6.7 *Remote Working* and supplier controls. 3. **Risk below acceptance criteria** — an exclusion tied to an assessed risk the owner has accepted, documented in the register. An exclusion is weak when it says only "not applicable", when it contradicts the scope (excluding 8.28 *Secure Coding* at a company that builds software), or when it is really "not implemented yet", which belongs in the status column and the treatment plan, not the exclusion column. ## A 250-person SaaS company's first SoA - Fully remote, production in a public cloud, no office servers. - 7.1 *Physical Security Perimeters*: applicable only to a small shared office for device storage; the hosting provider's data-centre perimeter is covered through supplier assurance. - 7.7 *Clear Desk and Clear Screen*: applicable, implemented through device policy for home workers. - 8.30 *Outsourced Development*: excluded, none performed; to be revisited if contractors are engaged. - 5.7 *Threat Intelligence*: applicable, partly implemented, on the treatment plan. ## How auditors use it - At **stage 1** they check that the SoA exists, covers all 93 controls and that exclusions are justified. - At **stage 2** and surveillance audits they pick controls marked implemented and test that they operate. - A control marked implemented that is not operating is a finding; so is a necessary control that was excluded. ## Keeping it current The SoA is versioned and approved. It changes when the scope changes, the risk assessment is repeated, or a treatment plan item is completed, and inconsistencies between SoA, risk register and treatment plan are among the most common audit findings.
- Can a control be marked applicable but not yet implemented at certification?Yes. The Statement of Applicability records implementation status, and a control can be planned with a date in the risk treatment plan and the risk owner's acceptance of the residual risk meanwhile. Auditors expect the plan to be credible and progressing; a necessary control that is neither implemented nor planned, or a plan that never moves, is likely to be a finding.
- Must the Statement of Applicability list controls beyond Annex A?It must list all necessary controls, and ISO/IEC 27001 allows organizations to design or take controls from any source. Annex A is a reference to check that nothing necessary is missed, not a closed list, so a SaaS company might add a control for tenant isolation testing and include it with its justification.
The SoA is like a building inspector's checklist that the owner fills in: every item is ticked as present, planned, or not needed with a reason. The inspector starts from the reasons, because 'not needed' is where corners get cut.
saying these in an interview costs you the question
- The Statement of Applicability lists only the controls that are implemented.
- 'Not applicable' needs no further explanation in the SoA.
- A control that is not implemented yet should be marked as excluded.
- The SoA may only contain Annex A controls.
- Physical controls can always be excluded by a fully remote company.