The Statement of Applicability — Your Most Important Document
I've reviewed thousands of Information Security Management System documents over my career, and if you held a gun to my head and forced me to evaluate an organization's entire security posture based on a single artifact, I'd ask for the Statement of Applicability every single time. Not the risk register. Not the policies. The SoA.
This isn't hyperbole. The Statement of Applicability is the architectural blueprint of your ISMS. It tells me what you've decided matters, what you've deliberately excluded, and crucially—why. A well-crafted SoA reveals an organization that genuinely understands its risks. A poorly constructed one exposes compliance theater faster than any other document in your management system.
What the Standard Actually Requires
Clause 6.1.3(d) mandates that organizations produce a Statement of Applicability containing the necessary controls—not just those from Annex A, but any controls determined to be necessary through your risk treatment process. You must state whether those controls are implemented and provide justification for including each one. Perhaps most importantly, you must justify the exclusion of any Annex A controls.
Let me be blunt about something many consultants gloss over: the 2022 revision reduced Annex A from 114 controls to 93, reorganizing them into four themes rather than fourteen domains. This wasn't just housekeeping. The consolidation eliminated redundancy while introducing eleven new controls addressing modern threats—Control 5.23 (Information security for use of cloud services), Control 5.7 (Threat intelligence), and Control 8.11 (Data masking), among others that previous versions awkwardly addressed through interpretation.
Your SoA must reflect this new structure if you're certifying or transitioning to 27001:2022. More importantly, it must reflect your actual implementation status, not your aspirational state. The ISO 27002:2022 implementation guidance emphasizes that controls should be tailored to your organization's context, not applied universally without consideration.
Why Most SoAs Are Garbage
I audited a mid-sized financial services company last year that presented an SoA clearly copied from a template purchased online. Every control was marked "implemented" with justifications that read like they were written by someone who'd never set foot in the organization. For Control 8.1 (User endpoint devices), their justification stated "laptops are encrypted and managed via MDM." During the audit, I discovered they had no MDM solution, roughly 40% of laptops were running BitLocker with recovery keys stored in a shared spreadsheet, and their BYOD policy allowed personal devices with zero controls.
This organization had confused "having a document called Statement of Applicability" with "having a useful Statement of Applicability." They are not the same thing.
The most common SoA failures I encounter fall into predictable categories:
- Copy-paste justifications that don't reference the organization's actual environment, risks, or business context
- Binary implementation status when reality exists on a spectrum—"implemented" when they mean "we started thinking about it"
- Missing exclusion justifications or justifications that amount to "we don't want to"
- Orphan controls that aren't traceable back to identified risks or contractual requirements
- Static documents that haven't been updated since initial certification despite significant organizational changes
The Exclusion Trap
Let's talk about control exclusions, because this is where auditors earn their keep and where organizations most frequently embarrass themselves.
You cannot exclude controls simply because they're inconvenient, expensive, or outside your current capabilities. Clause 6.1.3(d) requires justification for exclusions, and that justification must be defensible against your risk assessment and business nature.
I've seen organizations attempt to exclude Control 5.23 (Information security for use of cloud services) while running their entire infrastructure on AWS. I've watched security managers argue with straight faces that Control 7.4 (Physical security monitoring) doesn't apply because "we're mostly remote workers"—while maintaining a data center with co-located servers.
Valid exclusions exist. If you genuinely have no software development activities—not custom scripts, not low-code automation, nothing—then Controls 8.25 through 8.31 covering secure development might legitimately not apply. If you have no intellectual property creation activities, Control 5.32 (Intellectual property rights) might be excludable. But you'd better be certain, because I'm going to ask detailed questions.
Auditor tip: The test I apply for exclusions: can you explain this exclusion to a technically literate regulator without sounding ridiculous? If not, reconsider.
Building an Effective SoA
A useful Statement of Applicability starts with your risk assessment outcomes. Each included control should trace back to specific risks you've identified or regulatory requirements you must meet. The SME implementation guide emphasizes this connection—controls without clear risk justification are red flags.
Control Selection and Justification
Start with the mandatory controls—those required by law or contract. If you process payment cards, Control 8.24 (Use of cryptography) isn't optional. If you're subject to GDPR, Control 5.34 (Privacy and protection of personally identifiable information) is essential, and you should reference ISO 27018 for detailed PII protection guidance.
Next, work through your risk treatment decisions. For each identified risk, document which controls address it. This creates a traceable line from threat to control, which auditors love and which makes your life easier during management reviews.
Your justifications should be specific to your environment. Instead of "Control 8.1 is implemented to secure user devices," write "Control 8.1 addresses risks from unmanaged devices accessing customer data via our VPN. Implementation includes Intune MDM for company devices, conditional access policies requiring device compliance, and BitLocker encryption with Azure AD key escrow."
Implementation Status Realism
Use implementation status categories that reflect reality. I recommend four levels:
- Fully Implemented: Control is operating as intended with evidence of effectiveness
- Partially Implemented: Control exists but gaps remain (document what's missing and timeline for completion)
- Planned: Control not yet implemented but included in risk treatment plan with defined timeline
- Not Applicable: Control excluded with documented justification
Be honest about partial implementations. If Control 8.21 (Network security management) covers your main office but not your satellite locations, document that gap and your remediation timeline. Auditors prefer honest incomplete implementation over fictional complete implementation.
Cross-Standard Integration
Your SoA shouldn't exist in isolation. If you're using cloud services extensively, reference ISO 27017 for cloud-specific guidance. Organizations handling significant amounts of personal data should consider ISO 27018 requirements alongside Control 5.34.
For supply chain security, Control 5.19 (Information security in supplier relationships) should align with ISO 27036 if you're managing complex supplier ecosystems. Document these cross-references in your SoA—it demonstrates thorough risk consideration and helps during audits.
What the Auditor Looks For
During SoA review, I examine specific evidence:
- Traceability: Can you trace each control back to a specific risk or requirement?
- Currency: Does the SoA reflect your current state, not last year's implementation?
- Completeness: Are all 93 Annex A controls addressed (included or excluded)?
- Justification quality: Do exclusions demonstrate genuine inapplicability rather than convenience?
- Implementation evidence: Can you demonstrate that "implemented" controls actually exist and function?
I'll ask for supporting evidence. If Control 6.8 (Privileged access management) is marked implemented, show me your privileged access management solution, user lists, and access review records. If Control 8.28 (Secure coding) is excluded, walk me through your software inventory to confirm no development activities exist.
Common audit finding: Organizations often mark Control 5.15 (Access control for networks and network services) as implemented but can't demonstrate network segmentation between production and development environments. Implementation status should reflect actual capability, not intended capability.
Maintenance and Evolution
Your SoA is a living document that should evolve with your organization. When you adopt new cloud services, add new locations, or change business processes, review affected controls. New threats may require additional controls beyond Annex A—document these in your SoA with justification for their necessity.
Schedule quarterly SoA reviews tied to your management review process. Don't wait for annual audits to discover that half your controls no longer reflect reality. The SME guide emphasizes that smaller organizations can maintain more agile documentation—take advantage of this by keeping your SoA current and relevant.
Version Control and Approval
Maintain proper version control with change tracking. Each SoA revision should include a summary of changes, approval by your ISMS management team, and effective date. This documentation trail becomes crucial during certification surveillance audits when auditors examine how your ISMS has evolved.
Your Statement of Applicability represents your organization's security commitment translated into actionable controls. Invest the time to make it accurate, current, and defensible. A well-crafted SoA becomes your roadmap for implementation, evidence for audits, and foundation for continuous improvement. Get this document right, and everything else becomes significantly easier.
Need help building an effective Statement of Applicability for your organization? Connect with experienced ISO 27001 practitioners at the IX ISO 27001 Info Hub or schedule a consultation to review your current documentation approach.
Need personalized guidance? Reach our team at ix@isegrim-x.com.
