ISO 42001Annex A

The Statement of Applicability: justifying every Annex A control

The Statement of Applicability (SoA) is the document that ties your whole management system back to the standard. It's the auditor's index — the map they use to check that nothing important was quietly dropped. Build it last, build it honestly, and treat every "not applicable" as something you'll defend out loud.

What the SoA actually is

The SoA lists the Annex A controls and, for each, states whether it applies to you, why, and where it's implemented (or a justification if it isn't). Annex A groups these controls into areas covering things like your AI policy, internal organisation, resources, the AI system life cycle, data for AI, and information for interested parties. The SoA is where those controls stop being a generic catalogue and become your control set.

Build it last

The SoA references everything else — your policy, risk register, procedures — so it can only be honest once those exist. Teams that start with the SoA end up writing aspirations ("we will have a control for this") that the evidence doesn't back. Build your system, then write the SoA as a truthful index of what you actually have. It should read like a table of contents for a binder that exists, not a wish list.

Justify inclusions clearly, exclusions carefully

For included controls, a one-line justification and a pointer to the evidence is enough. Exclusions are where auditors focus. Marking a control "not applicable" is a claim you must defend — usually because it genuinely doesn't fit your context, not because it's inconvenient. A weak exclusion ("we're small, so this doesn't apply") is a red flag; a strong one ties to your scope and risk ("we neither develop nor modify AI systems, so provider-specific controls don't apply").

Why it disproportionately reassures an auditor

A clean SoA signals a mature system: it shows you know the full control landscape, made deliberate choices, and can point to evidence for each. A missing or vague SoA has the opposite effect — it suggests the system was assembled document by document without ever being checked against the standard as a whole. The SoA is your proof that you saw the forest, not just the trees.

The discipline. Write the SoA as the last document, from evidence that already exists, and treat every exclusion as a sentence you'll have to say to an auditor's face. If you can't defend it out loud, don't exclude it.
BJ

Former IBM and Deloitte strategy consultant, now advising mid-market companies on AI governance. Founder of Govern42.

Questions about your ISO 42001 or EU AI Act programme? Email me directly: bigjay11@gmail.com

Educational orientation, not legal advice. ISO/IEC 42001 references current as of September 2026. Certification is performed by accredited bodies.