You consider 38, you do not implement 38
Annex A of ISO 42001 contains 38 controls across nine areas. As with ISO 27001, the requirement is to consider all of them and justify which apply — not to implement every one.
Applicability is driven by your role. An organization that builds models carries the full weight of the life cycle and data areas. An organization that consumes a vendor API carries far less of those and more of the use and third-party areas. Both are legitimate positions and both need writing down.
A.2 — Policies related to AI
An AI policy, approved by management, aligned with your other policies, and reviewed at planned intervals. Straightforward if you already run a management system; the content is what matters, not the format.
A.3 — Internal organization
AI roles and responsibilities allocated and understood, and a route for reporting concerns about AI systems. The reporting route is frequently missing — organizations have a security incident channel and no way for someone to say a model output looked wrong.
A.4 — Resources for AI systems
Documenting the resources AI depends on: data, tooling and compute, human resources, and the systems themselves. In practice this is an inventory, and it is the control that most often reveals AI nobody had catalogued.
A.5 — Assessing impacts of AI systems
The defining area of the standard. Assessing the consequences of AI systems for individuals, groups and society, documenting those assessments, and revisiting them when systems change.
It is not a security risk assessment with AI words substituted. The question is what the system does to the people subject to it, which requires thinking about fairness, contestability and oversight rather than confidentiality and availability.
A.6 — AI system life cycle
The largest area for organizations that build. Objectives for responsible development, design and development processes, verification and validation, deployment, operation and monitoring, and technical documentation.
If you consume third-party AI, much of this is partly inherited — but not entirely. You still own intended purpose, monitoring in your context, and the decision to deploy.
A.7 — Data for AI systems
Data acquisition, quality, provenance and preparation. The hardest area to retrofit. Organizations that never tracked where training data came from cannot reconstruct provenance under audit pressure, and there is no quick remedy.
Start this early if you build models. If you consume vendor models, the obligation shifts to what you send them and under what basis.
A.8 — Information for interested parties
Transparency: system documentation for users, explanation of how AI is used, incident reporting, and information about the intended purpose and limitations. This is the area most directly aligned with what regulators ask for.
A.9 — Use of AI systems
Responsible use processes, ensuring systems are used for their intended purpose, and monitoring in operation. Applies whether you built the system or bought it, which makes it the area consumers of AI cannot exclude.
A.10 — Third-party and customer relationships
Allocating responsibility along the AI supply chain, supplier requirements, and obligations to customers. For most SaaS companies this is where the model vendor relationship gets documented — who is responsible for what when the model misbehaves.
Applicability by role
| Area | You build models | You consume vendor AI |
|---|---|---|
| A.2 Policies | Applies | Applies |
| A.3 Internal organization | Applies | Applies |
| A.4 Resources | Applies fully | Applies, lighter |
| A.5 Impact assessment | Applies fully | Applies fully — you deployed it |
| A.6 Life cycle | Applies fully | Partly inherited |
| A.7 Data | Applies fully | Shifts to what you send |
| A.8 Transparency | Applies | Applies |
| A.9 Use | Applies | Applies fully |
| A.10 Third parties | Applies | Applies fully |
Note what does not vary: A.5. Whoever deployed the system owns the impact assessment, regardless of who trained the model.
FAQs
How many controls are in ISO 42001 Annex A?
38 controls across nine areas: policies related to AI, internal organization, resources for AI systems, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships.
Do I have to implement all 38 ISO 42001 controls?
No. As with ISO 27001, you consider all 38 and justify which apply in your Statement of Applicability. Applicability depends heavily on whether you develop AI systems or only use them, and both positions are legitimate as long as the reasoning is documented.
Which ISO 42001 controls apply if I only use third-party AI?
All nine areas apply to some degree, but the weighting shifts. Life cycle and data obligations are lighter because the vendor performs much of that work, while use of AI systems and third-party relationships apply fully. Crucially, the impact assessment applies in full regardless — whoever deployed the system owns it.
What is the hardest ISO 42001 control area?
A.7, data for AI systems, for organizations that build models. Provenance of training data cannot be reconstructed retroactively, so companies that never tracked data origin face genuine work rather than documentation. A.5 impact assessment is the most conceptually unfamiliar, but it is tractable.
How is ISO 42001 Annex A different from ISO 27001 Annex A?
ISO 27001 has 93 controls concerned with protecting information. ISO 42001 has 38 concerned with governing AI — including the AI system life cycle, data provenance for training, and assessment of impact on people, none of which have ISO 27001 equivalents.
Where to go next
See the ISO 42001 checklist, certification services, or how these map onto an existing ISO 27001 system.