Annex A of ISO/IEC 42001:2023 is the control catalogue of the AI Management System standard: 38 controls grouped into 9 domains numbered A.2 through A.10. Like its ISO 27001 counterpart, Annex A is a menu — you assess each control against your scope and AI-related risks, apply the ones that fit, and record every applicable-or-excluded decision with justification in your Statement of Applicability (SoA). This page lists every control by reference and title, with a one-line description of what it covers. Implementation detail for each control lives in Annex B of the standard.
New to the standard? Start with our ISO/IEC 42001 practical guide for the full picture — clauses 4–10, the EU AI Act relationship, and the certification roadmap — then come back here for the control-level detail.
How the 38 Controls Are Organized
Each domain represents an AI governance objective; the controls beneath it are the mechanisms that achieve it. The numbering looks odd at first — controls start at .2, not .1 — because the .1 sub-clause of each domain holds the control objective statement itself. A.6 (AI system life cycle) is the largest domain with 9 controls and is split into two sub-objectives: responsible development (A.6.1) and life-cycle processes (A.6.2).
- A.2 Policies related to AI — 3 controls
- A.3 Internal organisation — 2 controls
- A.4 Resources for AI systems — 5 controls
- A.5 Assessing impacts of AI systems — 4 controls
- A.6 AI system life cycle — 9 controls
- A.7 Data for AI systems — 5 controls
- A.8 Information for interested parties — 4 controls
- A.9 Use of AI systems — 3 controls
- A.10 Third-party and customer relationships — 3 controls
The Complete Controls List
A.2 — Policies related to AI · 3 controls
| Ref | Control | What it covers |
|---|---|---|
| A.2.2 | AI policy | Establish, document, and communicate a policy governing AI development and use. |
| A.2.3 | Alignment with other organisational policies | Align the AI policy with existing policies — security, data protection, ethics. |
| A.2.4 | Review of the AI policy | Review the AI policy at planned intervals and when circumstances change. |
A.3 — Internal organisation · 2 controls
| Ref | Control | What it covers |
|---|---|---|
| A.3.2 | AI roles and responsibilities | Define and allocate AI-related roles, responsibilities, and accountability. |
| A.3.3 | Reporting of concerns | Provide a channel for reporting concerns about AI systems without fear of reprisal. |
A.4 — Resources for AI systems · 5 controls
| Ref | Control | What it covers |
|---|---|---|
| A.4.2 | Resource documentation | Document the resources AI systems depend on across their life cycle. |
| A.4.3 | Data resources | Identify and document data resources used by AI systems. |
| A.4.4 | Tooling resources | Manage and document the tools used to develop and operate AI systems. |
| A.4.5 | System and computing resources | Document the systems and computing infrastructure AI systems run on. |
| A.4.6 | Human resources | Ensure people working on AI have documented competence, roles, and awareness. |
A.5 — Assessing impacts of AI systems · 4 controls
| Ref | Control | What it covers |
|---|---|---|
| A.5.2 | AI system impact assessment process | Define and apply a process to assess impacts before and during the AI life cycle. |
| A.5.3 | Documentation of AI system impact assessments | Document assessment results so decisions and reasoning are auditable. |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Evaluate how each AI system affects the people subject to its outputs. |
| A.5.5 | Assessing societal impacts of AI systems | Evaluate broader societal effects — fairness, labour, environment, institutions. |
A.6 — AI system life cycle · 9 controls
| Ref | Control | What it covers |
|---|---|---|
| A.6.1.2 | Objectives for responsible development of AI system | Set and document objectives for responsible AI development. |
| A.6.1.3 | Processes for responsible design and development of AI systems | Apply defined responsible-development processes in design and build. |
| A.6.2.2 | AI system requirements and specification | Specify requirements — functional, data, transparency, safety — before building. |
| A.6.2.3 | Documentation of AI system design and development | Record design and development decisions so the system can be understood and audited. |
| A.6.2.4 | AI system verification and validation | Verify the system meets its requirements and validate it does what is intended. |
| A.6.2.5 | AI system deployment | Control how AI systems are released into production and into which environments. |
| A.6.2.6 | AI system operation and monitoring | Operate and monitor systems against defined performance and behaviour expectations. |
| A.6.2.7 | AI system technical documentation | Maintain technical documentation for interested parties across the life cycle. |
| A.6.2.8 | AI system recording of event logs | Keep logs of AI system events sufficient for incident investigation and accountability. |
A.7 — Data for AI systems · 5 controls
| Ref | Control | What it covers |
|---|---|---|
| A.7.2 | Data for development and enhancement of AI system | Govern the data used to develop and improve AI systems. |
| A.7.3 | Acquisition of data | Control how training and operational data is sourced — including legality and rights. |
| A.7.4 | Quality of data for AI systems | Define and enforce data quality criteria appropriate to each AI system. |
| A.7.5 | Data provenance | Document where data came from and how it was processed — lineage you can show. |
| A.7.6 | Data preparation | Control data preparation: cleaning, labelling, augmentation, and their effects on bias. |
A.8 — Information for interested parties of AI systems · 4 controls
| Ref | Control | What it covers |
|---|---|---|
| A.8.2 | System documentation and information for users | Provide users documentation covering capabilities, limitations, and intended use. |
| A.8.3 | External reporting | Enable external parties to receive or request information about AI systems. |
| A.8.4 | Communication of incidents | Define how AI incidents are communicated to affected and interested parties. |
| A.8.5 | Information for interested parties | Determine and provide the information interested parties need about your AI systems. |
A.9 — Use of AI systems · 3 controls
| Ref | Control | What it covers |
|---|---|---|
| A.9.2 | Processes for responsible use of AI systems | Define and follow processes so AI systems are used responsibly. |
| A.9.3 | Objectives for responsible use of AI system | Set measurable objectives for how AI systems should be used. |
| A.9.4 | Intended use of the AI system | Use AI systems only for their intended purposes, with human oversight appropriate to the context. |
A.10 — Third-party and customer relationships · 3 controls
| Ref | Control | What it covers |
|---|---|---|
| A.10.2 | Allocation of responsibilities | Allocate responsibilities between your organisation, suppliers, partners, and customers. |
| A.10.3 | Suppliers | Ensure suppliers of AI products, components, or data meet your responsible-AI expectations. |
| A.10.4 | Customers | Manage customer relationships so AI systems are used as intended — including expectations set in agreements. |
How to Select Controls: The Statement of Applicability
Annex A is not a checklist where everything is mandatory — it is a reference set you filter through your context. The mechanism is identical to ISO 27001: for each control, your SoA records whether it applies, why, and its implementation status. The drivers of applicability are your AIMS scope (Clause 4.3), your AI risk assessment, and your AI system impact assessments — the domain A.5 controls generate the very inputs that determine which other controls you need.
Two practical rules: first, role matters — an organisation that develops AI systems needs nearly all of A.6 and A.7, while an organisation that merely uses third-party AI concentrates on A.9 (responsible use) and A.10 (third-party relationships). Second, exclusions need reasons — "we don't develop models" is a valid justification for skipping data-preparation controls; "too hard" is not. Our Statement of Applicability guide covers the mechanics in depth — the SoA pattern is shared across both standards.
What Auditors Expect to See
For each applicable control, auditors want evidence the control operates — not just that a policy exists. Typical evidence: the approved AI policy (A.2.2), a RACI or org chart with named AI accountability (A.3.2), the AI system inventory with resource documentation (A.4.2), completed impact assessment reports per in-scope system (A.5.2–A.5.5), V&V records and deployment approvals (A.6.2.4–A.6.2.5), monitoring dashboards and event logs (A.6.2.6–A.6.2.8), data lineage records (A.7.5), user-facing documentation like model or system cards (A.8.2), and supplier assessments for third-party AI (A.10.3). The pattern across all of them: documented process + records showing it ran.
Baseline Yourself in 10 Minutes
Our free ISO 42001 AI Readiness Assessment walks you through the clauses and Annex A domains as a structured questionnaire — it produces a maturity score, a prioritized gap list, and a downloadable PDF report, entirely in your browser. It's the fastest way to find out which of these 38 controls you already satisfy and which need work before you ever talk to an auditor.
Already running ISO 27001 or ISO 9001? Much of the management-system scaffolding carries over — check your baselines with our ISO 27001 Gap Analysis and ISO 9001 Readiness Checker, and see how the three standards integrate into one management system.
Frequently Asked Questions
How many controls are in ISO 42001 Annex A?
38 controls across 9 domains (A.2–A.10). By comparison, ISO/IEC 27001:2022 Annex A has 93 controls in 4 themes. The 42001 set is smaller because it focuses specifically on AI governance; information-security controls are referenced to ISO 27001 rather than duplicated.
Are all 38 Annex A controls mandatory?
No. Annex A is a reference set — you select applicable controls through the Statement of Applicability based on your scope, AI risk assessment, and impact assessments. What is mandatory is the process: you must evaluate all 38 and justify each inclusion or exclusion.
Why do the control numbers start at .2 instead of .1?
The .1 sub-clause in each domain contains the control objective statement — the goal that domain's controls achieve. The numbered controls therefore begin at .2. A.6 additionally splits into two sub-objectives (A.6.1 responsible development, A.6.2 life-cycle processes), each with its own objective statement.
Which controls matter most if we only use third-party AI?
A.9 (use of AI systems — all 3 controls apply) and A.10 (third-party relationships, especially A.10.2 responsibilities and A.10.3 suppliers), plus the cross-cutting governance controls A.2, A.3, and A.5 impact assessment. Development-heavy domains A.6 and A.7 largely shift to your vendors — which is exactly what A.10 exists to manage.
How does Annex A relate to the EU AI Act?
Annex A provides the management-system machinery — impact assessments, documentation, oversight processes — that regulators expect to see, but it doesn't replace AI Act conformity work. Think of it as complementary: the AIMS gives you the operational processes; the AI Act defines the legal obligations for in-scope systems. Many organisations map Annex A controls to AI Act requirements as part of their compliance program.
