The Statement of Applicability is the document a certification auditor reads most closely, because it is the index to everything else. It says which controls you have decided you need, why, and whether they are in place. The audit plan is built from it, and its version number is commonly referenced on the certificate.
It is also the most often copied document in an ISMS, which is why so many fail on the same points. This guide covers what the standard requires, a column layout that works, and how to justify a control properly.
What clause 6.1.3 d) asks for
Four things, and only four. Everything else in an SoA is there to make it useful.
- The controls you have determined are necessary to treat your risks. These can come from Annex A or from anywhere else, including controls you designed yourself.
- A justification for including each one.
- Whether each necessary control is implemented or not.
- A justification for excluding any Annex A control.
A column layout that works
| Column | What goes in it |
|---|---|
| Control number and title | As written in Annex A: 5.1 to 5.37, 6.1 to 6.8, 7.1 to 7.14, 8.1 to 8.34. |
| Applicable | Yes or no. There is no partly applicable. |
| Justification | Why it is included or excluded. See the next section. |
| Risk reference | The risk register entries this control treats. |
| Implementation status | Implemented, partly implemented or planned, with a target date if not complete. |
| How it is implemented | One or two lines, naming the policy, procedure or system. |
| Evidence | Where the proof is: a document reference, a system report, a record. |
| Owner | The person who answers for the control. |
Writing a justification an auditor will accept
A justification for inclusion says where the need comes from. There are four honest sources, and most controls have more than one.
- A risk. Name the entry in the risk register. This is the strongest justification because it is the one the standard is built around.
- A legal or regulatory requirement. Name the law, regulation or direction.
- A contractual requirement. Name the customer contract or the clause.
- A business requirement or accepted good practice that management has adopted.
Excluding a control
A control is excluded when the activity it governs does not happen within your scope, so there is no risk for it to treat. The justification states that fact in a way an auditor can verify.
| Control | A justification that holds | One that does not |
|---|---|---|
| 8.28 Secure coding, 8.25 Secure development life cycle | No software is developed in scope. All applications are commercial products or services. | Development is outsourced. Outsourced development is still in scope under 8.30. |
| 7.x physical controls for a server room | No server room or data center in scope. All systems are hosted by the cloud provider named in the scope. | The office is small. Small offices still have entrances, desks and equipment. |
| 6.7 Remote working | Hard to justify for almost any organization today. | Staff rarely work from home. |
Mistakes that become findings
- Every control marked applicable and implemented. Auditors sample the SoA, and the first control found to be only on paper puts the whole document in doubt.
- Status copied from a template rather than checked. Planned is an acceptable status, provided the risk treatment plan carries the action and a date.
- No link to the risk assessment. The SoA is an output of risk treatment. If the two do not reference each other, the process the standard asks for did not run.
- Still on the 2013 control set. The 2022 edition has 93 controls in four themes and added eleven, including threat intelligence, cloud services, configuration management, data masking, data leakage prevention and secure coding.
- No version, date or approval. The SoA is controlled documented information.
- Never updated. Review it when the risk assessment changes, after a significant change to scope or systems, and at least once a year.