Direct definition
What is an ISO 27001 Statement of Applicability?
The Statement of Applicability, often shortened to SoA, is the bridge between an organisation's information security risks and the controls it chooses. Under Clause 6.1.3 d), it contains the necessary controls and the reasons for including them, states whether they are implemented, and explains any exclusion of an Annex A control.
Input
Scope · risks · obligations
Decision
Necessary or not necessary
Record
Rationale · implementation status
Evidence
Owner · operating records · review
Purpose: make control selection explainable and auditable. The SoA is not a generic list of 93 security tasks. It records what this organisation needs for this scope, including any necessary controls that do not come from Annex A.
Visual preview · fictional worked example
A complete Annex A decision ledger
Paperbark Payroll is a fictional 100-person Australian B2B SaaS provider using Microsoft 365 and Azure. The downloadable example accounts for all 93 controls in the 2022 Annex A structure. Its single exclusion and every implementation claim are illustrative, not findings about a real organisation.
A.5
37
Organisational controls
A.6
8
People controls
A.7
14
Physical controls
A.8
34
Technological controls
| Control | Name | Applies | Example rationale | Status |
|---|---|---|---|---|
| A.5.1 | Policies for information security | Yes | The fictional organisation uses an approved ISMS policy set, published in its controlled document system and reviewed annually. | Implemented |
| A.5.23 | Information security for use of cloud services | Yes | Cloud services support the in-scope SaaS service, so onboarding covers shared responsibility, data location and exit planning. | Implemented |
| A.7.9 | Security of assets off-premises | Yes | The fictional remote-first workforce uses laptops and mobiles outside the office, so managed-device, encryption and remote-wipe controls are necessary. | Implemented |
| A.8.24 | Use of cryptography | Yes | Customer data needs protection in transit and at rest, with keys managed through the fictional organisation’s approved process. | Implemented |
| A.8.30 | Outsourced development | No | The example performs all development through employed engineers and reassesses this exclusion when its delivery model changes. | Not applicable |
Five rows are shown here for readability. The CSV and PDF contain all 93 Annex A controls. Blank owner fields in the downloadable example are prompts to assign your own accountable roles, not completed evidence.
Decision anatomy
The control row is the end of a trace, not the start
01
Scope
What the ISMS covers
02
Driver
Risk or requirement
03
Decision
Control needed?
04
Rationale
Why included or excluded
05
Operation
Status, owner and evidence
A useful SoA lets a reader move in both directions. From a risk, they can find the controls selected to treat it. From a control, they can find the reason it is needed, its current state and the evidence that shows it operates. This is why the SoA and information security risk register should be reconciled rather than maintained as unrelated files.
Adaptation instructions
Replace the example with owned decisions
- Define the ISMS scope before making applicability decisions. Name the products, services, teams, locations, technologies and interfaces inside the boundary.
- Bring together your risk assessment results and the legal, regulatory, contractual and business requirements relevant to that scope.
- Determine the controls necessary to treat risk and meet requirements, then compare that set with Annex A so no necessary control is overlooked.
- Record necessary controls that are not listed in Annex A as well. The Statement of Applicability is not limited to a copied Annex A catalogue.
- Write a specific reason for each inclusion and each Annex A exclusion. Link the reasoning to your risks, scope and applicable requirements.
- Record whether each necessary control is implemented, who owns it and where current evidence can be found. Keep planned work distinct from operating controls.
- Approve and version the document, then review it after scope, risk, supplier, technology or requirement changes and during the normal ISMS cycle.
Common mistakes
Where an SoA stops being defensible
Copying the fictional decisions
The worked rows describe a made-up SaaS environment. Your scope and risks may lead to different controls, rationales and implementation states.
Calling every Annex A control mandatory
Clauses 4–10 are the management-system requirements. Annex A is the reference set used to check the controls your organisation determines are necessary.
Confusing “not implemented” with “not applicable”
A necessary control that is still planned remains applicable. An exclusion needs a defensible reason why the Annex A control is not necessary in the defined scope.
Listing only controls that appear in Annex A
Necessary controls can come from risk, contracts, law, customer commitments or another control set. Include them even when Annex A has no identical entry.
Writing a control description instead of a rationale
Explain why the control is needed or why an Annex A control is excluded. Repeating the control title does not show the decision logic.
Letting the SoA drift from the risk register
Reconcile the documents in both directions. Risk treatments should lead to controls, while applicability decisions should trace to a real driver.
Version, author and review status
- Resource version
- 1.0
- Published
- 2 September 2026
- Author
- Aegentra Academy
- Standards basis
- ISO/IEC 27001:2022 and Amendment 1:2024
- Substantive reviewer
- Harry Sidhu · Director and Principal Consultant, Aegentra
- Substantive review date
- 2 September 2026
Substantively reviewed for source accuracy, control logic, limitations and download parity. Source links were checked when this version was prepared; standards status and source availability can change.
Limitations and use boundary
- This is Aegentra-authored educational material, not official PECB course material and not a reproduction of ISO/IEC 27001 or Annex A.
- The worked organisation, scope, risks, systems, controls, owners and implementation claims are fictional. They are not evidence about Aegentra or any client.
- A completed template does not establish conformity. Decisions must be supported by your approved scope, risk treatment, applicable requirements and operating evidence.
- The example is a starting structure, not legal advice, an internal audit, a certification opinion or a guarantee that a certification body will accept your ISMS.
- ISO standards are copyrighted. Obtain authorised copies and use their exact requirements when making consequential implementation or audit decisions.
Sources and learning pathways
The explanations above are plain-English paraphrases. Use the published ISO standard for authoritative requirements; the Auditing Practices Group note is supplementary educational guidance with its own stated status.
- [1]ISO/IEC 27001:2022 — Information security management systems — Requirements
Official ISO edition page for the current requirements standard and its amendments.
- [2]ISO/IEC 27001:2022/Amd 1:2024 — Climate action changes
Official amendment page for the added climate-action considerations in Clause 4.
- [3]ISO/IEC 27001 Auditing Practices Group — Statement of Applicability note
Educational practices note on necessary controls, Annex A comparison and SoA completeness. The note itself states that it is not endorsed by ISO or SC 27.
FAQs
It is the controlled record that states the controls the organisation has determined are necessary, explains why they are included, records whether they are implemented and justifies exclusions from ISO/IEC 27001 Annex A. It connects the organisation’s scope, risk treatment and applicable requirements to its chosen control set.
No. Every Annex A control must be considered when the organisation compares its necessary controls with Annex A, but a control can be excluded when it is not necessary and the exclusion is justified. A control cannot be excluded simply because it is difficult or has not yet been implemented.
No. Use the columns and decision pattern as a starting structure, then replace every applicability decision, rationale, status, owner and evidence reference with information from your own approved scope, risk treatment and requirements.