Key Takeaways
- The Definitive Link: The SoA bridges the gap between your Risk Assessment and your chosen security controls, providing a clear rationale for every decision.
- A Scrutiny Focal Point: Practitioners use this document as their primary roadmap; if a control is listed as “included” in the SoA but is missing in practice, it will likely lead to a non-conformity.
- Modernized for Current Needs: Under the latest version of the standard, the SoA must now align with 93 controls organized into four themes: Organizational, People, Physical, and Technological.
If the Information Security Policy is the constitution of your security program, the Statement of Applicability (SoA) is its comprehensive manual. It is arguably the most scrutinized document during an ISO 27001 evaluation because it links your specific security decisions back to the standard’s requirements.
Understanding the ISO 27001 SoA is essential for any organization seeking to demonstrate that they have thoughtfully implemented the right protection for their unique environment.
Speak to a Compliance Specialist.
What Exactly is the SoA?
The SoA is a centralized document that lists every security control found in Annex A of the ISO 27001 standard. For each control, you must clearly state:
- Inclusion or Exclusion: Is this control part of your security framework?
- Justification: Why is it included (e.g., to mitigate a specific risk) or why is it excluded (e.g., you don’t have any physical servers)?
- Implementation Status: A brief description of how the control is currently being managed.
Why the SoA is Critical for Your Success
The SoA serves three vital functions that go beyond mere compliance:
- The Roadmap for Assessors: During an examination, the assessor uses your SoA as their primary guide. It tells them exactly which areas of your business they need to review and which are out of scope.
- A “Gap Analysis” Tool: Drafting the SoA often reveals areas where your security might be lacking. It forces a systematic review of all 93 controls in the 2022 version, ensuring nothing is overlooked.
- Stakeholder Transparency: For enterprise clients, the SoA (often provided in a redacted format) is the definitive proof that you have a comprehensive approach to information security.
How to Build a Robust SoA
Building a high-quality ISO 27001 SoA requires a cross-functional approach. It isn’t just an IT task; it involves legal, HR, and operations.
1. Start with Your Risk Assessment
You cannot fill out a SoA in a vacuum. The results of your risk assessment should dictate your controls. If you identified a high risk of unauthorized physical access, your SoA must reflect the implementation of strong physical entry controls.
2. Don’t Just Say “Yes”
For every included control, you need a justification. A common pitfall is providing vague answers. Instead of saying “We have a password policy,” a stronger SoA would say, “Control implemented via Policy [X] and enforced through [System Y] to mitigate the risk of unauthorized access identified in our 2026 Risk Assessment.”
3. Carefully Justify Exclusions
Excluding a control is perfectly acceptable, but the justification must be airtight. If you exclude “Secure Coding” because you are a service-based firm that doesn’t develop software, clearly state that your business model does not involve software development.
Common SoA Mistakes to Avoid
Even well-prepared teams can stumble on the technicalities of the SoA. Watch out for these frequent pitfalls:
- Ignoring Statutory or Contractual Requirements: Even if a risk assessment doesn’t flag a specific control, you may still be required to include it based on local laws or specific customer contracts.
- Copy-Pasting Justifications: Every control is unique. Using the same “this is a standard company policy” justification for twenty different controls suggests a lack of rigor to an assessor.
- Failing to Update after the 2022 Transition: If you are moving from the 2013 version to the 2022 version, your SoA must reflect the new 93-control structure and the updated attribute tags (e.g., #Cloud, #Privacy).
- Treating it as a “Set and Forget” Document: Your SoA should be reviewed whenever your business changes—such as moving to a fully remote model or adopting new cloud infrastructure.
Overcoming the Complexity of Mapping
The 2022 update to ISO 27001 streamlined the controls into four distinct themes, but the mapping process remains a technical challenge. Ensuring that your internal processes align perfectly with the standard’s expectations requires a deep understanding of the framework’s nuances.
How Auditwerx Simplifies Your ISO 27001 SoA
At Auditwerx, we assist organizations in translating their operational reality into a compliant, professional ISO 27001 SoA. We help you avoid the common mistakes that can lead to friction during an examination, ensuring your “master map” is accurate, defensible, and reflective of your commitment to security. We help you build a document that doesn’t just pass a review but serves as a valuable management tool for your team. If you are ready to get started, contact Auditwerx today.
FAQs
Can we share our SoA with potential clients during a sales cycle?
Yes, but do so with caution. Because the SoA contains a detailed map of your security controls, it is often treated as a confidential document. Many firms share a redacted version or require a signed Non-Disclosure Agreement (NDA) before releasing the full Statement of Applicability.
Is there a specific format required for the SoA?
ISO 27001 does not mandate a specific layout (like a Word doc vs. an Excel sheet), but it must be a “documented information” piece. The most important thing is that it is organized, version-controlled, and addresses all 93 controls from Annex A of the 2022 standard.While it may not eliminate every question, it typically reduces the volume by 70–90%. Most enterprise teams will accept the certificate and a “Statement of Applicability” as sufficient proof for the majority of their security domains, focusing only on a few specific custom requirements.At a minimum, your ISMS documentation should be reviewed annually. However, significant changes to your business—such as a merger, a move to a new cloud provider, or a shift to fully remote work—should trigger an immediate update to relevant policies like the Scope or SoA.
If we use a GRC tool, does it generate the SoA for us?
A GRC tool can provide a framework and pull in data, but it cannot write the “Justification” for you. A licensed practitioner will look for professional judgment in your justifications to ensure the controls were selected based on your specific business risks, not just software defaults.
How often should the SoA be formally reviewed
At a minimum, the SoA should be reviewed once a year as part of your Management Review. However, it should also be updated whenever there are significant changes to your risk profile, such as a major system migration or a change in the legal landscape affecting your data.A licensed practitioner ensures your ISMS is designed not just for compliance, but for the specific risks your buyers care about—such as cloud security and data privacy. They provide the independent report or certificate that serves as the “source of truth” your sales team can use to close deals.
About the Author
