ISO/IEC 42001
Annex A and Annex B — Reference control objectives and controls · Implementation guidance for AI controls
Both annexes are normative. Annex A carries the reference control objectives and controls; Annex B carries the implementation guidance for the same numbered controls, across twenty-five pages. Commentary routinely calls Annex B informative, and the standard’s own contents page says otherwise — which changes what an assessor may hold an organisation to.
§ 1 — Who it binds
Who the annexes reach, and how
Audited organisation
Every organisation seeking or holding certification to ISO/IEC 42001, and every organisation running an AIMS without certification that wants its control selection to be defensible. The annexes are reached through the risk treatment process rather than adopted directly: the organisation determines the controls it needs, compares that set against Annex A, and records the outcome. Nothing requires an organisation to implement every control in the annex.
§ 2 — In practice
Normative means an assessor may use it
Normative means an assessor may work from it. Annex A supplies the control objectives and controls against which a determined control set is compared, in four pages; Annex B supplies, for the same numbered items, the implementation detail, in twenty-five. Where a guidance annex is advisory, an organisation may take a different route to the same outcome and owes nobody an account of the choice. Where it is not, a departure is a position the organisation has taken and should be able to explain. Implementers arriving from another management-system standard commonly expect the guidance half to be advisory and treat it that way, and the cost of the mislabelling is not usually a missed requirement — it is that nobody recorded why something was done differently.
Annex A is a reference set, which cuts both ways and is widely read in only one direction. Controls may be excluded where the organisation can justify the exclusion, and controls not in Annex A may be added where the risk work calls for them. That is a different instrument from a catalogue to be implemented entire. The direction of travel is what people invert: the organisation determines the controls it needs from its own risk treatment, then compares that set against Annex A to see what it has missed, and records the result. Starting from the annex and working backwards to the risks produces a document that lists everything and explains nothing, and the inversion is visible in the artefact, because no control on it can be traced to an assessed risk.
The document recording those decisions originates in the risk treatment clause, 6.1.3, and not in the annexes — which is why practitioners looking for it in Annex A cannot find where it is required. What it has to carry is a decision per control, a justification per decision, and a route back to the risk work. An AI risk assessment that produced no criteria will produce no such route, because there is nothing to explain why one control was necessary and another was not, and the statement then arrives at assessment as an assertion rather than a conclusion.
The control set covers ground an assurance practitioner will recognise from elsewhere, and that is the useful way to approach it. There are control areas for policy and its alignment with the organisation’s other policies; for roles and responsibilities; for resources including data, tooling, compute and people; for impact assessment; for responsible design, development, verification and validation, deployment, operation and monitoring; for technical documentation and event logging; for data quality, provenance and preparation; for information supplied to users and to interested parties, and for the communication of incidents; for responsible use; and for the allocation of responsibility between an organisation, its suppliers and its customers. Several of those name the same artefact a regulator demands — an event log under Article 12, data governance evidence under Article 10, verification results under Article 15 — which is where one piece of evidence can genuinely serve two purposes. The numbering above is deliberately absent: the only inventory available outside the standard is a crosswalk written against the FDIS whose text layer carries scanning artefacts, so it is a reliable map of what the annex covers and an unreliable source for any control’s title.
What follows from getting this wrong is not a fine. ISO/IEC 42001 is voluntary, no regulator enforces it, and no penalty attaches to any part of the annexes. The exposure is that a certification body operating to ISO/IEC 42006 examines the applicability statement and the evidence behind it, and a certificate can be refused, suspended or withdrawn on what it finds. That is a commercial consequence rather than a legal one, and it is the honest thing to tell a board — which also means an organisation not seeking certification is free to use the annexes as a control framework and owes the decisions to itself alone.
§ 3 — What a weak answer looks like
The statement that excludes nothing
The applicability statement inherited from a consultant. Every control appears, every justification is the control’s own subject matter turned into a sentence of compliance, and the exclusions column is empty because excluding nothing felt safer. It reads as complete and evidences nothing: there is no route from any assessed risk to anything on it, so the document records what the standard lists rather than what the organisation decided. The version history usually settles the matter — a single entry, dated the week the certification programme began.
§ 4 — What discharges it
What the applicability file must hold
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
The applicability statement, with a decision and a justification per control
Two fields that cannot be inferred from one another: what was decided, and the reasoning that produced it. A justification restating the control’s own subject matter as a claim of compliance has recorded an intention, not a determination.
02
Operating evidence for every control marked applicable
Something the control produced while running — a record, a log, an approval, a rejected change — rather than the document that describes it. Adoption and operation are different claims and only the second can be sampled.
03
The trace from treatment decisions to selected controls
Each control tied back to the risk it treats and the decision that chose it, so selection is a conclusion rather than an inheritance. This is the thread that is missing whenever the statement was filled in before the risk work was finished.
04
Controls adopted beyond the annex, with their reasoning
What the organisation added because its own analysis called for it, and why the reference set did not cover the ground. An estate with unusual exposure and no additions suggests the annex was treated as the boundary of what could be considered.
05
The organisation’s position on the Annex B guidance, per control
Because that annex is normative rather than advisory, what was done with its implementation detail is part of what an assessor may work from — including, for each departure, what was done instead and on what reasoning.
06
The applicability review record after a scope or risk movement
Dated revisits triggered by a boundary change, a new system, or a material shift in the risk picture, with what changed as a result. A statement whose only version is the original was written for a certificate rather than for use.
§ 5 — Worked example
Worked example — everything applicable, nothing traced
A medical-imaging vendor completes its applicability statement ahead of certification. It lists every Annex A control, marks all of them applicable, and against each writes "implemented — see AI policy section 4" or "implemented — see MLOps handbook". Nothing is excluded, on the reasoning that an exclusion invites questions. The risk treatment plan is a separate document and references no control at all.
Why does marking everything applicable create more work at assessment rather than less?
Because applicability is a claim about implementation, and the vendor has now made that claim thirty-odd times. Every control marked applicable may be sampled, and each one needs evidence that it operates rather than a pointer to a document mentioning it — "see AI policy section 4" establishes that a policy exists, which is not the same as a control running. A justified exclusion costs a paragraph and closes the subject; an unjustified inclusion costs an evidence file. The second problem is the missing thread. Annex A is the reference set an organisation compares its own determined controls against, and that determination happens in risk treatment; with the treatment plan carrying no control numbers, nothing demonstrates that any control was selected because of an assessed risk, so the statement reads as a catalogue adopted whole. The repair runs in the direction the standard sets — risk, treatment decision, control, evidence — and the exclusions fall out of it with their reasons already attached.
§ 6 — Elsewhere
Where the controls are examined by somebody else
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
IIA Standard 13.4 names authoritative frameworks and standards as an acceptable source of evaluation criteria. The Annex A control objectives are one such source when an engagement needs something stated to measure an activity against.
ISO/IEC 42006:2025 sets requirements for bodies certifying AI management systems. The applicability statement and the evidence behind each included control are part of what such a body examines before a certificate is issued.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 7 — When it applies
The two editions, and what the dates mean
31 December 2023
Publication date of the BSI adoption of the first edition; an edition date, not a compliance deadline.
31 March 2026
European and UK adoption, BS EN ISO/IEC 42001:2026 — BSI states no technical differences in the requirements or guidance.
§ 8 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
- ISO/IEC 42001:2023 free document preview — official contents page, listing Annex A (normative) Reference control objectives and controls at page 17 and Annex B (normative) Implementation guidance for AI controls at page 21, with Annexes C and D marked informative.
- BSI Knowledge product record for BS ISO/IEC 42001:2023, published 31 December 2023, ISBN 978 0 539 15269 2.
- BSI Knowledge product record for BS EN ISO/IEC 42001:2026, published 31 March 2026 — no technical differences from the 2023 text.
- NIST-hosted crosswalk attributed to Microsoft and written against ISO/IEC FDIS 42001. The only inventory of Annex A and B control areas reachable outside the paywalled standard; used here for coverage, not for titles.
- NIST AIRC crosswalk index, which hosts the document and attributes it to Microsoft — the basis for describing it as NIST-hosted rather than as NIST guidance.
§ 9 — Also read
Also read
Evaluation criteria for an AI audit — IIA Standard 13.4
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.