The shape of Annex A
Lesson 1 of 4 in Annex A Controls and Annexes B, C, D: The Control Framework.
Clauses 4–10 built the engine of your AIMS. Annex A is the cargo it carries: a normative catalogue of 38 controls organised into nine groupings, A.2 through A.10, covering everything from the AI policy on the wall to the contract terms with your GPAI supplier.
The mechanics matter, because people constantly get them wrong. Annex A is normative — it is part of the standard, not a suggestion — but you do not blindly implement all 38 controls. Clause 6.1.3 makes you run your risk treatment process, determine which controls are necessary to treat your risks, compare your chosen controls against Annex A to make sure nothing essential was overlooked, and then record the result in a Statement of Applicability: every Annex A control listed, marked applicable or not, with a justification either way.
So the direction of travel is risk → controls → Annex A as a completeness check — not Annex A → checklist → done. An auditor who finds all 38 controls marked ‘applicable’ with identical boilerplate justifications has learned something important: the organisation ran a checklist, not a risk treatment.
Here is the whole territory in one table. Notice the arc: the groupings run roughly from organisational (policy, roles) through system-level (impacts, lifecycle, data) to relational (information for others, responsible use, supply chain). That arc is deliberate — it mirrors how accountability flows from the boardroom to the model to the market.
| Grouping | Objective in plain language | Controls | Flagship evidence |
|---|---|---|---|
A.2 Policies related to AI | Management direction for AI exists on paper, aligns with other policies, and stays current | 3 | Signed AI policy, alignment mapping, review records |
A.3 Internal organization | Someone owns every AI accountability, and anyone can raise a concern safely | 2 | RACI / role assignments, concern-reporting channel and its usage records |
A.4 Resources for AI systems | You know and document what every AI system runs on: data, tooling, compute, people | 5 | Resource inventories per system, competency records |
A.5 Assessing impacts of AI systems | A process exists to assess consequences for individuals, groups, and society — and it is used | 4 | Impact assessment procedure and completed assessments (see ISO/IEC 42005) |
A.6 AI system life cycle | Responsible development is engineered in: requirements, design records, V&V, deployment, monitoring, technical documentation, event logs | 9 | Lifecycle procedure, design docs, test reports, logs |
A.7 Data for AI systems | Data is managed as a first-class engineering object: acquisition, quality, provenance, preparation | 5 | Data management process, provenance records, quality criteria (see ISO/IEC 5259) |
A.8 Information for interested parties | The people who use and are affected by your systems get the information they need — including bad news | 4 | User documentation, incident communication plan, external reporting channels |
A.9 Use of AI systems | Your own use of AI (including bought-in AI) is governed: responsible-use processes, objectives, intended-use discipline | 3 | Acceptable-use process, documented intended use per system |
A.10 Third-party and customer relationships | Responsibility across the AI supply chain is allocated on purpose, in writing — upstream and downstream | 3 | Supplier assessments, contracts with AI clauses, customer-facing responsibility statements |
Where does Annex B fit? Every Annex A control has a matching section of Annex B — implementation guidance. Annex B is informative: it tells you how organisations typically satisfy a control (what a data provenance record might contain, what an impact assessment process might cover), but none of it is auditable requirement text. The pattern is borrowed straight from information security, where ISO/IEC 27001 Annex A lists the controls and ISO/IEC 27002 explains them — except 42001 ships the guidance inside the same document, so there is no separate ‘42002’ to buy.
Read Annex B the way an experienced implementer does: as a menu of acceptable shapes for evidence, not a template to copy. An auditor cannot write a nonconformity against Annex B — but if you ignore its guidance entirely, you had better be able to explain what you did instead and why it satisfies the control.
Key terms: Statement of Applicability, Annex A control (ISO 42001), normative vs informative, risk treatment, AI management system
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.