The Statement of Applicability, row by row

Clause 6.1.3 of ISO/IEC 27001:2022 asks you to treat the risks you assessed, and to compare the controls you chose against Annex A so nothing necessary is missed. The SoA is the record of that comparison. It covers all 93 Annex A controls and any extra controls you added from elsewhere.

The certification auditor

Uses it to plan sampling: every included control is something they may ask to see working.

Your customers

Some ask for it in vendor reviews to check that the controls they care about are in scope.

Your internal auditor

Uses it as the checklist for the year's internal audit programme.

You

It is the one page that shows what the ISMS promises, so it is where drift shows first.

The standard sets what the SoA must contain, not its format. A spreadsheet is the common choice because it filters well and sits beside the risk register. Treat it as documented information: version it, approve it, and keep the history.

1. Finish the risk assessment and agree a treatment for each risk above your acceptance level.
2. For each risk you chose to treat, list the controls that will reduce it. Those controls are included, with the risk ID as the reason.
3. Add controls that a law, regulation or contract requires even where the risk score alone would not.
4. Walk all 93 Annex A controls. For any you have not included, ask whether a risk was missed. If one was, go back to the register.
5. What is left is your exclusion list. Each one now needs a reason that would survive a question.

1. 1Risk treatmentThe strongest reason: the control reduces a named risk in the register.
2. 2Legal or regulatoryA law or regulator expects it, such as a log or reporting duty in India.
3. 3ContractualA customer agreement requires it, such as encryption or a breach notice period.
4. 4Business choiceLeadership wants it as good practice. Acceptable, but say so plainly.

• Risk assessment and treatmentA method that is repeatable, with the records an auditor reads.
• Documented informationWhat to write, how to control it, and how little is enough.

Auditors do not object to exclusions. They object to exclusions that collapse after one question. The table is illustrative: the left column shows reasons tied to facts the auditor can check; the right column shows the question that exposes a weak reason.

Write the reason as a sentence about your organisation, not about the control. "Not applicable" on its own is not a reason.

• New risk or changed score. Re-check the controls tied to it, and the SoA rows they sit on.
• Scope change. A new product, site or cloud account can turn an exclusion into an inclusion.
• Status moves. A planned control that goes live moves to implemented, with evidence.
• Before each audit. Read every exclusion again as if you were the auditor.
• Management review. Report what changed in the SoA since the last review.

• Copying a template's decisions. Inclusions that match no risk in your register are the first thing an auditor notices.
• Everything included. Including all 93 looks safe but commits you to evidence for each one.
• Status that is not true. Marking a control implemented before it runs turns a gap into a nonconformity.
• No version history. If you cannot show what changed and who approved it, the document is uncontrolled.
• Drift from the risk treatment plan. Two documents that name different controls for the same risk will be raised.

Sources: ISO/IEC 27001:2022, clause 6.1.3 and the Annex A control titles, described in our own words; Annex A control numbers follow the 2022 edition. The example rows are illustrative and describe no real organisation.