It wasn’t until my third ISO 27001 implementation that I truly understood the Statement of Applicability. The first time, it felt like a box-ticking exercise—a dry list of controls from Annex A. But I soon learned that this document isn’t just an obligation. It’s a living reflection of an organisation’s security posture. And when written properly, it becomes a powerful tool for clarity, accountability, and audit readiness.
If you’re knee-deep in your ISO 27001 implementation, or simply trying to wrap your head around what is Statement of Applicability ISO 27001, you’re not alone. This article unpacks the purpose, structure, and writing approach of the Statement of Applicability (SoA), including a real-world ISO 27001 Statement of Applicability example, so you can confidently develop or refine your own.
Why the statement of applicability matters
The Statement of Applicability isn’t just another document in your ISO binder. It’s a central artefact that links your organisation’s risk treatment plan to the ISO 27001 Annex A controls. Specifically, ISO/IEC 27001:2022, Clause 6.1.3, requires organisations to determine which of the 93 Annex A controls are applicable, justify inclusions and exclusions, and describe their implementation status.
This requirement is not optional. Your auditors will inspect the SoA to assess whether your organisation has thoughtfully selected its controls and whether those controls align with your actual risk profile.
More than that, the SoA becomes a guide for ongoing security governance. It allows internal stakeholders—from IT teams to compliance officers—to understand which controls are in place, which are planned, and why others are excluded. It’s the narrative spine of your ISO 27001 certification Statement of Applicability.
What the statement should include
Although the standard doesn’t prescribe a fixed format, a comprehensive SoA should clearly show which Annex A controls are:
- Applicable or not applicable
- Supported with a justification
- Implemented, partially implemented, or planned
This clarity ensures that the SoA isn’t just a formality, but a practical reference.
Before jumping into how to write ISO 27001 Statement of Applicability, it’s essential to understand the typical layout. Below is a simplified table to illustrate the structure of a well-constructed SoA.
Sample structure of a statement of applicability (ISO 27001:2022)
| Control ID | Control name | Applicability | Justification | Implementation status |
| A.5.1 | Policies for information security | Yes | Core to setting information security baseline | Implemented |
| A.5.34 | Protection of log information | Yes | Logs are retained and essential for forensics | Partially implemented |
| A.6.2 | Teleworking | No | Organisation does not allow remote work | Not applicable |
| A.8.28 | Secure coding | Yes | Custom applications are developed in-house | Planned |
This layout offers a snapshot of your security maturity and priorities. Each row should be supported by evidence—whether that’s a policy, procedure, or system configuration—when facing audits or internal reviews.
How to write ISO 27001 statement of applicability
Writing your SoA can feel intimidating, especially for first-timers. I remember staring at a blank statement of applicability ISO 27001 template XLS, unsure where to begin. But here’s the thing—this document doesn’t need to be perfect out of the gate. It evolves with your ISMS and your risk profile.
The process typically starts after your risk assessment and treatment plan have been defined. This is because the SoA is inherently a justification document—your decisions should be rooted in actual business risks, not assumptions.
Start with Annex A and go control by control. Ask three questions:
- Is this control relevant based on our risk profile?
- If not, can we clearly justify its exclusion?
- If it is relevant, what’s the status of its implementation?
Let me walk you through a detailed ISO 27001 Statement of Applicability example from a mid-sized fintech company, anonymised for confidentiality but reflective of real-life implementation.
ISO 27001 statement of applicability example (Fintech Ltd.)
| Control ID | Control Name | Applicable | Justification | Implementation status |
| A.5.10 | Acceptable use of assets | Yes | Staff access to production data must be controlled | Implemented |
| A.5.18 | Access rights | Yes | Critical for segregation of duties in payment systems | Implemented |
| A.5.23 | Information security for cloud services | Yes | Third-party cloud infrastructure must meet compliance standards | Partially implemented |
| A.5.35 | Clock synchronization | No | All systems use a centrally managed NTP service; separate control not needed | Not applicable |
| A.8.15 | Logging activities | Yes | Required for regulatory compliance and fraud detection | Implemented |
The narrative behind this table is equally important. For instance, “Access rights” was given high priority due to the risk of financial fraud. Meanwhile, “Clock synchronization” was deemed not applicable because its intent was already covered under another implemented system-wide process. Each decision was reviewed with stakeholders and approved by the ISMS steering committee.
This example also underscores the importance of aligning your SoA with operational reality—not just compliance optics.
Where templates help—and where they don’t
A Statement of Applicability ISO 27001 template—especially in XLS or PDF formats—can jumpstart your work. It offers a consistent format and ensures you don’t overlook any controls.
However, templates are just scaffolding. They won’t write your justifications or tell your story. I’ve seen SoAs that were copied verbatim from another company’s document—and they fell apart under auditor scrutiny. Use templates to save time, but always tailor the content to reflect your actual decisions.
Who should be involved in writing the SoA
In practice, the SoA should never be drafted in isolation. Security officers, IT leads, department heads, and risk managers all have insights into the applicability and implementation of controls. When I work with clients, I make the SoA part of the broader ISMS workshop, so stakeholders can justify decisions on the spot.
Auditors will often ask, “Why did you exclude this control?” or “Show me evidence that this control is working.” Those answers can only come from a collaborative, cross-functional understanding.
After it’s written, the SoA should be treated as a living document. Updates are expected whenever the risk landscape changes—say, after a new system rollout or regulatory shift. Regular reviews ensure ongoing alignment.
Are you documenting decisions—or just ticking boxes?
The ISO 27001 Statement of Applicability isn’t just a document. It’s a security mirror. Done well, it reflects how your organisation manages risk, aligns controls, and stays accountable. Done poorly, it becomes a paper shield—impressive until tested.
If you’re just starting out, lean on a Statement of Applicability ISO 27001 template XLS, but make it your own. Make it a conversation starter between departments. Use it as a tool to foster transparency in your risk decisions.
And most of all—don’t treat it as static. Like your security risks, your SoA evolves. Keep it alive, and it’ll do more than satisfy an auditor. It’ll help you build a stronger, smarter, and more resilient ISMS.
