Writing an ISO 27001 Statement of Applicability that buyers respect
The Statement of Applicability (SoA) is the most neglected document in the ISO 27001 toolkit, often treated as a bureaucratic chore. In reality, it is the single most important bridge between your security posture and your potential customers' procurement teams. If your SoA is a vague, templated mess, you aren't just failing an audit; you're failing to close deals.
Michael McCarroll— Founder · 20+ yrs GRC, ISO 27001 lead implementer 16 min read Updated June 2026
The SoA as a Sales Discovery Tool
The Statement of Applicability is essentially a snapshot of your entire security universe. Annex A of ISO 27001:2022 contains 93 controls, and the SoA is your public declaration of which of these you use and, crucially, why. During a procurement cycle, a sophisticated buyer from a FTSE 100 or Fortune 500 company will ask for this document almost immediately. If it looks like it was generated by a junior intern on a Friday afternoon, they will assume your security is equally reactive.
To a lead implementer, the SoA is more than a list; it is the output of your risk treatment process. Clause 6.1.3 requires you to compare your selected controls against Annex A. This isn't just about saying 'yes' to everything; it’s about providing a rational argument for your security posture. When a buyer sees a well-reasoned justification for an excluded control, they see a firm that actually understands its business risks rather than one blindly following a checklist.
Anatomy of a High-Trust SoA
Ditch the one-word 'Implemented' status. A buyer wants to see evidence of maturity, which means your SoA should be granular enough to provide confidence but high-level enough to remain readable. Each control entry should ideally reference a specific internal policy or procedure, such as 'Access Control Policy v2.1' or 'Network Architecture Diagram'. This demonstrates that the document is rooted in operational reality rather than theoretical compliance.
The 'Implementation Status' column is where most firms fail. Instead of a binary yes/no, use a graded scale that reflects the truth. If a control is 'ongoing' or 'partially implemented' as part of a remediation plan, state it. Transparency wins more trust than a perfect sheet of 'Yes' markers that clearly doesn't reflect the chaos of a growing startup. Professional buyers respect honesty and a roadmap for improvement over a polished lie.
Clear cross-references to internal policy names.
Implementation status (e.g., Planned, Partially Implemented, Operating).
Specific justifications for exclusion (citing business context).
Mapping to external frameworks like NIST CSF or SOC2 for international buyers.
Adapting to the 2022 Control Update
The 2022 update to ISO 27001 reduced the number of controls from 114 to 93, grouping them into four distinct themes: Organizational, People, Physical, and Technological. Your SoA must reflect this new structure to prove you are ahead of the curve. Using the old 2013 numbering in a 2024 pitch makes your firm look dated and suggests your security management system (ISMS) has been left to gather dust. This transition is a prime opportunity to re-justify your control selection.
Transitioning to the 2022 version isn't just about renumbering rows; it's about shifting to a more integrated way of thinking. For example, the new 'Threat Intelligence' control (5.7) is a massive differentiator. If your SoA shows you are actively consuming threat feeds to inform your firewalls, you are light-years ahead of the competition. Use this update as a catalyst to prune away legacy controls that no longer serve a purpose, keeping your SoA lean and focused on modern risks like cloud native security.
Handling Exclusions and Rationales with Precision
A procurement officer is looking for 'red flag' exclusions. If you are a software-as-a-service (SaaS) business but you have excluded Annex A 8.28 (Secure Coding) or 8.25 (Connectivity to Public Networks), you are going to get buried in follow-up questions. Your justifications for exclusion must be air-tight. If you exclude Physical Security (7.1) because you are 100% remote, explain that your employees work from secure home offices or move the responsibility to your data centre provider's SOC report.
On the flip side, the 'Rationale for Selection' column is your chance to shine. For each selected control, briefly state the business benefit. For 'Information Security in Supplier Relationships' (5.21), you might note: 'Ensures our upstream providers meet the same rigorous standards we promise our customers.' This turns a dry compliance requirement into a value statement. It tells the buyer that you are protecting their interests through every tier of your supply chain.
Control 8.9: Configuration Management – Shows you handle cloud infrastructure as code.
Control 8.10: Information Deletion – Vital for GDPR/DPA compliance and privacy trust.
Control 8.11: Data Masking – Demonstrates advanced data protection in non-prod environments.
Control 8.28: Secure Coding – Essential for any SaaS provider to prove dev excellence.
Maintenance and the 'Living' Document Principle
Static spreadsheets are the enemy of a living SoA. By the time you've finished one version, a new hire has started or a new tool has been integrated, making the document obsolete. To respect a buyer's time, provide them with a version-controlled, timestamped document that matches your most recent Audit findings. Integrating your SoA into your daily GRC workflow ensures that when a prospect asks for it on a Tuesday afternoon, you aren't scrambling to update it.
Finally, understand the 'Audience of One'. While the ISO auditor needs to see compliance with Clause 6.1.3, the buyer needs to see reliability. We recommend maintaining a 'Customer-Facing SoA' summary that lifts the lid on your best controls while keeping the highly sensitive internal mapping for the auditor's eyes only. This balanced approach protects your operational security while providing the transparency required to close the sale. A professional SoA is your best foot forward in any high-stakes business negotiation.
Turn your compliance into a competitive advantage.
Tired of managing your SoA in static spreadsheets? ISO-STANDARD.app automates the mapping between your risk assessment and your controls, providing a live, professional SoA that you can confidently share with prospects to close deals faster.
ISO-STANDARD.app ships a ready-to-adopt ISO 27001 workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
What is the minimum legal requirement for an SoA?
The SoA is a mandatory requirement under Clause 6.1.3 of ISO 27001:2022. It must list which Annex A controls you have selected, justifications for including or excluding them, and the implementation status of each. Without it, you cannot achieve certification.
How often should the SoA be updated?
You should update your SoA whenever your risk profile changes, after significant infrastructure shifts, or at least annually during your management review. In reality, modern firms update it continuously as they deploy new technical controls or decommission legacy systems.
Can I exclude controls from Annex A?
Yes, provided you provide a 'justification for exclusion'. For example, if you do not develop bespoke software, you may justify the exclusion of controls related to secure coding. However, regulators and savvy buyers will scrutinise these exclusions closely.
Should I publish my SoA on my website?
Ideally, no. A public SoA reveals your internal control landscape. Share it under a Non-Disclosure Agreement (NDA) or via a secure 'Trust Centre' to ensure it reaches genuine buyers without handing a roadmap to potential attackers.
Action checklist PDF
Mirrors this guide with owners, artefacts & a 30/60/90-day plan.
