ISO 42001 Annex A Controls: All 38, Explained by Objective

ISO 42001 lists thirty-eight controls in its Annex A, grouped into nine areas of AI governance. The number catches people out, and the bigger surprise is what you are meant to do with it: you select the controls that fit your risks, you do not implement all thirty-eight. Annex A is a menu to choose from, and choosing well is the actual skill.

Under ISO/IEC 42001:2023, the AI management system standard, these controls are the AI-specific safeguards that make the management system about AI rather than about paperwork. They differ from the generic security controls of other standards: where ISO/IEC 27001 carries ninety-three information security controls, ISO 42001 carries thirty-eight controls aimed squarely at AI concerns such as bias, transparency, data quality, and human oversight.

This guide from the AI Governance Certification Institute (AIGCI) explains the thirty-eight controls by their nine objectives, shows who typically owns each area, and makes clear how the controls are selected rather than simply adopted. It pairs with the requirements in clauses 4 to 10, which are a different thing from the controls, a distinction worth getting right before anything else.

What Annex A Is, and How It Differs From the Clauses

The single most common mistake with ISO 42001 is treating the clauses and the Annex A controls as one list. They are two different layers, and the system only makes sense when you keep them apart.

The clauses are the management system requirements, the how of governing AI, and you are certified against them. Annex A is a reference set of specific controls, the what you might put in place to treat your risks. You do not pick and choose among the clauses; you do pick and choose among the controls, selecting and justifying each one through the Statement of Applicability. Put as a plain relationship: the clauses require you to manage AI risk, and the Annex A controls are among the means you use to do it.

The Nine Control Objectives of Annex A

Annex A organizes its thirty-eight controls under nine objectives, numbered A.2 through A.10. The table below gives each objective, what it covers, how many controls sit under it, and who usually owns that area. It is the fastest way to see the whole control set at once.

The distribution tells its own story. The largest objective by far is A.6, the AI system life cycle, with nine controls, because that is where an AI system is actually built and run, and therefore where most can go wrong. The counts above are how the thirty-eight controls are commonly grouped; the firm facts are the total of thirty-eight and the nine objective areas.

The Objectives That Carry the Most Weight: Impact, Life Cycle, and Data

Three of the nine objectives do the heaviest lifting in practice, and seeing a concrete control in each makes the whole annex less abstract.

A.5 Assessing Impacts of AI Systems

This objective is what makes ISO 42001 different from a security standard. It requires you to assess how an AI system affects people, groups, and society, not just the organization, covering concerns like bias, fairness, and effects on fundamental rights. A representative control is the requirement to conduct and document an AI system impact assessment, and frameworks such as the NIST AI Risk Management Framework help you reason through what to assess.

A.6 AI System Life Cycle

The largest objective governs the AI system from design to retirement. Its controls cover responsible development objectives, documented design decisions, verification and validation, deployment, and ongoing operation and monitoring. A representative control is the requirement to define and document the processes for the responsible development of AI systems, so that quality and oversight are built in rather than bolted on.

A.7 Data for AI Systems

Because an AI system is only as trustworthy as its data, this objective targets data specifically. Its controls address data quality, provenance, acquisition, and preparation for training, validation, and testing. A representative control is the requirement to define and document data management processes, including where the data came from and how it was prepared, which is exactly what an auditor probes when fairness or accuracy is in question.

How the Controls Are Selected: Risk, Treatment, and the SoA

Annex A only works through selection, and the selection is driven by risk, not preference. This is the relationship that ties the controls back to the rest of the standard.

The sequence runs like this. You assess your AI risks, you decide how to treat them, and the controls you choose to treat them are drawn from Annex A. Each control is then recorded as applicable or not, with a justification, in the Statement of Applicability. That means the controls you implement come directly out of the risk assessment that drives selection, which is why two organizations using the same standard end up with different control sets. Expressed as a relationship, Annex A treats your AI risks, and your risk assessment decides which parts of Annex A you need.

This is also why copying another company's control set fails. Their selection answers their risks. Yours has to answer yours, which is the whole point of making the choice deliberate rather than defaulting to all thirty-eight.

Annex A, B, C, and D: What Each Annex Does

Annex A is one of four annexes, and confusing them is common because they look related. Knowing what each does saves time when you go looking for guidance.

In practice you select from Annex A, turn to Annex B when you need to know how to implement a control, draw on Annex C to make sure you have not missed a risk source, and use Annex D when your sector raises specific considerations. Annex A is the what; Annex B is the how.

Owners and Evidence: What Makes a Control Real

A control in your Statement of Applicability is a claim, and an auditor tests whether the claim is true. Two things turn a listed control into a real one: an owner and evidence.

Every applicable control needs a named owner, the person accountable for it operating, which is why the table above pairs each objective with a typical owner. It also needs evidence that it actually runs: a dated record, a log, an assessment, an approval. A control with no owner goes stale, and a control with no evidence is indistinguishable, to an auditor, from one that does not exist. Selecting the right controls is the first half of the work under Annex A; owning them and evidencing them is the half that passes the audit.

Common Mistakes With Annex A Controls

A few recurring errors turn Annex A from a tool into a liability, and all of them come from misreading what the control set is for.

•     Implementing all thirty-eight. Treating the reference set as a mandatory checklist, which produces controls that answer no real risk and still have to be maintained.

•     Copying another organization’s selection. Their control set answers their risks and their AI systems, not yours.

•     Selecting controls that trace to nothing. A control that cannot be tied back to an assessed risk is hard to justify when an auditor reads your Statement of Applicability.

•     Listing a control with no owner or evidence. On paper it looks governed; in the audit it reads as absent.

•     Reaching for Annex A without Annex B. Selecting a control without the implementation guidance that explains how to actually run it.

Frequently Asked Questions

How Many Controls Are in ISO 42001 Annex A?

Thirty-eight, grouped under nine control objectives numbered A.2 through A.10. The largest objective is A.6, the AI system life cycle, which holds nine of the thirty-eight. The controls are AI-specific, covering areas such as policy, impact assessment, the AI life cycle, data, transparency, use, and third-party relationships.

Are All 38 Annex A Controls Mandatory?

No. Annex A is a reference set, not a mandatory checklist. You select the controls that treat your assessed AI risks and justify both the ones you include and the ones you exclude in your Statement of Applicability. Two organizations will usually end up with different control sets because their risks differ.

What Is the Difference Between Annex A and Annex B?

Annex A lists the controls themselves, the what. Annex B gives implementation guidance for those controls, the how. You choose controls from Annex A through your risk assessment, then use Annex B to understand how to put each chosen control into practice.

How Do You Choose Which Annex A Controls Apply?

Through risk. You assess your AI risks, decide how to treat them, and select the Annex A controls that address those risks. Each decision is recorded in the Statement of Applicability with a justification. The selection is driven by your specific AI systems and risks, not by a desire to implement as many controls as possible.

What Is the Difference Between the Clauses and the Annex A Controls?

The clauses, 4 to 10, are the management system requirements you are certified against. The Annex A controls are the specific safeguards you select to treat your risks. You cannot exclude a clause; you can and must choose among the controls. The clauses require you to manage AI risk; the controls are among the means of doing so.

Do the Annex A Controls Map to the EU AI Act?

Many of them align closely. Annex A controls for transparency, impact assessment, human oversight, and data governance cover much of the same ground the EU AI Act expects for higher-risk AI, so a well-selected control set gives you a strong head start on regulatory obligations. The mapping is not one to one, and the standard is voluntary while the regulation is law, but the overlap is a large part of why organizations pursue certification as part of their compliance work.

Is There a Downloadable List of the Annex A Controls?

The authoritative list of all thirty-eight controls, with their exact wording, lives in the published ISO/IEC 42001:2023 standard itself, which is the source to rely on for certification. The objective-by-objective table above summarizes the full set so you can see the structure and plan your selection before working from the standard.

From the Controls to a Certified System

Knowing the thirty-eight controls is the start; selecting, owning, and evidencing the right ones is what earns a certificate. That judgment is built through practice and training. You can see every route through the ISO 42001 courses, with the implementer path taught clause by clause and control by control in the Lead Implementer certification, so Annex A becomes a set of choices you can defend rather than a list you try to complete.