ISO/IEC 42001 Annex A lists 38 reference controls for an AI management system, and most teams struggle to turn their short titles into evidence an auditor will accept. Annex A is normative: you must compare your AI risk treatment against it and record each control's inclusion or exclusion in a Statement of Applicability, while Annex B gives the implementation guidance. This guide walks control areas A.2 to A.10 one by one, in our own paraphrase, with the evidence each typically needs and what changes when the AI system is an autonomous agent acting with its own credentials. It is for AIMS owners, AI governance leads and auditors who already know the clause structure from the ISO/IEC 42001 Guide. It does not reproduce ISO text; buy the standard for the authoritative wording.
Key takeaways
- 38 controls in nine areas. Annex A runs from A.2 (AI policy) to A.10 (third parties and customers); A.1 is the annex introduction, not a control area.
- Selection is risk-based. Clause 6.1.3 requires comparing your chosen controls with Annex A and justifying any exclusion in the Statement of Applicability; you can also add controls of your own.
- Annex B mirrors Annex A numbering. Guidance for A.6.2.8 sits at B.6.2.8, so read them side by side.
- Impact assessment and life cycle carry the weight. A.5 and A.6 together hold 13 controls and generate most of the audit evidence.
- Agents stress three areas most. Event logging (A.6.2.8), intended use (A.9.4) and responsibility allocation with suppliers (A.10.2) only hold up if each agent has its own identity and scoped permissions.
How Annex A works
ISO/IEC 42001:2023 (edition 1.0, published 18 December 2023) applies to any organisation that provides or uses AI-based products or services. Its clauses 4 to 10 set the management system requirements; Annex A holds the reference control objectives and controls, Annex B the implementation guidance, Annex C potential AI objectives and risk sources, and Annex D use across sectors. The introduction stresses a risk-based approach so that the level of control fits each AI use case.
| Area | Theme (paraphrased) | Controls | Main clause links |
|---|---|---|---|
| A.2 | AI policy | 3 | 5.2 |
| A.3 | Internal organisation | 2 | 5.3 |
| A.4 | Resources for AI systems | 5 | 7.1 |
| A.5 | Assessing impacts of AI systems | 4 | 6.1.4, 8.4 |
| A.6 | AI system life cycle | 9 | 8.1 |
| A.7 | Data for AI systems | 5 | 8.1 |
| A.8 | Information for interested parties | 4 | 7.4 |
| A.9 | Use of AI systems | 3 | 8.1 |
| A.10 | Third-party and customer relationships | 3 | 8.1 |
The counts add to 38. Organisations playing several roles (developer, provider, deployer) will usually find most controls applicable; a pure user of third-party AI may justify narrowing parts of A.6 and A.7 but rarely excluding them outright.
A.2 AI policy and A.3 internal organisation
- A.2.2 AI policy: a documented policy for developing or using AI. Evidence: approved policy that states principles, scope and links to objectives.
- A.2.3 Alignment with other policies: identify where security, privacy, quality and procurement policies touch AI and make them consistent. Evidence: a short mapping or cross-references.
- A.2.4 Policy review: review at planned intervals and on significant change, such as adopting agentic systems. Evidence: review records.
- A.3.2 Roles and responsibilities: assign AI roles across the life cycle, including who approves deployment and who owns each system. Evidence: RACI and named system owners in the AI register.
- A.3.3 Reporting of concerns: a route for people to raise concerns about AI systems, with protection from retaliation. Evidence: channel description, logged reports and responses.
Agent angle: name a human owner for every agent, not just for the platform it runs on. That owner is who approves its permissions and answers when it acts unexpectedly. See the Agent Identity and Access Guide.
A.4 Resources for AI systems
A.4.2 asks you to identify and document the resources each AI system relies on; A.4.3 to A.4.6 break that down into data, tooling, system and computing, and human resources.
| Control | Paraphrased intent | Typical evidence | Agent angle |
|---|---|---|---|
| A.4.2 | Document resources per AI system | AI register entry listing components | Record each agent's tools, connectors and credentials |
| A.4.3 | Data resources | Dataset list with source and purpose | Include retrieval stores and memory the agent reads |
| A.4.4 | Tooling resources | Frameworks, model hosting, evaluation tools | List MCP servers and plugins the agent can call |
| A.4.5 | System and computing resources | Infrastructure, regions, capacity | Runtime identities and network egress |
| A.4.6 | Human resources and competence | Roles, skills, training | Who reviews agent approvals and escalations |
The AI Register and AI Inventory Template gives a register layout that satisfies A.4.2 in one place.
A.5 Assessing impacts of AI systems
- A.5.2 Impact assessment process: a defined process for assessing potential consequences for individuals, groups and society, with triggers for when it runs.
- A.5.3 Documenting assessments: keep results and retain them for a defined period.
- A.5.4 Impacts on individuals or groups: consider fairness, privacy, safety and accessibility for affected people.
- A.5.5 Societal impacts: consider wider effects such as environmental or economic consequences.
Clause 6.1.4 makes the impact assessment a requirement in its own right, and clause 8.4 requires performing it at planned intervals. ISO/IEC 42005:2025 (edition 1, May 2025) gives detailed guidance on identifying, evaluating and documenting impacts across the life cycle. See the ISO/IEC 42005 AI System Impact Assessment Guide and the AI Impact Assessment Template. For agents, include the impact of actions taken, not just outputs shown: a wrong payment or deleted record is a different harm from a wrong answer.
A.6 AI system life cycle
The largest area splits into management guidance (A.6.1) and life cycle stages (A.6.2).
| Control | Paraphrased intent | Evidence an auditor samples |
|---|---|---|
| A.6.1.2 | Set objectives for responsible development | Documented objectives feeding design requirements |
| A.6.1.3 | Define processes for responsible design and development | SDLC stages with AI-specific gates |
| A.6.2.2 | Specify requirements for new systems or major changes | Requirement specs including performance and safety limits |
| A.6.2.3 | Document design and development choices | Architecture, model selection and training decisions |
| A.6.2.4 | Verify and validate the system | Test plans, evaluation results, acceptance criteria |
| A.6.2.5 | Plan and approve deployment | Deployment plan and sign-off |
| A.6.2.6 | Operate and monitor | Monitoring dashboards, drift checks, incident tickets |
| A.6.2.7 | Provide technical documentation to relevant parties | Model cards, system documentation |
| A.6.2.8 | Record event logs | Log design, retention and samples |
Agent angle: A.6.2.4 validation should cover tool misuse and goal hijacking scenarios, and A.6.2.5 deployment approval should include the agent's permission set. A.6.2.8 logs are only useful if every action is attributable to a specific agent identity and the human or workflow that invoked it. See the AI Agent Audit Log Schema Template and the AI Agent Deployment Checklist.
A.7 Data for AI systems
- A.7.2 Data for development and enhancement: define and document data management processes for training and improving systems.
- A.7.3 Acquisition of data: record how data is obtained, including rights and terms.
- A.7.4 Quality of data: set quality requirements and check data against them.
- A.7.5 Data provenance: record the origin and history of data over its life cycle.
- A.7.6 Data preparation: define and document preparation methods such as cleaning, labelling and transformation.
For deployers who do not train models, A.7 still applies to retrieval corpora, fine-tuning sets and the data agents write back. Provenance records are also what lets you answer an incident question such as which documents fed a harmful action. The AI BOM vs Model Card vs Datasheet guide compares the artefacts that carry this information.
A.8 Information for interested parties and A.9 use of AI systems
| Control | Paraphrased intent | Typical evidence |
|---|---|---|
| A.8.2 | Give users the system documentation and information they need | User guidance, limitations, instructions |
| A.8.3 | Let external parties report adverse impacts | Public reporting channel and handling log |
| A.8.4 | Plan communication of incidents | Incident communication plan naming audiences |
| A.8.5 | Meet obligations to inform interested parties | Register of reporting obligations and records of reports |
| A.9.2 | Define processes for responsible use | Usage procedures and approvals |
| A.9.3 | Set objectives for responsible use | Documented objectives and measures |
| A.9.4 | Use the system as intended | Intended purpose statement and monitoring for out-of-scope use |
Agent angle: A.9.4 is the control that turns into technical guardrails for agents. An intended use statement means little unless the agent's scopes, tool allow-lists and approval thresholds enforce it. See the AI Agent Action Approvals and Spending Limits Guide and the AI Agent Authorisation Guide.
A.10 Third-party and customer relationships
- A.10.2 Allocating responsibilities: split responsibilities across the AI life cycle between you, partners, suppliers and customers.
- A.10.3 Suppliers: ensure supplied AI services, products and components fit your responsible AI approach.
- A.10.4 Customers: take customer expectations and needs into account in your responsible AI approach.
Model providers, agent platforms and MCP server publishers are all suppliers under A.10.3. A supplier's own 42001 certificate helps but does not cover your controls; cloud providers that publish certificates still expect customers to have their own controls assessed. See Contractual vs Technical Controls for Third-Party AI and the AI Vendor Security Questionnaire Template.
Implementing Annex A step by step
- Build the AI register first. Every control is applied per system; without an inventory the SoA cannot be justified.
- Assign roles (A.3.2) and decide your role per system. Developer, provider and user roles change which life cycle controls apply.
- Run risk and impact assessments (6.1.2, 6.1.4) on a pilot system. Pick one representative system, ideally an agent with real permissions.
- Draft the SoA against all 38 controls. Record inclusion, justification, implementation status and the evidence location.
- Close gaps in priority order. Policy and roles, then impact assessment, then logging and intended-use guardrails, then supplier terms.
- Operate for a cycle. Collect monitoring results, run an internal audit and a management review before certification.
- Roll out to remaining systems in waves. Reuse the pilot templates; revisit the SoA when a new system type appears.
If you already hold ISO/IEC 27001, reuse document control, internal audit and supplier processes and add the AI-specific evidence. See ISO 42001 vs ISO 27001.
Measuring control effectiveness
- Register coverage: percentage of AI systems and agents in the register with a named owner and documented resources.
- Impact assessment currency: systems with an assessment completed within the review interval.
- Log attribution rate: share of agent actions in logs traceable to a unique agent identity and invoking principal.
- Out-of-scope use detections: number of blocked or flagged actions outside the intended use, and time to review.
- Supplier coverage: AI suppliers with responsibilities allocated in contract and reviewed in the last year.
Framework mapping
NIST has published a crosswalk from the AI RMF to ISO/IEC 42001, written against the draft (FDIS) text and referencing the Annex B guidance items; treat it as conceptual alignment, not proof of conformity.
| 42001 area | NIST AI RMF (per crosswalk) | NIST CSF 2.0 |
|---|---|---|
| A.2 Policy | GOVERN 1.1 | GV.PO-01 |
| A.3.2 Roles | GOVERN 2.1 | GV.RR-02 |
| A.4 Resources | GOVERN 1.6 | ID.AM-01 |
| A.5 Impact assessment | MAP 1.1 | Not directly mapped |
| A.6.2.6 and A.6.2.8 Monitoring and logs | MEASURE 2.4 | PR.PS-04 |
| A.10 Third parties | GOVERN 6.1, MANAGE 3.1 | GV.SC-05 |
Common failure patterns
- SoA written for the platform, not the systems. One generic entry per control hides which agents actually meet it.
- Impact assessments that stop at outputs. Agentic actions, tool calls and downstream effects are left unassessed.
- Shared service accounts for agents. A.6.2.8 logs then cannot show which agent acted, and A.9.4 limits cannot be enforced per agent. See the AI Agent Credential Lifecycle and Rotation Guide.
- Relying on a supplier certificate. A model provider's certificate does not satisfy your A.10.2 allocation or your own deployment controls.
- Data controls only for training. Retrieval stores and agent memory are omitted from A.7 provenance and quality checks.
- Policy never reviewed after agents arrive. A.2.4 review triggers do not include a change in autonomy level.
Practitioner checklist
- Maintain an AI register covering every system and agent, with owner and resources (A.3.2, A.4).
- Record all 38 controls in the SoA with justification and evidence location.
- Run and retain impact assessments that include agent actions (A.5).
- Gate deployment on validation results and an approved permission set (A.6.2.4, A.6.2.5).
- Give each agent its own identity so logs are attributable (A.6.2.8).
- Document provenance for training, fine-tuning and retrieval data (A.7.5).
- Publish an external reporting channel and incident communication plan (A.8.3, A.8.4).
- Enforce intended use with scopes, tool allow-lists and approvals (A.9.4).
- Allocate responsibilities with every AI supplier and review annually (A.10.2, A.10.3).
Standards and references
- IEC Webstore: ISO/IEC 42001:2023 Artificial intelligence management system
- ISO: ISO/IEC 42005:2025 AI system impact assessment
- NIST: AI RMF to ISO/IEC 42001 Crosswalk
- IEC: ISO/IEC 42001 edition 1.0 preview
- NIST: Cybersecurity Framework 2.0
- Microsoft Learn: ISO/IEC 42001 compliance offering
- ISMS.online: ISO 42001 Annex A controls
Related NHI Mgmt Group resources: ISO/IEC 42001 Guide · ISO 42001 Readiness Checklist · ISO/IEC 42006 · EU AI Act vs ISO/IEC 42001