How to fill in a Statement of Applicability

A strong SoA is readable by someone who did not build the ISMS: each row shows which control you are talking about, whether it applies, and why that decision is reasonable given your scope and risk outcomes. Below is a practical sequence teams follow when creating or refreshing the document.

1. Freeze scope and boundaries first

List sites, legal entities, services, and technology in scope. If something is explicitly out of scope (for example a legacy subsidiary), say so in your ISMS scope statement so “not applicable” rows on the SoA are not mistaken for laziness.

2. Import or build your control baseline

Most organisations start from Annex A (or an equivalent catalogue) and map any internal control IDs. Ensure titles and references stay stable across versions—changing IDs every quarter confuses auditors and your own GRC team.

3. Work risk treatment before you “guess” applicability

Run (or update) your information security risk assessment. For each material risk, note which control themes reduce likelihood or impact. That pass gives you a first-cut list of controls that must apply unless you have a documented alternative treatment.

4. Decide applicability row by row

For each control in the catalogue:

• If it applies: set applicable and write a short justification such as where it is implemented (policy name, platform, team)—enough for an auditor to know where to sample.
• If it does not apply: set not applicable and write a specific justification tied to scope (for example “No physical sites operated by in-scope entities—control owned by colocation provider per contract Appendix B”) rather than “N/A.”

5. Cross-check for contradictions

Search for mismatches: high risks with no linked controls; controls marked not applicable while related risks remain open; duplicate rows with conflicting applicability. These are the first places auditors dig.

6. Add ownership and review dates

Even when the standard does not mandate a single format, organisations usually record control owner, review frequency, and last review date in the control library or SoA companion—so management review can ask “what changed since last quarter?”

7. Publish as controlled documented information

Version the SoA (or the system that exports it), approve it under your document control process, and communicate changes to owners. Many teams keep the master data in a tool and export a PDF for the certification binder; others maintain the authoritative table entirely in software—either way, version discipline matters.

For definitions, see what is a Statement of Applicability?. For tooling-specific workflow, see how ISMSVision helps with the SoA.