# The ISO 27001 Statement of Applicability What clause 6.1.3 d) requires in an SoA, how to justify inclusions as well as exclusions, and what a certification auditor checks in it. Source: https://sted.digital/docs/standards/iso-27001/statement-of-applicability · Last reviewed 17 October 2026 · Strand Standards and regulations The Statement of Applicability (SoA) is the ISO 27001 document that lists every control your risk treatment needs, says whether each is implemented, and justifies both why each is included and why any Annex A control is excluded. ISO 27001:2022 6.1.3 d) requires it, and certification auditors use it as their map of your controls. ## The requirement in plain English Clause 6.1.3 asks you to choose risk treatments, then determine every control those treatments need (ISO 27001:2022 6.1.3 b)). You may design controls yourself or take them from any source. You then compare your list with [Annex A](/docs/glossary/annex-a) to check you have not missed a necessary one (ISO 27001:2022 6.1.3 c)). The [Statement of Applicability](/docs/glossary/statement-of-applicability) records the outcome (ISO 27001:2022 6.1.3 d)). It must contain: - the necessary controls, from Annex A or elsewhere; - the justification for including each of them; - whether each is implemented or not; - the justification for excluding any Annex A control. So every one of the 93 Annex A controls appears, either as included with a reason or excluded with a reason, plus any controls of your own. The SoA is documented information, and because it is the record of your control decisions, it changes whenever the risk treatment does. The SoA is not the scope statement. The scope says what the ISMS covers; the SoA says which [controls](/docs/glossary/control) apply inside that scope. This is guidance to help you understand the requirement, not legal advice. ## What good looks like A 20-person data analytics company keeps its SoA as a table of 93 Annex A rows plus three of its own: a contractual control from its largest customer requiring quarterly access attestations, a control on use of AI coding assistants, and one on customer data in demo environments. Each row carries the control, applicable or excluded, the justification, the implementation status, the owner and where the evidence lives. Inclusion justifications point to something an auditor can check: risk IDs from the register, a named contract clause, a law. Exclusions are few and specific. "No premises of our own; staff work from home; covered by remote working and endpoint controls" excludes the premises monitoring control (ISO 27001:2022 Annex A 7.4) with a reason that holds. Nothing is excluded only because a supplier runs it. The cloud services control (ISO 27001:2022 Annex A 5.23) is applicable, with the evidence being the provider's assurance reports and the company's own configuration reviews. The SoA carries a version number and an approval date. The security lead updates it after every risk reassessment, and top management reviews the changes at [management review](/docs/glossary/management-review) (ISO 27001:2022 9.3). The certification body is told when it changes, because the certificate usually refers to a specific SoA version. ## Evidence an auditor expects - **The SoA itself** (required documented information): the auditor checks all four elements of 6.1.3 d) are present for every row, and that every Annex A control appears. - **Traceability to risk treatment**: the auditor picks a risk from the register and expects to find its controls in the SoA, then picks a control and expects to find the risk or requirement behind it. - **Exclusion reasons**: each one tested against the scope and the business; an exclusion contradicted by what the auditor sees on site is a nonconformity. - **Implementation status**: sampled against reality, for example a control marked implemented with no evidence behind it. - **Version and approval history**: the auditor checks the SoA reviewed at stage 2 is the one on the certificate, and that changes since have been approved. ## Common mistakes ### Justifying only the exclusions Many SoAs leave the inclusion column blank, or write "applicable" in it. The 2022 wording asks for the justification for inclusion too. Reference the risk, contract or law for each. ### "Not applicable, outsourced" Using a cloud provider does not make a control inapplicable; it changes how you meet it. The auditor will ask how you assure the supplier's part and what you configure yourself. Keep the control, and record the shared responsibility. ### An SoA that does not match the risk register The SoA was built from a template and the register later, so they disagree: controls with no risk behind them, or risks treated by controls marked excluded. Build both from the same treatment decisions and check traceability both ways. ### Implemented on paper Marking every control implemented on day one invites the auditor to test the weakest one. Use honest statuses; a control in progress with a date in the treatment plan is acceptable. ### Forgetting the version on the certificate An SoA changed after certification without telling the certification body leaves the certificate pointing at an old version. Version the SoA, record each approval, and inform the certification body of significant changes. ## How Sted helps Sted keeps a Statement of Applicability for each adopted standard with a control catalogue. Only standards with a control catalogue get a Statement of Applicability card. Each Statement of Applicability card on the Summary lists the standard's controls by theme as Applicable, Excluded or Not addressed, with any exclusion reason, the implementation status and when each was last verified; below administrator it is marked as a partial view, and its PDF needs a paid plan. You can exclude a control with a coded reason and justification and record its implementation status. An excluded control needs one of nine coded reasons, Other needs a written justification, and an excluded control counts as decided for audit readiness; a document's controls cannot be decided while a newer draft of it is in progress. Only administrators can export the SoA as a PDF, because only their view is complete. Readiness counts four kinds of item per adopted standard (each linked document approved; its requirements for that standard adopted or excluded with a reason; at least one closed record per record template; each assigned person's training completed), counts an item shared by two standards once overall, and reads 0% for a standard with nothing linked. Sted builds the SoA from your adopted documents and records each exclusion. Whether a decision is right is for your risk owners, and in the end the certification auditor, to judge. ## Related guides and terms - [How to write a Statement of Applicability](/docs/guides/statement-of-applicability): the step-by-step guide. - [Risk assessment and treatment](/docs/standards/iso-27001/risk-assessment-and-treatment): the decisions the SoA records. - [The Statement of Applicability in Sted](/docs/product/statement-of-applicability): reading the card, deciding a control and exporting the PDF. - [ISO 27002 and how it relates to ISO 27001](/docs/standards/iso-27001/iso-27002): the guidance behind each Annex A control. - [Statement of Applicability](/docs/glossary/statement-of-applicability): the term in one paragraph. - [ISO 27001 Annex A physical controls](/docs/standards/iso-27001/annex-a-physical-controls): the theme most exclusions come from, and the controls that still follow your laptops. ## Frequently asked questions Q: Do I need to justify the controls I include, or only the ones I exclude? A: Both. Clause 6.1.3 d) asks for the justification for including each necessary control as well as for excluding any Annex A control. A short reference to the risk, contract or law behind each inclusion is enough. Q: Can a control be applicable but not yet implemented? A: Yes. The SoA records whether each necessary control is implemented, so an applicable control that is still in your treatment plan is honest and acceptable. A certification auditor will expect the plan to show when it will be in place. Q: Can I add controls that are not in Annex A? A: Yes. Annex A is not exhaustive, and the controls your risk treatment needs may come from a customer contract, another framework or your own design. List them in the SoA with the same justification and status as the Annex A ones.