Short answer
The Statement of Applicability (SoA), required by ISO 27001 clause 6.1.3 d, lists the controls necessary to treat your information security risks, justifies why each is included, says whether each is implemented, and justifies the exclusion of any Annex A control. It links risk treatment decisions to the controls you actually run.
Key takeaways
- The SoA must cover all 93 Annex A controls, included or excluded.
- Each inclusion and each exclusion needs a justification.
- It must state whether each necessary control is implemented.
- It should trace back to risk treatment decisions, not a template.
What clause 6.1.3 d requires
When you plan risk treatment, ISO/IEC 27001 requires you to produce a Statement of Applicability that contains the necessary controls, the justification for their inclusion, whether the necessary controls are implemented or not, and the justification for excluding any Annex A controls. It is documented information and a common starting point for certification auditors.
What a good SoA row looks like
| Control | Applicable | Justification | Status | Reference |
|---|---|---|---|---|
| A.5.15 Access control | Yes | Risk R-03 (unauthorised access to customer data); customer contract clause 7 | Implemented | Access Control Policy v3; IAM procedure |
| A.7.4 Physical security monitoring | No | No company premises in scope; all hosting at cloud provider covered by its own certifications (see A.5.23) | Not applicable | Cloud provider assurance file |
| A.8.11 Data masking | Yes | Risk R-11 (test environments hold production data) | Partially implemented | Treatment plan item T-07, due Dec 2026 |
Justifying inclusions
Link each included control to the reason it is needed: a risk in the register, a legal or contractual requirement, or a business decision. "Required by ISO 27001" isn't a justification, because Annex A controls are reference controls you select, not mandatory requirements.
Justifying exclusions
An exclusion is acceptable when the control isn't needed to treat any identified risk and no legal or contractual requirement calls for it. Say why in a sentence that an auditor can test, for example that there is no software development in scope, so to are excluded. Exclusions that contradict the scope, such as excluding supplier controls while relying on a cloud provider, become findings.
Status matters. If a necessary control isn't fully implemented yet, say so and point to the treatment plan. Claiming "implemented" for a control with no records is a common nonconformity.
Common SoA findings
- Copied template with justifications that don't match the risk register
- Exclusions that contradict the scope or the way services are actually delivered
- 2013 control numbering still used after the 2022 transition
- No version control, owner or approval date
- Status marked implemented with no evidence behind it
Checklist
SoA review before an audit
0 of 5 done
Put this into practice on QULDEX
Frequently asked questions
Do we have to implement all 93 Annex A controls?
No. You include the controls your risk treatment needs and justify excluding the rest. The SoA must still list all 93.
Can the SoA be a spreadsheet?
Yes. The standard doesn't prescribe a format, only the content. It must be controlled documented information with version and approval.
How often should the SoA be updated?
Whenever risk treatment decisions change, and at least when the risk assessment is repeated, usually annually.