ISO 42001 controls: what the Annex A controls are for

How the controls work before you read them

Two facts change how you read the list. First, ISO/IEC 42001:2023 splits into a mandatory management system (clauses 4 to 10) and a selectable set of controls (Annex A). The clauses you must meet to certify. The controls you choose from. Second, you make that choice through risk treatment: you assess your AI risk, decide which controls answer it, and record every inclusion and exclusion, with reasons, in a Statement of Applicability. So a control you leave out is not a failure if you can defend leaving it out. Treat each of the 38 as a decision you need to be able to justify, not a box you are obligated to fill.

The 38 controls sit in 9 domains. Here is what each domain is for at a glance, then the detail underneath.

That is 38 controls in total. You will occasionally see "39" in vendor content, usually from counting a domain heading or a draft; the enumeration here matches the published ISO/IEC 42001:2023 structure.

A.2 Policies related to AI (3 controls)

This domain exists so that responsible AI is a documented commitment, not a hallway understanding. It asks for an AI policy approved at the top, kept consistent with your security, privacy, and HR policies, and reviewed on a schedule and after any major change or incident. The point an auditor is testing is whether someone senior actually owns the position and whether the policy is alive, meaning reviewed and current, rather than written once and forgotten.

A.3 Internal organization (2 controls)

Diffuse ownership is how AI risk goes unmanaged, so this domain forces roles and responsibilities to be defined, allocated, and known to the people holding them. It also asks for a working channel to raise concerns about AI, internally and from outside. What it is really for is answering one question an auditor and a board both ask: when an AI system does something wrong, whose job was it to catch it?

A.4 Resources for AI systems (5 controls)

You cannot govern what you have not inventoried. This domain requires documentation of the resources every AI system depends on: the data it uses, the tooling and frameworks it runs on, the compute and infrastructure behind it, and the people who build, run, and oversee it, with their competencies. It is the foundation the rest of the standard builds on, because impact and risk both trace back to these components.

A.5 Assessing impacts of AI systems (4 controls)

This is one of the domains that make ISO 42001 an AI standard rather than a security one. It requires a defined, repeatable process for assessing how an AI system affects individuals, groups, and society, documented per system: intended use, foreseeable misuse, the impacts, and the mitigations. Ordinary risk work asks what could hurt the company; this asks what could hurt the people the system touches, which is where fairness, safety, and rights sit.

A.6 AI system life cycle (9 controls)

The largest domain, with nine controls, because it covers the whole engineering lifecycle. It sets objectives and processes for responsible development, then walks through requirements, design documentation, verification and validation, a controlled deployment with sign-off, operation and monitoring in production, current technical documentation, and event logging. Its purpose is to make governance something that happens inside the build process, not a review bolted on at the end. For teams that ship AI, this is usually the hardest domain to evidence, because it demands that governance checkpoints exist in the actual SDLC.

A.7 Data for AI systems (5 controls)

A model is largely a product of its data, so this domain governs that data across the lifecycle: the data used to develop and improve systems, how it is acquired and selected, quality requirements, provenance so you can trace where it came from, and preparation methods like cleaning and labeling. What it is for is preventing the failure mode where nobody can say what a system learned from, which is where bias and silent errors enter and where an auditor will probe hardest.

A.8 Information for interested parties (4 controls)

Transparency, made concrete. This domain requires that users can learn a system’s purpose, limits, and instructions; that there is a route for outsiders to report adverse impacts; that you have a plan for communicating incidents; and that obligations to regulators and customers are identified and met. It is the outward-facing half of governance: the controls that stop an AI system from being a black box to the people who rely on it or are affected by it.

A.9 Use of AI systems (3 controls)

A well-built system can still be misused, so this domain sets documented processes and objectives for responsible use and requires systems to be used for their intended purpose, with misuse watched for. It matters most for organizations that deploy AI they did not build, which is most companies. Governing use is how you keep a vendor tool inside the lines it was approved for, and it is the counterpart to the human-oversight expectations that run through the standard.

A.10 Third-party and customer relationships (3 controls)

Almost no AI system is built entirely in-house, so this domain governs the seams. It requires responsibilities to be allocated clearly across you, your suppliers, and your customers; suppliers to be vetted against your requirements and held to them in contracts; and customer expectations and responsible-use needs to be addressed. Its purpose is to stop accountability from falling into the gap between organizations, which is exactly where it tends to disappear.

Where these controls differ from ISO 27001

If you already hold ISO 27001, the reflex is to assume the controls overlap. Some governance and risk plumbing does carry over, and that is a real head start. But the domains that give ISO 42001 its reason to exist are the ones ISO 27001 never had: A.5 (impact on individuals and society), A.6 (the responsible-development lifecycle), and A.7 (data provenance and quality for training). Security controls protect data from outsiders; these controls ask whether the system is fair, whether anyone checked its effect on the people it touches, and whether you can say what it learned from. That is new work, and it is where most of the effort in a first certification actually goes.

What to do with this

Reading the domains is the easy part; deciding which controls your systems need, and evidencing them, is the work. The practical next steps are to run the ISO 42001 checklist to see where you stand control by control, and to read our ISO 42001 certification guide for how the controls fit into the audit path. If you would rather have the gap found and the Statement of Applicability drafted for you, with a stated price, that is our ISO 42001 readiness assessment. For how these controls line up against the NIST AI RMF and the EU AI Act, the framework crosswalk maps them row by row.

This page is general information, not legal or audit advice; the standard text and your accredited auditor govern the actual requirements, and it is current as of July 2026.