Controls reference · October 30, 2026
ISO 42001 Controls: The Annex A List, With Evidence
ISO/IEC 42001 has 38 Annex A controls under nine objectives, numbered A.2 to A.10. They are a reference set, not a to-do list. You pick the ones your AI risks need and record each choice, with a reason, in a Statement of Applicability. Below, every control is listed by number, in plain words, with the evidence that shows it working.
How Annex A is built
Four annexes, two of them normative
Nine objectives hold the 38 controls.
The main clauses, 4 to 10, set up the management system. Annex A supplies the controls. Numbering starts at A.2, because A.1 only introduces the annex. Each objective states an outcome, and the controls under it are the measures you show evidence for.
The top-ranked guides for this search disagree on one point. Some call Annex B informative, another calls it normative. The standard’s own contents page settles it: Annexes A and B are normative, C and D are informative.
Annex A · Normative
The controls
The 38 controls under nine objectives, A.2 to A.10. Starts on page 17. You check your control set against it.
Annex B · Normative
How to implement them
Implementation guidance for each control, numbered to match, B.2 to B.10. It runs from page 21 to page 45.
Annex C · Informative
Objectives and risk sources
Possible AI objectives and sources of risk, to feed your risk assessment.
Annex D · Informative
Use across sectors
How the management system applies across domains and sectors.
- A.2Policy3 controls
- A.3Roles and concerns2 controls
- A.4Resources5 controls
- A.5Impact assessment4 controls
- A.6Life cycle9 controls
- A.7Data5 controls
- A.8Information for others4 controls
- A.9Use3 controls
- A.10Suppliers and customers3 controls
Structure and page numbers from the contents page of ISO/IEC 42001:2023, shown in the free sample on the iTeh Standards catalogue. The standard is 51 pages, published December 2023, and sold by ISO for CHF 225. Control numbers cross-checked against two published lists (Mindset Cyber, ISMS.online) and the Annex B numbering in the crosswalk posted by NIST. All read October 30, 2026.
The 38 controls
ISO 42001 Annex A controls list
Every control, the evidence for it, and where to start.
The names and summaries are the Institute’s own plain words. ISO and IEC own the text of the standard, so buy a copy for the exact wording. The evidence column gives examples an auditor can read. Your certification body decides what it samples.
The last column shows whether one of the Institute’s free documents already records the control. Of the 38, 8 are covered, 23 are partly covered, and 7 have no Institute document yet.
A.2 Policy
One written AI policy that leadership stands behind, kept in step with your other policies. 3 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.2.2A written AI policy | Leadership approves a policy that sets how the organization builds, provides, or uses AI. | The signed policy, its approval date, and its named owner. | PartlyAI acceptable use policyCovers staff use of AI tools. A full AI policy also covers systems you build or sell. |
| A.2.3Fit with your other policies | Check the AI policy against security, privacy, HR, and buying rules, and fix any conflict. | A dated note of which policies the AI policy touches and what changed. | PartlyAI acceptable use policyIts information rules follow your existing data classification. |
| A.2.4Scheduled policy review | Review the policy on a set cycle, and again after a major change. | A review log with dates, what changed, and who approved it. | CoveredAI acceptable use policyIts ownership clause sets a yearly review and six triggers for an earlier one. |
A.3 Roles and concerns
Names against every AI decision, and a safe way to say something is wrong. 2 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.3.2Named owners for AI work | Assign who owns, approves, runs, and can stop each part of the AI life cycle. | A role register or charter that names each owner and their authority. | CoveredCommittee charter |
| A.3.3A safe route to raise concerns | Give staff and others a way to report a concern, with someone bound to respond. | The published reporting route and a record of reports and responses. | CoveredAI acceptable use policyIts reporting clause protects good-faith reports. The charter adds the escalation path. |
A.4 Resources
A record of everything each AI system depends on: data, tools, computing, and people. 5 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.4.2A resource record for each system | Keep an inventory of what each AI system relies on at each stage of its life. | An inventory entry per system, kept current. | CoveredGovernance checklist, inventory section |
| A.4.3The data each system uses | Record each dataset a system uses, what it is for, and how current it is. | A data map per system. | PartlyGovernance checklist, data section |
| A.4.4Tools and models it is built with | Record the models, frameworks, and tools the system depends on. | A tooling list with versions. | PartlyGovernance checklist, inventory sectionRecords the model or service and its version. |
| A.4.5Compute and hosting | Record where the system runs and the computing it needs. | A hosting and environment record. | PartlyGovernance checklist, inventory sectionRecords the operating environment. |
| A.4.6People and skills | Record who works on the system across its life, and the skills each role needs. | Role lists with competence and training records. | PartlyGovernance checklist, people and training section |
A.5 Impact assessment
A repeatable way to judge how a system could affect people and society, kept on file. 4 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.5.2When and how impacts are assessed | Set a process for assessing impacts, including what triggers a new assessment. | A written procedure with its triggers. | PartlyAI risk assessmentA risk method with reassessment triggers. ISO/IEC 42005 goes further on impact. |
| A.5.3Keeping each assessment on file | Keep the completed assessments, so they can be checked and revisited. | Dated, completed assessments for real systems. | PartlyAI risk assessment |
| A.5.4Effects on individuals and groups | Assess how the system could affect specific people or groups of people. | An affected-people section in each assessment. | PartlyAI risk assessmentIts data map step includes an affected-population note. |
| A.5.5Effects on society | Look past direct users to wider effects, such as on public services or the environment. | A society-level section where the system warrants one. | Not yetNo Institute document records this yet. |
A.6 Life cycle
How a system is specified, built, tested, released, run, documented, and logged. 9 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.6.1.2Responsible-development goals | Set goals such as fairness or safety thresholds that shape how systems are built. | Written goals linked to each project. | PartlyHuman-centered AI framework |
| A.6.1.3A written build process | Write down the steps your teams follow to design and build AI systems. | A development procedure with its approval points. | PartlyGovernance checklist, launch gate |
| A.6.2.2Requirements, written before building | Specify what the system must and must not do, and why it is needed. | A requirements document under change control. | PartlyGovernance checklist, purpose and scope section |
| A.6.2.3Design decisions, recorded | Record the main design and build choices and the reasons for them. | Design records traced back to the requirements. | Not yetNo Institute document records this yet. |
| A.6.2.4Testing against set thresholds | Decide how the system is checked and what results it must reach before release. | A test plan, its thresholds, the results, and a sign-off. | CoveredGovernance checklist, testing section |
| A.6.2.5Release plan | Plan and approve each release, with a way to roll it back. | A signed release decision and a rollback record. | CoveredGovernance checklist, launch gate |
| A.6.2.6Day-to-day running and monitoring | Watch performance, drift, and failures, and say who fixes what. | A monitoring plan, review logs, and incident records. | CoveredGovernance checklist, monitoring section |
| A.6.2.7Technical documentation for each audience | Give users, partners, and authorities the technical information each one needs. | A documentation set per audience. | PartlyGovernance checklist, inventory sectionAsks for a system card, not a full documentation set. |
| A.6.2.8What the system logs | Decide which events are logged, at which stages, and how long logs are kept. | A logging rule and the retained logs. | PartlyGovernance checklist, data sectionSets logging and record-keeping rules. |
A.7 Data
Where data comes from, whether it is good enough, and how it was prepared. 5 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.7.2Rules for development data | Set how data used to build and improve a system is managed. | A data management procedure for training and tuning data. | PartlyGovernance checklist, data section |
| A.7.3How data is acquired | Record where each dataset came from, how it was chosen, and your right to use it. | Source records, licences, and permissions. | PartlyGovernance checklist, data sectionAsks you to confirm permission and purpose. |
| A.7.4Data quality checks | Set quality rules for data and check that real data meets them. | Written quality criteria and test reports. | PartlyGovernance checklist, data sectionLists a quality report as evidence. |
| A.7.5Where each dataset came from | Keep a trail of each dataset's origin and every change made to it. | A lineage record per dataset. | Not yetNo Institute document records this yet. |
| A.7.6How data is prepared | Choose and record the cleaning, labelling, and other preparation methods used. | Preparation and labelling logs with reasons. | Not yetNo Institute document records this yet. |
A.8 Information for others
What users, affected people, and outside parties are told, and how they can tell you. 4 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.8.2Plain information for users | Tell users what the system does, its limits, and how to use it safely. | User notices, guides, and stated limits. | PartlyGovernance checklist, transparency section |
| A.8.3A route for outsiders to report problems | Let affected people and the public report harm or complaints about a system. | An external reporting channel and its case records. | PartlyGovernance checklist, transparency sectionAsks for a path to question, correct, appeal, or report. |
| A.8.4Telling people about incidents | Plan who tells whom, how fast, and how, when an AI incident happens. | An incident communication plan and copies of notices sent. | PartlyGovernance checklist, incident section |
| A.8.5What you share without being asked | Decide what other system information goes to regulators, partners, or the public. | A register of what is shared, with whom, and when. | Not yetNo Institute document records this yet. |
A.9 Use
Rules and goals for using AI systems, and keeping each one to its intended purpose. 3 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.9.2A process for responsible use | Write down how people use AI systems, including when to pause or stop. | Use rules, approvals, and training records. | CoveredAI acceptable use policy |
| A.9.3Goals that guide use | Set goals for how systems are used, such as where a person must review. | Written use goals that operators can check against. | PartlyHuman-centered AI framework |
| A.9.4Staying within intended use | Keep each system to the purpose it was built for, and reassess before stretching it. | An intended-use statement per system and checks on actual use. | PartlyGovernance checklist, purpose and scope section |
A.10 Suppliers and customers
Who answers for what across vendors, partners, and the customers you serve. 3 controls.
| Control | What it asks for | Evidence an auditor can read | Institute document |
|---|---|---|---|
| A.10.2Who is responsible for what | Split responsibilities clearly between you, suppliers, partners, and customers. | A responsibility split and the contract clauses that carry it. | Not yetNo Institute document records this yet. |
| A.10.3Supplier fit | Check that suppliers of models, data, and tools meet your responsible-AI rules. | Supplier reviews and contract terms. | PartlyAI acceptable use policyIts information rules require provider terms that bar training on your inputs. |
| A.10.4Customer obligations | Weigh what you owe customers before deciding how to build, provide, or use AI. | Customer commitments mapped to the systems they affect. | Not yetNo Institute document records this yet. |
Plain-language summaries by LA Global Institute, checked against the control-by-control descriptions published by Mindset Cyber and ISMS.online, read October 30, 2026. They are not the text of ISO/IEC 42001.
Statement of Applicability
How you choose controls
You do not implement Annex A. You choose from it.
The standard defines the Statement of Applicability as the record of every control you need, with the reason each one is in or out. Its notes say you may not need every Annex A control, and you may add controls of your own. Every risk you identify, and the control that treats it, must appear in it.
So the order matters. Assess risk and impact first. Then compare the controls those assessments call for against Annex A, so nothing relevant is missed.
What each line of a Statement of Applicability answers
- Does this control apply to the systems in scope?
- Why, in one sentence that points to a risk or impact finding?
- Is it in place today, partly in place, or planned?
- Where is the evidence, and who owns it?
Definition and notes: ISO/IEC 42001:2023, term 3.26, shown in the free sample pages, read October 30, 2026. Assess-then-compare order: clause 6.1.3 as summarized by Konfirmity. The four questions are the Institute’s summary, not a form to copy.
Gap analysis
ISO 42001 gap analysis, in six steps
Walk the 38 controls against what you can prove today.
A gap analysis compares your evidence with the controls you need. Done in this order, the scope stays fixed and the assessments decide which controls count.
- 01
Fix the scope
Name the AI systems in scope and your role for each: building, providing, or using AI.
Find your role with the framework router - 02
List every system
Put each system in one inventory with an owner. Controls apply system by system, so this comes first.
Inventory section of the checklist - 03
Assess risk and impact
Run the risk and impact assessments before judging controls. They decide which controls apply and how deep.
AI risk assessment method - 04
Walk all 38 controls
For each control, decide if it applies and why. Then find the evidence that exists today.
- 05
Grade the evidence
Mark each applicable control as evidenced, partial, or missing. Stale evidence counts as partial.
- 06
Turn gaps into owned work
Give every missing item an owner and a date. Re-run the walk before the Stage 1 audit.
What the audit stages cost
Build order
Start where later evidence depends on it
Six steps, from owners to suppliers.
Some controls only work once others exist. This order follows the nine decisions in the Institute’s AI governance framework, which crosswalks each decision to ISO/IEC 42001, the NIST AI RMF, and the EU AI Act.
- A.3.2
Owners and stop authority
Every other control needs someone accountable. Without an owner who can say no, the rest is advice.
Committee charter - A.4.2 to A.4.6
The inventory
Controls are applied to systems. An empty inventory means there is nothing to apply them to.
Governance checklist, inventory - A.2, A.9.2, A.3.3
Policy, use rules, and a reporting route
These are the controls staff meet first. They also give you evidence an auditor can read on day one.
AI acceptable use policy - A.5
The risk and impact method
The assessment tier decides how much of A.6 to A.8 each system needs.
AI risk assessment - A.6 and A.7
Life cycle and data
Heaviest for systems you build or fine-tune. Lighter for tools you buy, where A.10 carries more weight.
Governance checklist, launch gate - A.8 and A.10
Outside parties, suppliers, and customers
These depend on knowing your systems, your data, and your incidents, so they come last.
Decision 08 in the framework
Limits
Read the list, then read the standard
A controls list is not a certificate.
Knowing the 38 controls tells you what an auditor may ask about. It does not show that any control works. Certification is a separate step: a certification body audits your AI management system, under rules set by ISO/IEC 42006.
LA Global Institute does not certify organizations, systems, or people, and it is not a certification body. If you are budgeting for an audit, see what ISO/IEC 42001 certification costs, line by line.
Common questions
ISO 42001 controls FAQ
Answers to the questions people search for.
How many controls are in ISO 42001?
ISO/IEC 42001:2023 has 38 controls in Annex A. They sit under nine control objectives, numbered A.2 to A.10. The largest group is A.6, the AI system life cycle, with 9 controls. The smallest is A.3, internal organization, with 2.
Are all 38 ISO 42001 controls mandatory?
No. You choose the controls your AI risks call for, and you can add your own. The standard defines the Statement of Applicability as the record of all the controls you need, with the reason each one is included or excluded. Leaving a control out is allowed when the reason is written down.
What is the difference between Annex A and Annex B?
Annex A lists the controls. Annex B gives implementation guidance for each one, numbered to match. The standard's own contents page marks both Annex A and Annex B as normative, and Annexes C and D as informative. Some guides that rank for this search call Annex B informative, so check the contents page of your copy.
What is a Statement of Applicability in ISO 42001?
It is the document that lists every control you need and gives the reason each Annex A control is in or out. The standard also says every risk you identify, and the control that treats it, must show up in it. That makes it the link between your assessments and your evidence.
Which ISO 42001 controls cover data?
Objective A.7 holds five data controls, A.7.2 to A.7.6. They cover rules for development data, how data is acquired, data quality, where each dataset came from, and how data is prepared. A.4.3 also asks you to record the data each system uses.
How do ISO 42001 controls compare with ISO 27001 controls?
ISO/IEC 27001:2022 has 93 controls in four themes, and they protect information. ISO/IEC 42001 has 38 controls in nine objectives, and they govern how AI is built and used. Both use a Statement of Applicability. An existing ISO/IEC 27001 system helps with the shared management clauses, but not with AI-only controls such as impact assessment in A.5.
Is there an ISO 42001 controls checklist or template on this page?
There is a reference table, not a fill-in template. It lists all 38 controls with the evidence that shows each one working. Your own Statement of Applicability has to come from your own risk and impact assessments, so a copied one would not hold up.
How do I run an ISO 42001 gap analysis?
Fix the scope, list every AI system with an owner, and run your risk and impact assessments. Then walk all 38 controls. For each one, decide if it applies, find the evidence that exists, and mark it evidenced, partial, or missing. Give every gap an owner and a date.
Can I copy the control text from this page into my documents?
The control names and summaries here are the Institute's own plain-language labels, not the wording of the standard. ISO and IEC own the text of ISO/IEC 42001 and sell it. Buy a licensed copy for the exact wording an auditor will use.
Does LA Global Institute certify organizations to ISO 42001?
No. LA Global Institute does not certify organizations, systems, or people, and it is not a certification body. Certification comes from a certification body that audits your AI management system, under rules set by ISO/IEC 42006.
The ISO/IEC 27001 figure is as published by Konfirmity. The Annex labels come from the contents page of the standard. References do not imply affiliation with, or endorsement by, ISO, IEC, NIST, Microsoft, Konfirmity, Mindset Cyber, ISMS.online, iTeh, or any other organization.
Turn the controls into records