# ISO 27001 Statement of Applicability
The Statement of Applicability (SoA) is the document that transforms ISO 27001 from a generic framework into an organization-specific security program. It is both a compliance artifact and an operational decision record, capturing which of the 93 Annex A controls an organization has chosen to implement, which it has excluded, and the precise reasoning behind every choice.
The SoA exists because ISO 27001 operates on a risk-based approach rather than a prescriptive compliance model. Unlike frameworks such as SOX or PCI DSS that mandate specific controls for all covered organizations, ISO 27001 provides a menu of 93 controls and requires each organization to determine which controls are applicable to its risk profile, business context, and operational environment. This flexibility is both the standard's strength and its complexity.
Under ISO/IEC 27001:2022 Clause 6.1.3(d), the SoA is a mandatory deliverable that must contain four elements: the controls determined to be applicable, justification for their inclusion, justification for the exclusion of any omitted controls, and the implementation status of each applicable control. The document serves as the bridge between the organization's Information Security Risk Assessment and its Risk Treatment Plan, translating identified risks into specific control decisions.
The SoA fits within the broader ISO 27001 framework as the outcome of the risk assessment process and the input to ongoing control implementation and monitoring. Without a credible SoA, an ISO 27001 certification audit cannot proceed. With a well-constructed SoA, an organization has a defensible, traceable map connecting identified risks to implemented controls, giving auditors, executives, regulators, and counterparties a clear view of the organization's security posture and the logic behind it.
The 2022 revision of ISO 27001 reorganized the 93 Annex A controls into four thematic categories: Organizational Controls (37), People Controls (8), Physical Controls (14), and Technological Controls (34). This reorganization affects how organizations structure their SoA but does not change the fundamental requirement to address every control with either an inclusion or exclusion decision.
Constructing a credible SoA is a multi-phase process that requires systematic analysis of risk assessment results, business context, legal obligations, and technical architecture. The process follows a defined sequence that cannot be shortcut without creating audit vulnerabilities.
Phase 1: Risk Assessment Foundation
The SoA cannot be written before completing the Information Security Risk Assessment under Clause 6.1.2. The risk assessment identifies threats, vulnerabilities, and impacts that apply to information assets within the defined scope. This output directly informs control applicability decisions. For example, a software company with cloud-hosted services and no physical data centers will find that physical security controls such as A.7.1 (Physical security perimeters) may be inapplicable, while cloud-specific controls such as A.5.23 (Information security for use of cloud services) are highly relevant.
The risk assessment must be granular enough to support control-level decisions. Generic risk statements such as "unauthorized access to data" are insufficient. Specific risk scenarios such as "unauthorized access to customer payment data through compromised administrative credentials in the billing system" provide the detail needed to evaluate which authentication, access control, and monitoring controls are applicable.
Phase 2: Control-to-Risk Mapping
For each identified risk, the organization selects one or more Annex A controls as part of its risk treatment approach. This mapping creates audit traceability. If an auditor asks why control A.8.12 (Data leakage prevention) is included, the answer must reference specific risks in the risk register such as "exfiltration of source code through unauthorized file transfers" or "accidental disclosure of customer data through misconfigured cloud storage."
The mapping works in reverse as well. Every included control must trace back to at least one identified risk or legal requirement. A control included without corresponding risk justification signals that the SoA was assembled as a compliance exercise rather than built from actual security analysis. Auditors recognize this pattern and probe it aggressively during certification audits.
Phase 3: Systematic Control Review
The SoA must address all 93 Annex A controls, including those excluded from implementation. For excluded controls, the organization must document a valid justification falling into one of three categories: the risk addressed by the control does not exist within the organizational scope; the risk is addressed through an alternative control that achieves equivalent protection; or the operational context makes the control inapplicable.
Valid exclusion examples include a fully remote organization excluding A.7.3 (Securing offices, rooms and facilities) because no company-controlled physical premises exist, or a software vendor excluding A.8.31 (Separation of development, testing and operational environments) because the organization only develops software for external customers and does not operate production systems containing regulated data.
Invalid exclusions cite resource constraints, cost considerations, or implementation difficulty. These justifications will result in audit non-conformances because ISO 27001 requires organizations to implement controls necessary to address identified risks regardless of resource limitations.
Phase 4: Implementation Status Documentation
For each included control, the SoA records whether implementation is complete, partial, or planned. This status must reflect operational reality, not aspirational goals. A control listed as "implemented" must have verifiable evidence of operation. Controls with "partial" or "planned" status require associated timelines in the Risk Treatment Plan.
Implementation status affects audit scope. Auditors will test all controls marked as implemented and will verify that partially implemented controls have documented remediation plans with realistic timelines. Controls showing "planned" status for extended periods without progress will attract scrutiny during surveillance audits.
Phase 5: Evidence Linkage
Best-practice SoA construction includes references to specific evidence artifacts demonstrating control implementation. For example, control A.5.1 (Policies for information security) might reference the organization's information security policy document, the board resolution approving the policy, and the communication records showing policy distribution to staff.
This evidence linkage is not required by ISO 27001 but dramatically improves audit efficiency. Auditors can quickly locate relevant evidence rather than spending time identifying what documents support each control claim. Organizations without evidence linkage typically spend significant audit time reconstructing the connection between SoA entries and supporting documentation.
Practical Example: Financial Services Implementation
A regional bank preparing for ISO 27001 certification identifies risks including unauthorized access to customer financial data, regulatory compliance violations, and business disruption from cyberattacks. The bank's SoA includes control A.8.2 (Privileged access rights) as applicable with full implementation, supported by evidence including the privileged access management policy, technical configuration of the identity management system, and quarterly access review reports.
The bank excludes control A.8.22 (Secure system engineering principles) because it does not develop software systems internally, purchasing all applications from certified vendors. The exclusion justification references the vendor management policy requiring security certifications and the current vendor assessment documentation. This is a defensible exclusion because the control addresses risks that do not exist in the bank's operational context.
Maintenance and Version Control
The SoA is a living document requiring regular updates when organizational changes occur. Triggers for SoA review include scope changes, new services, acquisitions, significant security incidents, and annual risk assessment updates. Version control is mandatory because auditors review SoA evolution over time to verify the document reflects actual organizational changes rather than cosmetic updates.
Organizations with rapid growth or frequent operational changes should establish quarterly SoA review cycles. Mature organizations in stable environments may review annually, but any material change in risk profile should trigger an immediate SoA review regardless of the scheduled cycle.
The SoA is the foundational document for ISO 27001 implementation and the primary focus during certification audits. It defines the scope of everything else auditors will examine. Controls included in the SoA will be tested for evidence of implementation. Controls excluded from the SoA will not be audited, but the exclusion justifications will be scrutinized for validity under the standard's requirements.
From an operational perspective, the SoA serves as the security program's implementation roadmap. Security teams use it to understand which controls must be maintained, what evidence must be collected, and how control decisions connect to organizational risks. A well-constructed SoA enables efficient resource allocation by focusing implementation efforts on controls that address actual identified risks rather than generic security measures.
Business Communication and Due Diligence
Enterprise customers, regulators, and business partners frequently request the SoA during vendor security assessments. The document provides external parties with visibility into the organization's security decision-making process and control implementation status. A credible SoA demonstrates that security decisions are deliberate and risk-based rather than reactive or compliance-driven.
Conversely, an SoA listing all 93 controls as applicable with identical generic justifications signals that the document was created to satisfy audit requirements rather than reflect operational security decisions. Sophisticated counterparties recognize this pattern immediately and may require additional security evidence or impose contractual security requirements to compensate for the lack of credible security documentation.
Audit Failure Modes
Organizations treating the SoA as a compliance checkbox consistently fail in predictable ways. The most common failure mode is controls listed as implemented without supporting evidence, resulting in audit non-conformances that delay certification or require corrective action plans. These failures typically occur when the SoA is constructed before implementing the controls it describes.
The second common failure involves exclusions without valid justifications. Organizations exclude controls they prefer not to implement rather than controls that are genuinely inapplicable to their risk profile. Auditors will challenge every exclusion and require organizations to either provide valid justification or include the control as applicable.
Documented Consequences
Real-world examples demonstrate the business impact of inadequate SoA construction. In 2021, a European cloud services provider lost a major enterprise customer contract when due diligence review revealed that the provider's SoA excluded data encryption controls on cost grounds rather than risk-based justification. The customer concluded that the provider's security decisions were driven by financial considerations rather than risk management, making the provider unsuitable for processing regulated healthcare data.
Common Misconceptions
A persistent misconception is that comprehensive inclusion equals superior security. Some organizations include all 93 controls to avoid writing exclusion justifications, creating an SoA that cannot be implemented within the organizational context. This approach generates audit risk when auditors find no evidence for controls listed as implemented but operationally inapplicable.
Another misconception is that the SoA can be copied from similar organizations or purchased as a template. Control applicability depends on specific organizational risk profiles, business models, and operational contexts. Template-based SoAs inevitably contain control decisions that do not align with the organization's actual risk assessment results, creating audit vulnerabilities and operational confusion.
CDA approaches the Statement of Applicability through Perpetual Compliance Assurance (PCA), operating under the principle that compliance is not an event but a state. Within the Planetary Defense Model (PDM), the SoA sits squarely within the Risk Governance and Assurance (RGA) domain, which governs the ongoing alignment between organizational risk decisions and the control framework that addresses those risks.
The conventional approach treats the SoA as a certification artifact: constructed once, reviewed annually, and updated minimally to maintain the certificate. CDA rejects this static model because it reflects a static understanding of risk, and organizational risk is inherently dynamic. Organizations change cloud architectures, onboard new suppliers, expand into regulated markets, and face evolving threat actors. Each change potentially affects which controls are applicable, which are excluded, and what implementation status actually reflects operational reality.
CDA's methodology connects the SoA directly to continuous risk monitoring outputs through structured control traceability matrices. When changes are detected in the organization's risk profile, whether through threat intelligence feeds, supplier risk events, or internal audit findings, the RGA domain triggers automated review of affected SoA entries. This creates a continuous loop where the SoA reflects current organizational state rather than historical compliance snapshots.
Specifically, CDA implements SoA management through control traceability matrices linking each Annex A control to its originating risk, implementing policy or technical control, assigned control owner, and last verified implementation date. Control owners receive automated notifications when their assigned controls require re-verification based on trigger events or scheduled review cycles.
This approach means that customer, regulator, or auditor requests for the SoA receive documents reflecting operational reality rather than compliance artifacts from prior periods. Audit preparation time is minimized because the SoA has been maintained continuously rather than reconstructed before audit windows. Most importantly, the SoA serves as an operational tool for security teams rather than a compliance document stored until the next certification cycle.