ISO 27001 Statement of Applicability: What It Is and How to Write It

The ISO 27001 Statement of Applicability is, in practical terms, the most strategically important document in the entire ISMS. It is the document that links the organization’s risk assessment to its control framework — translating the output of the risk identification process into specific, documented decisions about which of the 93 Annex A controls the organization will implement, which it will exclude, and why each decision is justified.

According to ISMS.online, the Statement of Applicability is one of the three documents most frequently cited in Stage 1 audit findings — alongside the risk assessment and the internal audit programme. The ISO/IEC 27001:2022 standard requires the SoA to contain not just inclusion/exclusion declarations but the specific justification for each decision and the implementation status of each applicable control.

For foundational context on the full controls framework, see our guide to the ISO 27001 controls list. For context on how the SoA fits within the broader ISMS, see ISO 27001 ISMS.

Tl; DR:

Concern: The ISO 27001 Statement of Applicability is one of the most commonly deficient documents in first-time certification audits — organizations frequently produce SoAs that are incomplete, unjustified, or disconnected from the risk assessment, resulting in major nonconformities that delay certification.
Overview: The ISO 27001 Statement of Applicability (SoA) is a mandatory document that lists all 93 Annex A controls, declares each as applicable or not applicable, provides documented justification for each decision, and records the implementation status of each applicable control. It is the bridge between the risk assessment and the control framework.
Solution: Organizations that build their SoA systematically — starting from the risk assessment output, reviewing every Annex A control rigorously, and documenting justification at the control level — produce a document that satisfies Stage 2 auditors and provides lasting ISMS governance value throughout the three-year certificate cycle. CertPro CPA LLC helps organizations build rigorous, audit-ready SoAs.

What Is the ISO 27001 Statement of Applicability?

The ISO 27001 SoA is a mandatory document required by ISO/IEC 27001:2022 Clause 6.1.3(d). The standard specifies that the SoA must contain:

• The necessary controls: All controls the organization has determined are necessary to address identified information security risks
• Justification for inclusions: Specific justification for each included control — referencing the risk assessment output, legal requirements, contractual obligations, or organizational policy
• Whether controls are implemented: The current implementation status of each applicable control — fully implemented, partially implemented, or planned
• Justification for exclusions: Documented justification for each Annex A control that has been excluded from the ISMS scope

The SoA is not simply a checklist. It is a governance document that must demonstrate that the organization has thoughtfully reviewed every Annex A control in the context of its specific risk profile, operational environment, and regulatory obligations.

ISO 27001 SoA — Required Structure and Content

How to Write the ISO 27001 Statement of Applicability — Step by Step

• Complete the Risk Assessment First: The SoA applicability decisions must flow from the risk assessment output — not the other way around. SoAs built before the risk assessment is complete produce unjustified decisions that auditors challenge during Stage 1. For a complete risk assessment methodology, see ISO 27001 risk management.
• Create the SoA Template: Build a structured document or spreadsheet with columns for each required element: control reference, control name, applicability decision, justification, implementation status, reference documents, and notes.
• Review Each Control Against the Risk Assessment: Work through all 93 controls systematically. For each control, ask: does our risk assessment identify risks this control addresses? Do any legal, regulatory, or contractual obligations require this control? Conducting ISO 27001 gap analysis alongside SoA development reinforces both processes.
• Write Specific Justifications: Generic justifications such as ‘applicable because it addresses information security risk’ are insufficient and will be challenged during Stage 1 audit. Effective justifications reference specific risk IDs from the risk register or specific legal obligations (e.g., ‘GDPR Article 32 requires encryption of personal data in transit — addresses RISK-014’).
• Record Accurate Implementation Status: Controls marked as ‘Fully Implemented’ must be demonstrably operational with evidence available for Stage 2 review. Organizations using automated evidence collection platforms find maintaining accurate SoA implementation status significantly easier.
• Cross-Reference to Implementing Documents: For each applicable control, add references to the specific policies, procedures, or technical configurations that implement it. See ISO 27001 policies and procedures and compliance documentation.
• Review and Approve: The SoA must be formally approved by appropriate management authority — typically the CISO or equivalent — and version-controlled with a documented review date.

ISO 27001 SoA — Justification Examples

Example 1 — Control Included: 8.8 Management of Technical Vulnerabilities

Justification: Risk assessment identifies RISK-007 (Ransomware via unpatched Windows Server vulnerabilities, Likelihood 4, Impact 5, Risk Score 20 — above acceptance threshold of 15). This control directly addresses the identified vulnerability exploitation pathway. Additionally, customer contract [Contract-A] requires monthly vulnerability scanning and 30-day critical patch SLA. Implemented via Tenable.io scanning platform and documented patch management procedure PM-001.

Example 2 — Control Excluded: 7.4 Physical Security Monitoring

Justification: The organization’s ISMS scope covers the design, development, and operation of the SaaS platform hosted on AWS eu-west-1. The organization does not operate any physical data centre facilities or server rooms within the ISMS scope. Physical security of AWS data centre infrastructure is governed under AWS’s own ISO 27001 certification. Physical security monitoring of the organization’s office premises falls outside the ISMS scope boundary.

Example 3 — Control Included: 5.23 Information Security for Use of Cloud Services (NEW 2022)

Justification: The organization uses AWS, GitHub, Slack, and Salesforce as critical cloud service dependencies within the ISMS scope. Risk assessment identifies RISK-031 (Cloud service provider misconfiguration or service failure, Likelihood 3, Impact 4, Risk Score 12). Implemented via Cloud Security Policy v1.2 and Supplier Assessment Procedure SP-003.

ISO 27001 SoA — Common Mistakes That Cause Nonconformities

• Building the SoA before completing the risk assessment: Applicability decisions made without a completed risk assessment cannot be properly risk-justified. Auditors trace every inclusion back to the risk register — if no corresponding risk exists, the justification fails.
• Using generic justifications: Every entry must contain a specific, referenced reason tied to the organization’s risk profile, regulatory context, or operational reality.
• Claiming full implementation for partially operational controls: Auditors cross-check every ‘Fully Implemented’ claim during Stage 2. Overstating implementation status is one of the most common generators of Stage 2 major nonconformities.
• Missing the 11 new 2022 controls: Organizations transitioning from 2013-era SoA templates frequently omit the 11 new controls. All 93 must be addressed. See the full ISO 27001 controls list.
• Failing to maintain and update the SoA throughout the certificate cycle: The SoA must remain current. When the organization’s risk profile changes, the SoA must be updated and re-approved.
• Excluding controls without adequate justification: An auditor who finds an excluded control that clearly addresses an identified risk will raise a nonconformity.

ISO 27001 SoA and the ISMS Scope — How They Connect

The ISMS scope and the SoA are closely linked. Controls are frequently excluded because the activity or asset they govern falls outside the ISMS scope boundary. For example, organizations whose ISMS scope covers only cloud-delivered SaaS services may legitimately exclude physical security controls (7.1–7.14) because they do not operate physical infrastructure within scope.

However, the scope exclusion must be accurately documented in the scope statement and consistently reflected in the SoA justifications. Scope and SoA exclusion justifications must be mutually consistent — auditors check both documents together during Stage 1. For guidance on building a scope definition that supports a defensible SoA, see ISO 27001 scope.

ISO 27001 SoA vs Risk Treatment Plan — The Relationship

The risk treatment plan and the SoA are distinct but closely connected documents. The risk treatment plan documents how the organization has decided to address each identified risk above the acceptance threshold — including the treatment option selected and the controls chosen to implement that treatment. The SoA documents the resulting control selection decisions across all 93 Annex A controls, with justifications.

In practice: the risk treatment plan drives the SoA (because risk treatment decisions determine which controls are selected), and the SoA references the risk treatment plan (because justifications for inclusions cite specific risk treatment decisions). Both documents must be internally consistent and mutually cross-referenced for Stage 1 audit. For internal audit programme guidance, see internal audit procedures.

Ready to Get ISO 27001 Certified?

CertPro CPA LLC is a licensed CPA firm delivering ISO 27001 certification audits. Work with credentialed auditors who understand your business environment.

Schedule your ISO 27001 certification discussion →

FAQ