Welcome back to the part of the standard you had been quietly hoping was optional. It is not. We have arrived at Annex A of ISO/IEC 42001:2023 — the section where ten clauses of orderly principle finally cash themselves out as a list of things you are expected to actually do, with documents, and with somebody’s name on each line. Thirty-eight controls. Nine sections. One Statement of Applicability. No, you cannot just keep the ones you like.
If Clauses 4 through 10 told you to think about your AI management system, Annex A tells you, in alphabetical-numerical order, what specifically there is to think about. It is the homework, and there is a great deal of it.
What Annex A Actually Is (and What It Is Not)
Two preliminary points, because both come up in every kickoff meeting.
First: Annex A is normative. It is part of the requirements of the standard, not optional reading material. Do not let the word “Annex” lull you into thinking otherwise. (Annex B, on implementation guidance, is informative — that is the one you can use as a doorstop. Annex A is not.)
Second: Annex A is a reference list, not a mandate that all 38 controls apply to every organisation. You are expected to determine which controls apply to you, based on the risks identified under Clause 6.1, and document that determination in a Statement of Applicability (SoA). If you have read ISO 27001, you recognise the SoA; it is the spreadsheet ISO has now insisted you produce for AI as well. If you have not, congratulations: you are about to.
The Nine Sections, A.2 Through A.10
There is no A.1 to speak of — that is just the section header. The substantive material starts at A.2. The sections, in the order ISO put them, are:
A.2 — Policies Related to AI
The high-level governance documents. You shall have an AI policy, aligned with other organisational policies, approved by management, communicated, and reviewed at planned intervals. Yes, in writing. No, the deck from the AI strategy offsite does not count.
A.3 — Internal Organization
Roles, responsibilities, and authorities for AI. The control that produces the inevitable RACI matrix and the equally inevitable argument about who owns model monitoring versus who owns the platform it runs on. The standard expects AI responsibilities to be formally assigned, not merely assumed by whoever happened to be in the meeting.
A.4 — Resources for AI Systems
What you need to run the AIMS: data, tooling, system and compute resources, and humans with the relevant competence. You are expected to identify and document these as resources, not merely have them. “We have a data team” is not documentation. A list of named systems, datasets, environments, and accountable owners is.
A.5 — Assessing Impacts of AI Systems
The AI impact assessment lives here. This is the bespoke 42001-flavoured cousin of the privacy impact assessment, and the control most likely to be entirely new to your organisation. You will need a documented method, criteria for triggering it, and a retained record of each assessment performed. The scope is broad: effects on individuals, groups, and society at large.
A.6 — AI System Life Cycle
The largest and most operational section, and the one your engineering function will end up living inside. Requirements for objectives, design, development, verification and validation, deployment, operation, monitoring, and decommissioning. Technical documentation. Event logging. Post-release monitoring. This is where the standard intersects most directly with what your ML teams were already doing — and where they will learn they were doing it for ISO too.
A.7 — Data for AI Systems
Data quality, provenance, preparation, and the management of training, validation, and operational datasets. The control that finally puts in writing the requirement to know where your training data came from and what was done to it before it became a model. Auditors will be very interested. So, increasingly, will regulators.
A.8 — Information for Interested Parties of AI Systems
What you tell users, customers, regulators, and affected third parties about the AI systems you provide or operate. Purpose. Intended uses. Limitations. Channels for reporting problems. The mechanism by which a person finds out that the thing making decisions about them is, in fact, a model.
A.9 — Use of AI Systems
The operational controls — responsible use, intended use, and monitoring use against intent. This is where “we deployed the chatbot for customer support and it has been quietly recommending mortgages” becomes a documented nonconformity rather than a quarterly anecdote.
A.10 — Third-Party and Customer Relationships
Supplier and customer responsibilities. What you require of vendors who supply AI components or training data; what you communicate to customers who consume AI you provide. Procurement, contracts, and the small print no one has previously read but which is now, per ISO, the basis of your assurance posture.
What Changed, What’s New, What’s Genuinely Novel
A few things deserve highlighting, because they are the parts of Annex A that will quietly consume the most time in your first implementation cycle.
The Statement of Applicability is now mandatory for AI. This is the structural import from ISO 27001, and the document that will, in practical terms, dominate your audit. Each of the 38 Annex A controls must be marked applicable or not, with justification, with implementation status, and (when applicable) a reference to where it is implemented. There is no shortcut. The SoA is, somewhat humorously, the deliverable that proves the deliverables.
A.5 has no direct analogue elsewhere. ISO 27001 has risk assessment. GDPR has DPIAs. NIST AI RMF has its own framing. The AI impact assessment is none of those, quite. It considers harms to individuals, groups, and society, and must be revisited whenever a system materially changes. Most organisations will be building it from scratch.
A.10 puts customers, not just suppliers, on the page. Most management-system standards talk about supplier oversight. A.10 also requires you to inform and instruct your customers about the responsible use of AI you provide. Governance under 42001 is bidirectional — and the obligations are in writing.
Annex B exists, and is useful. Annex B (informative) provides implementation guidance for each Annex A control; Annex C lists potential organisational objectives and risk sources. Neither is a requirement, but the auditor will assume you have read them, and your life will be easier if that assumption is correct.
An Editorial Aside
There is something faintly poignant about the fact that ISO/IEC 42001 — the world’s first AI management system standard — concludes with a spreadsheet. Thirty-eight rows. A few columns. The whole apparatus of modern machine learning reduced, at last, to the same instrument that governs information security at a regional bakery chain. I do not say this disapprovingly. Governance has always been the art of pointing at people. ISO 42001 is, at minimum, an unusually well-organised pointer.
Closing
And so we reach the structural end of the standard — Clauses 1 through 10, plus the normative Annex A and its 38 controls. The series will not end here, however. Each of the nine Annex A sections deserves its own treatment, and each will in due course receive one. Next time: A.2 — Policies Related to AI, the section that finally requires your organisation to write down what it actually thinks about artificial intelligence. Try to have an opinion ready. I will see you there.