A Statement of Applicability explains which security controls are necessary for your ISMS and the reasoning behind the selection. It should connect to the scope and risk treatment. Copying a spreadsheet and marking every row “yes” does not explain why controls are needed or what has actually been implemented.
Use Annex A as a comparison
ISO/IEC 27001:2022 contains 93 Annex A controls in four themes, as described in UKAS’s transition bulletin. Start with controls needed for your risks and other applicable requirements, then compare them with Annex A to check for omissions. A control number in a spreadsheet is not evidence that the control operates effectively.
Four records with different purposes
| Record | Question answered |
|---|---|
| Risk register | What could go wrong and how do we assess it? |
| Treatment plan | What change will be made, by whom and when? |
| SoA | Which controls are necessary, why and with what status? |
| Evidence register | What demonstrates implementation and verification? |
One system can support all four functions. Keep the meaning of its fields clear, however. Completing a project task should not automatically label a control as continuously effective. Record how evidence relates to the period and service being assessed.
Fictional example: supplier access
A fictional supplier receives temporary access to a customer environment. The risk concerns excessive permissions or access remaining active for too long. The SoA points to the selected access controls and their justification. The treatment plan assigns work to enforce end dates. Approvals, configuration records and a review of expired accounts provide evidence. Until the change is tested, its implementation status should show that limitation.
Explain both inclusion and exclusion
Difficulty is not a substantive reason to exclude a control. Explain the connection with scope, risks and applicable requirements. Inclusion also needs reasoning: what does the control protect, and how is it implemented? An outsourced activity may still require agreements, oversight and checks. “The supplier does it” is therefore not a complete justification. Record your own responsibility and what evidence supports reliance on that supplier.
A practical review before assessment
- Trace an important risk through its control to supporting evidence.
- Check an exclusion against the actual scope and dependencies.
- Compare an implementation status with current operation.
- Identify the approved version and who reviews changes.
- Update the connections when services, systems or risks change.
Use the risk assessment and corrective action process to address gaps. The normative requirements are in ISO/IEC 27001; this article offers a practical explanation rather than a reproduction of the standard.