ISO 42001 Statement of Applicability: how to write one
The ISO 42001 Statement of Applicability is the document a certification auditor reads first, and in most AI management systems it is the one written last, in a rush, once everything else feels finished. That order is backwards. The SoA is not a summary of the work — it is the single place where your AI risk assessment, your control decisions and your implementation status become visible in one view, and it is what an auditor uses to decide how hard to look at everything else.
Get it right and stage 1 moves quickly, because the logic of your AI management system is legible without being explained. Get it wrong and you spend the audit narrating a document that should have been doing the narrating for you.
Most guides on this topic explain what an SoA is. This one shows what a defensible row looks like next to one that will not survive an audit, and which exclusion justifications actually hold for an AIMS.
Building the documented set from scratch? The ISO 42001 Compliance Suite includes the Statement of Applicability pre-populated with all 38 Annex A controls, alongside the sixteen procedures and nine registers clauses 4 to 10 require. €590 excl. VAT.
What clause 6.1.3 actually requires
Clause 6.1.3 of ISO/IEC 42001:2023 covers AI risk treatment, and the Statement of Applicability requirement sits inside it rather than in a clause of its own — which is one reason organisations coming from ISO 27001, where it has its own lettered sub-clause, sometimes miss how much weight it carries here.
The sequence the clause sets out: determine the risk treatment options for each risk identified in your AI risk assessment (6.1.2), determine the controls necessary to implement the treatment you chose, then compare that set against Annex A to verify nothing necessary has been overlooked. The output of that comparison, recorded with a decision and a justification for every control, is the Statement of Applicability.
Annex A is formally informative — the same status it holds in ISO 27001 — which means it is a reference set, not a mandatory list. The normative requirement is the process in 6.1.3: determine controls from your risk treatment, check the set against Annex A for completeness, document the result. An organisation may include controls that are not in Annex A at all, if the risk treatment produced them. Almost nobody exercises that option, and when an auditor sees it, it is usually the strongest signal in the room that the AIMS is real rather than assembled from a template.
The word doing the most work in the clause is justification, required for both inclusion and exclusion. Most Statements of Applicability answer the exclusion half adequately and the inclusion half with “required by the standard” — which is not a justification, it is a restatement of the fact that the control appears in Annex A.
The SoA is downstream of two things, not one
In ISO 27001 the SoA is downstream of the risk assessment alone. In ISO 42001 it is downstream of two processes, and the second one is easy to lose sight of.
The AI system impact assessment, required under clause 6.1.4 with no equivalent in ISO 27001, asks a different question from the risk assessment: not what could go wrong for the organisation, but what consequences the AI system has for individuals, groups and society — including when the system performs exactly as designed. A model that scores accurately overall and worse for one demographic subgroup has not failed in the risk-assessment sense. It has produced exactly the kind of finding the impact assessment exists to surface.
That finding has to reach the SoA. If your impact assessment identifies a fairness concern for a specific population and your Statement of Applicability shows A.5 — assessing impacts of AI systems — as a thin, boilerplate justification with no reference to that finding, the two documents are describing different organisations. Auditors read both, and they read them together.
The practical test: pick any included control and ask which risk or which impact-assessment finding it treats. If the answer is a specific reference, the chain holds. If the answer is “because it’s in Annex A”, the SoA is a compliance artefact rather than a working part of the management system — and that gap surfaces within the first twenty minutes of a competent stage 2 audit.
The anatomy of an ISO 42001 Statement of Applicability row
Annex A groups 38 controls under nine objectives, numbered A.2 through A.10: policies related to AI (A.2), internal organisation and reporting of concerns (A.3), resources for AI systems — data, tooling, computing, human (A.4), assessing impacts of AI systems (A.5), objectives for responsible development and the AI system life cycle (A.6), data for AI systems (A.7), information for interested parties (A.8), responsible use of AI systems (A.9), and third parties, suppliers and customers (A.10).
Your SoA covers all 38, including the ones you exclude. A table listing only the controls you applied is not a Statement of Applicability — the exclusions and their justifications are exactly half of what clause 6.1.3 asks for, and it is usually the half that gets skipped.
A workable structure needs six columns:
| Column | What goes in it |
|---|---|
| Control reference and title | A.6.2 AI system life cycle — as written in Annex A |
| Applicable | Yes or No |
| Justification | Why included, or why excluded — one or two sentences, specific |
| Implementation status | Implemented, partially implemented, planned with a date |
| How it is implemented | The procedure, register or record that realises the control |
| Risk or impact-assessment reference | The risk ID or impact-assessment finding this control addresses |
The last column is what turns the document from a list into evidence. It is the fastest way to demonstrate that the SoA is downstream of your risk and impact processes rather than copied from Annex A, and it costs one column.
Keep justifications to a sentence or two. An SoA records decisions, not the reasoning behind them in full — if a justification needs a paragraph, what it actually needs is a pointer to the procedure or register where that reasoning lives.
Worked rows: what good and bad look like
Take A.6.2, the AI system life cycle control, covering design through retirement.
A weak row: applicable, justification “required for AI systems”, status “implemented”, implementation “we manage the lifecycle of our models”. Every field is populated and none of it can be checked. Managed how, by whom, recorded where?
A strong row: applicable, justification “addresses risk R-009, model drift in the credit-scoring system going undetected between quarterly reviews”, status implemented, implementation “AIMS-08 AI System Life Cycle procedure, stage-gate reviews at design, validation, deployment and retirement, output logged in the life cycle record”, risk reference R-009. An auditor reading that knows exactly what to sample next.
Now take A.10, third parties, suppliers and customers, for an organisation whose AI systems are built entirely in-house.
A weak exclusion: not applicable, justification “we don’t use third parties”. That is a claim about the organisation in general, and it invites the obvious follow-up about the cloud infrastructure, the base model, or the labelled training data the system almost certainly touches somewhere.
A strong exclusion: not applicable, justification “the AIMS scope covers the fraud-detection model family; all models are trained from first principles on internally generated data, with no third-party pretrained models, no third-party training data providers and no subcontracted AI development. Infrastructure hosting is assessed separately under the organisation’s ISO 27001 supplier controls, outside AIMS scope. This exclusion is reassessed if a model incorporating externally sourced components enters scope.” The exclusion rests on a specific, checkable fact about scope, and it names where the adjacent concern — hosting — is actually handled.
That is the shape of every exclusion that holds: a fact about what is or is not in scope, plus where the related concern is managed if it exists elsewhere.
Which exclusion justifications hold
Accepted, because they describe scope or context rather than convenience:
- The activity does not exist in scope. A.7’s data-provenance controls, where the AI system in scope uses no externally sourced training data.
- The asset type does not exist. Sub-controls under A.4 covering specialised AI compute infrastructure, where the organisation exclusively uses managed inference APIs and holds no training infrastructure of its own.
- The relationship does not exist, and you can show it. A.10’s third-party controls, for a system built and trained entirely in-house — the example above, provided the boundary is genuinely accurate.
- The obligation sits with another party, with that party’s assessment on record. A foundation-model provider’s model card and safety documentation, referenced rather than reproduced, where your system is a thin application layer over it.
Rejected, reliably, because they are statements about resourcing or convenience rather than applicability:
- “Not applicable, low-risk system.” A low-risk classification under your impact assessment scales how deeply a control is implemented. It does not remove the control. A.5’s impact-assessment requirement in particular does not become optional for a low-impact system — it is the process that concluded the system was low-impact in the first place, and that conclusion has to be documented like any other.
- “Not applicable, the vendor handles it.” Naming a foundation-model or cloud provider transfers some operational work, not the obligation to assess and monitor them. That assessment is the evidence, not the transfer itself.
- “Not applicable, we’re a small team.” Organisation size affects the depth of implementation, never whether a control applies.
- “Not applicable, it overlaps another control.” Overlap between AI policy (A.2) and life-cycle governance (A.6) is normal by design in a management-system standard built on the harmonised structure. Both are applicable.
- Blank. An empty justification field is a nonconformity against an explicit clause requirement, and the easiest one for an auditor to raise without needing to sample anything.
The mistakes that come back as findings
Beyond individual rows, a handful of structural problems drive most SoA findings in AIMS audits specifically.
The SoA that ignores the impact assessment. A.5 is marked implemented with a generic justification, while the impact assessment register shows an unresolved finding for the same system. Two documents in the same evidence pack, describing two different levels of maturity. This is the failure most specific to ISO 42001, because it is the one connection auditors familiar with ISO 27001 will check precisely because it has no equivalent there.
The SoA that contradicts the rest of the AIMS. It marks A.9, responsible use of AI systems, as fully implemented; the internal audit report from three months earlier flags inconsistent human-oversight logging. Both are in the pack. This is the failure that puts every other row in doubt.
The SoA nobody owns. No one is responsible for updating it, so it gets touched once a year, shortly before a surveillance audit, by whoever happens to be free. Assigning it to whoever maintains the AI risk register fixes this permanently, because the two documents change together.
Everything marked implemented. In a real AIMS, some controls are partial or planned at any given time — a new model family entering scope, a life-cycle stage not yet run end to end. Thirty-eight controls out of thirty-eight showing fully implemented on the day of stage 1 reads as aspirational, and auditors sample accordingly: they will pick the three that look least plausible and ask for evidence first.
The SoA that has never changed. A new AI system entered scope, or an existing one moved from pilot to production, and the SoA still describes the earlier state. Because so much else references it, a stale SoA quietly invalidates the documents pointing at it.
Where it sits if you already hold ISO 27001
Organisations that already run an ISO 27001 ISMS are not starting from nothing. The management-system clauses — context, leadership, planning, support, operation, evaluation, improvement — follow the same harmonised structure, and the SoA mechanism itself is one you already operate.
What does not transfer is Annex A. The two control sets address different risk domains, and roughly half of the ISO 42001 controls — the AI-specific ones under A.5 through A.9 — have no ISO 27001 equivalent to map from. Reusing the SoA format saves real time. Reusing SoA content control by control does not work past the shared management-system controls, and treating the AI-specific rows as a formality because “we already did this for 27001” is exactly how the impact-assessment gap above happens.
Keeping it alive
The SoA also defines the boundary of what your internal audit under clause 9.2 has to sample, so a stale SoA quietly narrows your own audit scope along with it.
Three triggers, not a calendar: the SoA changes when the AI risk assessment changes, when the impact assessment produces a new finding, and when a system’s implementation status moves — a model entering production, a life-cycle stage completing, a new AI system entering scope entirely.
Version it with a date and a change record. Management review under clause 9.3 should compare this version against the last one and expect to be able to explain every difference — being unable to is the finding, not the difference itself.
Once a year, take the ten rows with the thinnest justifications and check whether they still describe what the organisation actually does. That review takes about an hour, and it is where contradictions with the rest of the AIMS surface before an auditor finds them instead.
If you are still assembling the rest of the documented set, our ISO 42001 checklist works through the seventeen documented-information requirements and all 38 Annex A controls by what produces evidence, and the AI system impact assessment guide covers what auditors expect from the process that feeds A.5 specifically. If you already hold ISO 27001, what actually transfers maps the two control sets clause by clause rather than by the round-number percentages most comparisons quote.
Frequently asked questions
Is the Statement of Applicability mandatory under ISO 42001? Yes. Clause 6.1.3 requires it as part of AI risk treatment, and certification bodies request it before stage 1. There is no route to certification without one.
Does the SoA have to list all 38 Annex A controls? Yes. The clause requires a justification for excluding any Annex A control, which is only possible if every control appears with a recorded decision. A document listing only the controls you applied is incomplete.
Can we exclude controls and still be certified? Yes, and most organisations exclude some. What matters is that each justification is a fact about scope or context rather than a preference, and that it does not contradict something else in the AIMS or the impact assessment.
What is the difference between the SoA and the AI risk treatment plan? The treatment plan says what will be done, by whom, and by when, for each identified risk. The SoA records which Annex A controls are necessary, why, and their current status. Clause 6.1.3 requires both, and they are related but not interchangeable.
Does the SoA need to reference the impact assessment as well as the risk assessment? The clause does not name the impact assessment explicitly, but a Statement of Applicability that only traces to the risk register while ignoring impact-assessment findings under A.5 is the gap auditors familiar with the standard check first, precisely because it has no ISO 27001 equivalent to fall back on.
Does it have to be a spreadsheet? No. It needs the required elements and to be under document control. A spreadsheet is the common choice because thirty-eight rows filter more easily than they read as prose.
Sources
ISO/IEC 42001:2023, in particular clauses 6.1.2, 6.1.3, 6.1.4 and 9.3, and Annex A.