What Is the Statement of Applicability?
The Statement of Applicability (SoA) is one of the few documents explicitly required by the ISO/IEC 27001:2022 standard. Clause 6.1.3(d) states that the organisation shall "produce a Statement of Applicability that contains: the necessary controls; justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls."
In plain terms: the SoA is a master register of all 93 ISO 27001:2022 Annex A controls. For each control, you state whether it applies to your organisation, justify the decision either way, and record implementation status. Your certification auditor will use it to verify that your risk treatment decisions are complete and defensible.
Get this document wrong and your audit will stall. Get it right and it becomes a useful internal management tool, not just an audit box-tick.
ISO 27001:2022 Annex A: 93 Controls Across 4 Themes
ISO 27001:2022 restructured the control set from 114 controls in 14 clauses (the 2013 version) to 93 controls in 4 themes. The 4 themes are:
- Organisational controls (A.5.x): 37 controls covering governance, supplier relationships, incident management, business continuity, and compliance
- People controls (A.6.x): 8 controls covering screening, employment terms, training, disciplinary processes, and remote working
- Physical controls (A.7.x): 14 controls covering physical perimeters, equipment, cabling, and disposal
- Technological controls (A.8.x): 34 controls covering access, malware protection, vulnerability management, encryption, and secure development
The 2022 version also introduced 11 new controls that didn't exist in the 2013 standard:
| Control | Title | Why It Matters |
|---|---|---|
| A.5.7 | Threat intelligence | Proactive threat awareness, not just reactive controls |
| A.5.21 | ICT supply chain security | SolarWinds/Log4Shell-type risks now explicitly in scope |
| A.5.23 | Cloud services security | Explicit cloud governance — critical for SaaS companies |
| A.5.30 | ICT readiness for business continuity | Separated from general BCP; ICT-specific continuity |
| A.7.4 | Physical security monitoring | CCTV, alarms, and premises monitoring |
| A.8.9 | Configuration management | Formalises IaC, hardening baselines, config drift detection |
| A.8.10 | Information deletion | GDPR Art. 17 alignment — right to erasure controls |
| A.8.11 | Data masking | Test data and analytics data protection |
| A.8.12 | Data leakage prevention | DLP tools, egress monitoring, sensitive data controls |
| A.8.16 | Monitoring activities | Anomaly detection, SIEM, behavioural monitoring |
| A.8.23 | Web filtering | DNS filtering, web proxies, malicious site blocking |
| A.8.27 | Secure system architecture | Security by design, threat modelling, architecture principles |
| A.8.28 | Secure coding | OWASP Top 10, code review standards, SAST integration |
The 4 Required Elements of Each SoA Entry
ISO 27001 clause 6.1.3(d) specifies exactly what the SoA must contain for each control:
- The control itself — identifying which of the 93 Annex A controls it refers to (control reference and title)
- Justification for inclusion — why the control is applicable (typically: risk treatment requirement, legal/regulatory obligation, or contractual requirement)
- Implementation status — whether the control is implemented (yes/no, or a more granular status like planned/partial/implemented)
- Justification for exclusion — if the control is not applicable, why not (and this justification must be defensible)
Many SoA templates only capture applicability and status. That's not enough. The justification columns are what auditors scrutinise.
How to Justify Excluded Controls (and What Auditors Check)
Excluding a control is not the same as ignoring a risk. ISO 27001 allows exclusions only when a control is genuinely not applicable — and the justification must demonstrate that the exclusion does not leave unacceptable residual risk.
Valid justification categories include:
| Justification Type | Example | Auditor Check |
|---|---|---|
| Activity does not exist | A.7.1 Physical perimeters — fully remote company with no office | Confirms no physical premises in scope; checks ISMS scope statement aligns |
| Cloud provider responsibility | A.7.11 Supporting utilities — cloud-hosted, AWS handles power/cooling | Checks AWS SOC 2 / ISO 27001 report covers this; checks no on-prem assets in scope |
| No relevant risk | A.5.32 IP rights — no software licences or IP in scope | Checks ISMS scope; verifies risk assessment supports the claim |
| Alternative control in place | A.8.11 Data masking — all test environments use synthetic data generation instead | Reviews the compensating control; checks it provides equivalent protection |
| Legal requirement doesn't apply | A.5.34 PII protection — ISMS scope excludes personal data processing | Reviews ISMS scope boundary; may request evidence of PII exclusion |
What auditors specifically check for exclusions:
- Is the justification substantive, or just "not applicable" with no reasoning?
- Does the ISMS scope statement support the exclusion?
- Does the risk assessment confirm the excluded risk is genuinely absent?
- Is the residual risk from the exclusion within the organisation's risk appetite?
- Was the exclusion decision approved by management?
The most common SoA audit failure: Marking a control as N/A without any supporting justification. "Not applicable" is not a justification; it's just a label.
Implementation Status: What to Use
ISO 27001 doesn't prescribe specific implementation status values, but a four-level scale is standard practice:
| Status | Meaning | Audit Implication |
|---|---|---|
| Planned | Control identified; implementation not yet started; documented in Risk Treatment Plan | Auditor checks action plan and target date exist; acceptable at Stage 1 audit |
| Partially Implemented | Control exists but gaps remain; documented remediation plan in place | Auditor reviews what's in place and whether the gap is risk-accepted or on a plan |
| Implemented | Control fully in place and operating | Auditor samples evidence to verify; looks for records, policies, configurations |
| Reviewed | Control implemented and verified effective through internal audit or management review | Strongest position; auditor may still sample but sees active oversight |
You do not need 100% "Implemented" to pass a certification audit. ISO 27001 certification requires that your ISMS is functioning — that risks are identified, controls are planned or in place, and the management system is operating. A handful of "Planned" controls with documented action plans is acceptable. A large number of "Planned" controls with no action plans is a nonconformity finding.
Physical Controls and Cloud-Native SaaS: What to Do
This is where most SaaS companies get stuck. ISO 27001 has 14 physical controls (A.7.x), and a cloud-native company with no office may reasonably exclude many of them. Here's a practical breakdown:
| Control | Cloud-Native SaaS Applicability | Suggested Justification |
|---|---|---|
| A.7.1 Physical perimeters | Usually N/A | No physical premises in ISMS scope. Data centres managed by AWS/GCP/Azure under their own ISO 27001 certification. |
| A.7.2 Physical entry | Usually N/A | As above — no physical premises. Cloud provider manages data centre entry controls. |
| A.7.3 Securing offices | N/A (no office) or Applicable (with office) | Organisation has no dedicated office space. Employees work remotely; A.6.7 covers remote work security. |
| A.7.4 Physical security monitoring | Usually N/A | No physical premises to monitor. Cloud provider data centres maintain CCTV and physical monitoring. |
| A.7.5 Physical/environmental threats | Applicable | Applies to cloud resilience, multi-AZ deployment, DRP covering environmental disruption. |
| A.7.7 Clear desk / clear screen | Applicable | Applies to all remote workers — screen lock policy, clean desk when in shared spaces. |
| A.7.8 Equipment siting | N/A if no on-prem | All server infrastructure is cloud-hosted. Control managed by cloud provider. |
| A.7.9 Assets off-premises | Applicable | Covers employee laptops, mobile devices used off-premises. |
| A.7.10 Storage media | Applicable | Covers employee laptops, USB drives (if used), mobile devices. |
| A.7.11 Supporting utilities | N/A if cloud-only | Cloud provider manages power, cooling, and supporting utilities at data centres. |
| A.7.12 Cabling security | N/A if cloud-only | No physical cabling in scope — all network infrastructure managed by cloud provider. |
| A.7.13 Equipment maintenance | N/A if cloud-only | Hardware maintenance is responsibility of cloud provider. Covered in supplier agreement. |
| A.7.14 Secure disposal | Applicable | Applies to employee laptops, mobile devices, external drives. NIST 800-88 disposal procedures apply. |
Critical: If you use co-working spaces regularly, A.7.1–A.7.6 may partially apply. Review your ISMS scope boundary carefully before excluding these.
The Relationship Between the SoA and the Risk Treatment Plan
The SoA and the Risk Treatment Plan (RTP) are two sides of the same document set. The RTP records which risks you've identified and how you've decided to treat each (mitigate, transfer, avoid, accept). The SoA records which controls you've selected to implement those treatment decisions.
Auditors will cross-reference them. If your RTP says "mitigate risk of unauthorised access" and your SoA marks A.5.15 (Access control) as "Not Applicable", that's a contradiction — and a major nonconformity finding.
The consistency check is: every risk in your RTP that is being mitigated should map to one or more applicable controls in the SoA. Every exclusion in the SoA should either have no corresponding risk in the RTP, or the risk is being accepted or managed through a compensating control.
Common SoA Mistakes (and How to Avoid Them)
| Mistake | Why It's a Problem | How to Fix |
|---|---|---|
| Bare "N/A" with no justification | Auditors cannot verify the exclusion decision is valid | Write a substantive justification for every excluded control |
| 100% "Implemented" across all controls | Implausible for any real organisation — auditors will look harder | Use accurate status levels; honest partial/planned is fine |
| SoA scope doesn't match ISMS scope | Controls included or excluded based on wrong scope boundary | Review SoA applicability against your clause 4.3 ISMS scope statement |
| Physical controls excluded without checking contractor/office use | Co-working spaces, shared offices, and contractor visits may bring physical controls back in scope | Check physical footprint before blanket N/A on A.7.x controls |
| New 2022 controls defaulted to N/A without review | A.5.23 (cloud services), A.8.9 (configuration management), and A.8.28 (secure coding) are almost universally applicable to SaaS | Explicitly review all 11 new 2022 controls — don't exclude them by default |
| SoA not updated after significant changes | Auditors check version history; an unchanged SoA suggests the organisation isn't managing its ISMS | Review and update the SoA at least annually and whenever scope or risk changes |
SoA Version Control and Change Management
The SoA should be version-controlled with a change log. Each version should record: version number, date, author, description of changes, and management approval. This demonstrates that the SoA is actively managed — not just created once and forgotten.
Triggering events for a SoA update:
- Annual ISMS management review
- Significant changes to the organisation (new product lines, acquisitions, new data processing activities)
- New risks identified in the risk assessment
- ISO 27001 standard update (the transition from 2013 to 2022 required SoA revision)
- After a significant security incident that reveals a control gap
Generate Your ISO 27001 SoA
Use the ISO 27001 Statement of Applicability Generator to create a complete SoA covering all 93 Annex A controls, with applicability decisions pre-populated based on your company profile (cloud-native SaaS, SaaS with office, hybrid, etc.) and customisable justifications and implementation status for each control.
Related generators: ISO 27001 Gap Assessment, Information Security Policy, Access Control Policy, Vulnerability Management Policy, Cryptography Policy.
Related reading: ISO 27001:2022 Annex A Controls: A Practical Guide for SaaS, ISO 27001 Gap Assessment Guide, ISO 27001 vs SOC 2: Which Does Your SaaS Need?.
⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. Your SoA should be reviewed by a qualified ISO 27001 lead implementer or certification auditor before use in a certification engagement.