--- title: "ISO 27001 Statement of Applicability, With Example" description: "What an ISO 27001 SoA must contain for all 93 controls, how to justify exclusions, a worked example, and the mistakes certification auditors find most." canonical: https://www.isosecurity.co.uk/resources/statement-of-applicability updated: 2026-11-10 --- # Statement of Applicability: the document your auditor will steer by The Statement of Applicability records your justified position on all 93 Annex A controls: which apply, why, and whether they are implemented. It is the single most scrutinised document at Stage 1, and the map your Stage 2 auditor follows. ## What must a Statement of Applicability contain? For every Annex A control, the SoA records whether it is included, why, and whether it is implemented. For any control you exclude, it records the justification for excluding it. Justifications must point somewhere real: a risk in your assessment, a legal obligation, a contractual requirement. A ticked list of the 93 control titles satisfies none of this. You may also include controls from outside Annex A, for example cloud-specific controls, and they belong in the same document. The Statement of Applicability is itself one of the [mandatory documents](/resources/iso-27001-mandatory-documents) ISO 27001 requires. ## What does a Statement of Applicability extract look like? The rows below are paraphrased examples in my own wording, showing the level of reasoning an auditor expects. Your version will have 93 rows and your own evidence. | Control area | Applies? | Justification | Status | | --------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Policies for information security | Yes | Required in all cases; underpins the management system and customer commitments | Implemented: policy set approved and reviewed annually | | Segregation of duties | Yes, proportionately | Risk: single-person approval of payments and access grants in a small finance function | Implemented: dual approval in the finance system, with a compensating review where headcount prevents full separation | | Secure development lifecycle | No | The organisation develops no software and operates no code pipeline; purchased platforms only. Supplier controls apply instead | Excluded: justification recorded, revisited if development is brought in-house | | Information security for cloud services | Yes | Core systems are SaaS and cloud-hosted; shared-responsibility boundaries must be defined per service | Implemented: responsibility matrix maintained for each significant provider | ## How do you build the Statement of Applicability? The order matters. Complete the risk assessment and treatment plan first, as my [risk assessment guide](/resources/iso-27001-risk-assessment) explains, and let the controls you select flow from the risks you accepted, treated or transferred. Where a risk demands a control that Annex A does not name, add it. Where an Annex A control addresses a risk you do not have, exclude it and say why. Auditors test this linkage at both [Stage 1 and Stage 2](/resources/iso-27001-stage-1-stage-2-audit). A SoA assembled from a downloaded grid usually comes apart in the first hour. ## Which Statement of Applicability mistakes do I see most? - **Exclusions without justifications**, or justifications that read "not applicable" with nothing behind them. - **"Implemented" claimed for controls with no evidence.** If you claim it, expect to be asked to show it. - **A frozen document.** New suppliers, systems and services change the answers; the SoA must change with them. - **Missing the 2022 additions:** threat intelligence, cloud services and ICT readiness are still commonly overlooked by organisations working from older templates. ## How do you keep the Statement of Applicability up to date? Version it, date it, approve it, and review it at least annually and whenever something material changes. At surveillance the auditor will compare the SoA against the controls you actually run. Keeping the two in step during the year, as my [maintenance guide](/resources/how-to-maintain-iso-27001-certification) sets out, makes that a short conversation. ## Frequently asked questions about the Statement of Applicability ### What is a Statement of Applicability in ISO 27001? It is the document that records your position on every one of the 93 Annex A controls: whether each applies to your organisation, why, and whether it is implemented, with the justification where a control is excluded. The certification auditor uses it to steer the Stage 2 audit, so derive it from your risk assessment and keep it current as controls change. ### Can we exclude Annex A controls in the Statement of Applicability? Yes, where the control genuinely does not apply: for example, secure development controls in an organisation that develops no software. Each exclusion needs a justification an auditor can test, and exclusions made for convenience are one of the most common Stage 1 findings. ### What does a good Statement of Applicability look like? One row per control with four honest entries: applicability, justification linked to a risk, contract or legal requirement, implementation status, and an owner. Version-control it, date it, approve it, and update it when your risks, systems or suppliers change. ## Contact Statement of Applicability not standing up? Arrange a readiness discussion: [contact ISO Security](/contact) or email info@isosecurity.co.uk.