When compliance leaders first open ISO/IEC 42001:2023, the clauses describe what an AI Management System must achieve — but the practical question every team asks is: what do we actually have to build? The answer lives in Annex A, a catalogue of 38 controls organized under nine objectives. This post walks through those control objectives, explains the intent behind each, and shows the concrete artifacts your AI governance program will need to demonstrate them.
How Annex A Fits Into the Standard
ISO/IEC 42001 uses the Annex SL High-Level Structure, with management-system requirements in Clauses 4–10. Clause 6 requires you to assess AI risks and impacts and then select controls to treat them. Annex A is the reference set of controls you draw from, and your choices are documented in a Statement of Applicability (SoA) that records which controls apply, why, and their implementation status.
Two companion annexes support Annex A:
- Annex B provides detailed implementation guidance for each control — think of it as the “how-to” companion.
- Annex C catalogues AI-related risk sources, useful during risk identification.
- Annex D offers sector-specific guidance.
Annex A controls are not implemented blindly. They are selected based on your risk and impact assessments. A small organization using a single vendor chatbot will justify a very different control set than a bank deploying its own credit-scoring models.
The Nine Control Objectives at a Glance
The 38 controls span objectives A.2 through A.10. The table below summarizes each objective and what it covers.
| Objective | Theme | What it addresses |
|---|---|---|
| A.2 | AI policy | Establishing, approving, and maintaining an organizational AI policy |
| A.3 | Internal organization | Roles, responsibilities, and reporting lines for AI governance |
| A.4 | Resources for AI systems | Data, tooling, human, and computing resources |
| A.5 | Assessing impacts of AI systems | Processes for AI system impact assessment |
| A.6 | AI system life cycle | Responsible design and development across the life cycle |
| A.7 | Data for AI systems | Data quality, provenance, and governance |
| A.8 | Information for interested parties | Transparency, documentation, disclosure |
| A.9 | Use of AI systems | Responsible use and human oversight |
| A.10 | Third-party & customer relationships | Managing suppliers, vendors, and customers |
Let’s examine each in depth.
Everything starts with a documented, top-management-approved AI policy that sets out the organization’s principles and commitments for developing and using AI responsibly. The policy should align with the organization’s broader objectives and other policies (security, privacy, ethics), be communicated across the organization, and be reviewed at planned intervals.
An approved AI policy document, records of communication, and a review schedule with revision history.
AI governance fails without clear accountability. This objective establishes roles and responsibilities — who owns the AIMS, who sits on the AI governance committee, who signs off on high-risk deployments, and how AI concerns are escalated. It also addresses reporting of concerns, giving staff a channel to raise issues about AI systems.
A RACI matrix or roles-and-responsibilities register, AI governance committee charter and meeting minutes, and a defined escalation/reporting process.
AI systems consume specific resources, and mismanaging any of them creates risk. This objective requires you to identify and document the resources needed across four categories:
- Data — datasets used for training, testing, and operation.
- Tooling — development environments, ML platforms, monitoring tools.
- Human resources — competencies and skills required to build and oversee AI.
- Computing and system resources — infrastructure and compute.
Documenting these resources supports both risk management and reproducibility — an auditor may ask you to show which data and tools produced a given model.
Resource inventories, documented compute and data dependencies, and competency records.
This objective operationalizes the impact-assessment requirement from Clause 6. It requires a defined process for assessing the potential consequences of AI systems on individuals, groups, and society, including harms to health, safety, and fundamental rights. Impact assessments should be performed at appropriate points in the life cycle and repeated when systems change materially.
An impact-assessment procedure and completed AI system impact assessments for each material system.
Perhaps the most substantial objective, A.6 covers responsible design and development across the entire AI life cycle. It addresses objectives for responsible development, life-cycle processes, requirements definition, design and development documentation, verification and validation, deployment, and operation and monitoring. In practice this means embedding governance into how models are conceived, built, tested, released, and maintained — not bolting it on afterward.
Documented development life-cycle procedures, design specifications, model cards, test and validation reports, deployment approvals, and post-deployment monitoring records.
Because AI behavior flows from data, this objective demands rigorous data governance. It covers data quality, provenance (where data came from and how it may be used), data preparation, and the acquisition of data for AI systems. Weak data governance is one of the most common sources of AI harm — biased or unrepresentative training data produces biased outputs.
Data provenance records, data-quality criteria and validation results, data-preparation documentation, and dataset documentation (sometimes called datasheets).
Transparency is a defining principle of trustworthy AI. This objective requires you to provide relevant information to interested parties — users, affected individuals, regulators — about the AI systems you operate. This includes documentation about the system’s intended purpose, capabilities and limitations, and how to report problems or seek redress.
User-facing documentation, transparency notices, system disclosures, and channels for reporting issues.
Building an AI system responsibly is not enough; it must also be used responsibly. This objective covers responsible use, defining intended and prohibited uses, and — critically — human oversight. Systems that make or inform consequential decisions need meaningful human review, and staff must understand the system’s limitations to avoid over-reliance (automation bias).
Acceptable-use policies for AI, human-oversight procedures, oversight logs, and records showing intended-use boundaries are enforced.
Few organizations build AI entirely in-house. This objective governs relationships with suppliers, vendors, and customers — including foundation-model providers and downstream customers who use your AI. It requires allocating responsibilities across the value chain and ensuring third-party controls are adequate.
Supplier assessments, contractual clauses allocating AI responsibilities, third-party risk registers, and customer-facing responsibility documentation.
Selecting Controls: From Risk to Statement of Applicability
Controls are not chosen in isolation. The flow is:
To understand what could go wrong.
Choose the controls that treat those risks — supplemented by custom controls where Annex A does not fully cover a risk.
Record it in the Statement of Applicability, marking it applicable or excluded with reasoning.
Put each applicable control into practice and keep proof that it operates.
The SoA is a cornerstone audit artifact. Auditors compare your risk assessment, your SoA, and your actual implementation to confirm they tell a consistent story. An excluded control that clearly should apply given your risk profile is a red flag.
Common Pitfalls in Control Implementation
- Treating Annex A as a tick-box exercise. Controls must trace back to real risks and be genuinely operational, not paper policies.
- Neglecting the human-oversight and transparency controls. These (A.8, A.9) are where AI governance most visibly differs from security compliance, and where regulators focus.
- Weak data governance (A.7). Provenance and quality gaps undermine everything downstream and are hard to remediate late.
- Ignoring the value chain (A.10). Relying on vendors without assessing their controls transfers risk without managing it.
- No living evidence. Model cards, impact assessments, and oversight logs must be maintained, not created once for the audit.
Regulatory Context: Why These Controls Matter Now
The control set maps closely onto emerging legal obligations. The EU AI Act requires high-risk systems to have risk management, data governance, technical documentation, transparency, human oversight, and post-market monitoring — each of which corresponds to Annex A objectives (A.5–A.9 especially). Organizations that implement Annex A controls build reusable evidence for AI Act conformity. The controls also align conceptually with the NIST AI Risk Management Framework and complementary standards such as ISO/IEC 23894 and ISO/IEC 24028.
EU AI Act penalties reach €35 million or 7% of global turnover. High-risk obligations were originally due 2 August 2026; the November 2025 Digital Omnibus proposes deferring them toward December 2027 — but the direction of travel is unchanged, and controls mapped to A.5–A.9 remain the most reusable path to conformity.
Key Takeaways
- Annex A contains 38 controls across nine objectives (A.2–A.10) — the practical backbone of an AIMS.
- Controls span policy, roles, resources, impact assessment, life cycle, data, transparency, use/oversight, and third parties.
- Control selection is risk-driven and documented in the Statement of Applicability.
- Human oversight (A.9) and transparency (A.8) are where AI governance most distinguishes itself from traditional compliance.
- Every control needs living evidence: policies, model cards, impact assessments, data provenance records, and oversight logs.
- The control set aligns with EU AI Act obligations and NIST AI RMF, making implementation reusable across regimes.
Frequently Asked Questions
No. You implement the controls relevant to your assessed risks and impacts. Excluded controls must be justified in the Statement of Applicability with a defensible rationale.
Clauses 4–10 define the management-system requirements — the mandatory “shall” statements. Annex A is a reference catalogue of controls you draw on to treat risks. The clauses tell you what the system must do; Annex A helps you do it.
Consistency between your risk assessment, your SoA, and your operational reality — plus concrete artifacts like the AI policy, model cards, impact assessments, data provenance records, and human-oversight logs.
Many controls directly support AI Act high-risk requirements (risk management, data governance, documentation, transparency, human oversight, monitoring), so implementing them produces evidence useful for demonstrating conformity.
This article provides general information about ISO/IEC 42001 and does not constitute legal advice.