Statement of Applicability
The Statement of Applicability (SoA) is one of the most important documents in your ISMS. It lists all 93 Annex A controls, states whether each is applicable or not, provides justification for inclusions and exclusions, and describes how applicable controls are implemented. Auditors review the SoA closely — it is the bridge between your risk assessment and your control implementation.
What the SoA Must Include
For each of the 93 Annex A controls, your SoA must document: whether the control is applicable, the justification for its inclusion or exclusion, the implementation status (implemented, partially implemented, planned), and a reference to the risk treatment plan that drives the control selection.
Structure and Format
Most organizations use a spreadsheet or table with columns for: control reference number, control name, applicability (yes/no), justification, implementation status, implementation description, and responsible owner. There is no mandated format, but clarity and completeness are essential.
Common Mistakes
Excluding controls without justification. Every exclusion must be justified based on your risk assessment. Saying a control is "not applicable" without explaining why is an audit finding waiting to happen.
Copy-pasting generic descriptions. Auditors want to see how you specifically implement each control, not boilerplate language. Reference your actual policies, tools, and processes.
Treating it as a one-time document. The SoA is a living document. When risks change, when you adopt new technologies, or when you restructure, the SoA must be updated.
Misaligning with the risk assessment. If your risk assessment identifies a risk but the SoA excludes the relevant control, auditors will flag the inconsistency. The SoA must be traceable to your risk assessment.
Maintenance
Review the SoA at least annually or whenever significant changes occur. Changes in scope, technology, business processes, or the threat landscape may affect control applicability. Document each revision with a changelog.
In the next lesson, we will cover the internal audit process.