Statement of Applicability: A Practical Guide
Build a clear Statement of Applicability that connects information security risks, necessary controls, implementation status and audit evidence.
In 30 seconds
- Purpose: document necessary controls and justify the inclusion of controls and the exclusion of Annex A controls.
- Inputs: ISMS scope, risk assessment, risk treatment decisions and applicable requirements.
- Outputs: an approved SoA, implementation status and links to supporting records.
- When to use it: when establishing an ISMS, changing its scope, reviewing risks or preparing an audit.
A useful Statement of Applicability (SoA) explains which information security controls your organisation needs, why they are necessary, and whether they are implemented. It connects risk treatment decisions with day-to-day security management.
What the SoA should achieve
The SoA should make your decisions understandable. A reader should be able to trace a control back to a risk or requirement and understand how its implementation is managed. It is not simply a list of controls copied from a standard.
At NetQualIT, the objective is a document that remains practical to maintain: clear decisions, named owners and evidence that can be retrieved when needed.
A practical structure
Record the control reference, whether it is necessary, the justification, and its implementation status. For operational follow-up, add an owner, evidence references and the next review date. Compare the controls you have determined with Annex A so that necessary controls are not overlooked; other sources of controls may also be relevant.
| Illustrative control area | Decision and reason | Implementation and evidence |
|---|---|---|
| Access control | Necessary to restrict access to critical systems and information. | Record the actual status, access rules, approvals and review records. |
| Secure development | Assess applicability against your scope, including outsourced development and relevant supplier responsibilities. | Document the decision and supporting evidence; do not assume exclusion solely because there is no internal development team. |
Common mistakes
- Copying a template without explaining decisions in your own context.
- Leaving the SoA disconnected from risk assessment and treatment.
- Marking a control as implemented without evidence.
- Excluding a control without considering suppliers and contractual obligations.
- Failing to review the document after a significant change.
Preparing for an audit
Check consistency between the ISMS scope, risk assessment, treatment plan and SoA. Keep the reasoning for inclusions and exclusions available, and use implementation status that reflects reality. Link evidence rather than duplicating it in several documents.
Your working checklist
- Confirm the scope and applicable requirements.
- Review risks and treatment decisions.
- Determine necessary controls and compare them with Annex A.
- Document justifications and implementation status.
- Assign follow-up actions and organise review and approval.
Read the risk assessment guide to build the starting point for these decisions.
Deliverables
- A working SoA structure with decision justifications.
- An implementation-status and evidence review checklist.
Operational summary
Keep the scope, risk decisions, necessary controls and evidence consistent. Review the document after relevant changes.
Download
Turn your SoA into a working management document
NetQualIT can help structure the document, clarify decisions and connect controls with usable evidence.