The Statement of Applicability: Your ISMS Master Blueprint
The Statement of Applicability (SoA) is the central nervous system of an ISO/IEC 27001:2022 Information Security Management System (ISMS). Far from a static list of controls, the SoA is the mechanism that translates high-level security objectives into a functioning operational reality.
It serves as the master blueprint for your security posture, connecting the theoretical requirements of the international standard to the technical specifics of a cloud-first, serverless environment. It is the definitive document an auditor will use to understand the scope and implementation of your security controls.
Defining the Blueprint
The SoA identifies which of the 93 Annex A controls are relevant to your organization. This selection is driven by your “Interested Parties Register” to ensure the architecture meets stakeholder expectations:
- Regulatory Authorities: Meeting data governance requirements like Quebec’s Law 25.
- Clients: Ensuring secure handling of transactional and personal data.
- Partners: Providing assurance of secure data exchange.
The SoA is the bridge between intent and action, connecting your Scope Document, your Risk Register, and your Technical Controls.
The Logic of Inclusion
Inclusion of a control is a risk-based decision. Each control should be mapped to a specific business driver and a formal owner:
| Annex A Control | Business Driver | Documentation Source |
|---|---|---|
| A.5.15 Access Control | Enforcement of Least Privilege (PoLP). | Access Control Policy |
| A.8.32 Change Management | Mitigation of risks from system modifications. | Change Management Policy |
| A.8.2 Info Classification | Protection of sensitive data via tiers. | Data Management Policy |
| A.8.20 Network Security | Protection of virtual network transmissions. | Network Controls Policy |
The Strategic Justification: Why Exclusions Matter
In a cloud-native architecture, justifying the exclusion of a control is as technically demanding as justifying its inclusion. A claim of “Not Applicable” requires a formal Targeted Risk Analysis (TRA).
Example: Internal Vulnerability Scanning If you operate a fully serverless architecture with ephemeral resources, traditional internal network scanning may be “Not Applicable” because there is no persistent “internal” network to scan. In this case, your justification would point to compensating controls like monthly external application-layer scans and CI/CD pipeline security.
Evidence-Based Compliance
For an auditor, a policy is only as good as the evidence it generates. Your SoA should map to specific artifacts:
- Audit Logs: System-generated logs showing user logins and security events.
- Access Registers: Documented permissions for applications and infrastructure.
- Training Records: Evidence of annual security awareness completion.
- Device Inventories: Current tracking of all company-issued hardware.
The Lifecycle of the Blueprint
The SoA is a living document. It must be reviewed at least annually or upon significant changes to the environment. This review ensures that the audit program remains aligned with actual operational evidence and that any nonconformities are tracked and resolved.
Conclusion
A meticulously documented Statement of Applicability transforms ISO 27001 from a compliance exercise into a master blueprint for resilience. By moving from generalities to the specifics of serverless-justified exclusions and policy-to-artifact mapping, you create a transparent and defensible security posture that builds trust with clients and regulators alike.
Get Your Free Security Readiness Assessment
Map your controls, identify compliance gaps, and secure your systems before the audit.