ISO 42001 controls: all 38 in Annex A
Annex A of ISO/IEC 42001:2023 lists 38 controls under nine headings. You decide about every one of them in writing, the same way ISO 27001 makes you decide about its 93, and the decisions go in a Statement of Applicability that the auditor reads before anything else.
ISO/IEC 42001:2023 carries 38 reference controls in Annex A, grouped under nine headings numbered A.2 through A.10. The largest group by a wide margin is the AI system life cycle at nine controls. The smallest is internal organization at two. Below is every group, the count, what each control is reaching for, and the evidence a stage 2 auditor will ask you to produce against it.
Two structural facts decide how you read the annex. First, Annex A is a reference set rather than a mandatory list: clause 6.1.3 tells you to determine the controls necessary to treat your AI risks and then compare that set against Annex A so you can see what you missed. Second, the annex is only half the document you need. Annex B carries several pages of implementation guidance per control, Annex C lists potential AI-related organizational objectives and risk sources, and Annex D covers using an AI management system across domains and sectors. Reading Annex A alone and guessing at what an auditor wants is the same false economy as buying ISO 27001 without ISO 27002.
How many controls does ISO 42001 have?
38 Annex A reference controls
9 Headings, A.2 through A.10
9 Controls in the largest group, A.6 life cycle
| Heading | Controls | What it is reaching for |
|---|---|---|
| A.2 Policies related to AI | 3 | An AI policy, its alignment with the policies you already have, and a review cycle for it. |
| A.3 Internal organization | 2 | Named AI roles and responsibilities, and a route for staff to raise concerns about an AI system. |
| A.4 Resources for AI systems | 5 | Documented data, tooling, compute and human resources for each system in scope. |
| A.5 Assessing impacts of AI systems | 4 | A process for impact assessment, its documentation, and separate assessment of impact on individuals and on society. |
| A.6 AI system life cycle | 9 | Responsible development objectives and processes, requirements, design documentation, verification, deployment, operation and monitoring, technical documentation, event logging. |
| A.7 Data for AI systems | 5 | Data used for development, how it was acquired, its quality, its provenance, and how it was prepared. |
| A.8 Information for interested parties | 4 | System documentation for users, external reporting, incident communication, and what other interested parties are told. |
| A.9 Use of AI systems | 3 | Processes and objectives for responsible use, and a defined intended use for each system. |
| A.10 Third-party and customer relationships | 3 | Allocation of responsibility across the value chain, supplier controls, and customer obligations. |
| Total | 38 | Plus Annex B guidance, Annex C risk sources and Annex D sector guidance. |
The words the annex uses, and what they mean
- Control
- One of the 38 reference items in Annex A. You record a decision on each. The clauses of the standard, 4 through 10, are requirements and are not controls, exactly as in ISO 27001.
- Role
- Your position in the AI value chain for a given system. ISO/IEC 22989 names them, and the ones that matter commercially are AI provider, AI producer, AI customer and AI partner. Your role changes which controls are relevant, and it changes per system rather than per company.
- AI system impact assessment
- The assessment of consequences for individuals, groups and society required by clause 6.1.4 and operated under clause 8.4. Four Annex A controls sit under it. Covered in full on the AI impact assessment page.
- Statement of Applicability
- The clause 6.1.3 record of which Annex A controls you determined necessary, why, whether they are implemented, and the justification for any exclusion. Same mechanism and same four columns as the ISO 27001 version.
- Annex C risk source
- One of the AI-specific risk sources listed in the informative Annex C, such as level of automation, lack of transparency, or complexity of the environment. Not requirements. They exist so your risk assessment is not limited to the risks you happened to think of.
A.2 and A.3, policy and accountability
What the five controls ask for
A.2 wants an AI policy that management has approved, that does not contradict your existing privacy, security and procurement policies, and that gets reviewed on a stated cycle. A.3 wants two things: written AI roles and responsibilities, and a mechanism for someone inside the organization to report a concern about an AI system without going through the person who built it.
What evidence closes them
An approved policy document with a version history and an owner. Minutes or a signature block showing management approved it. A role description or a RACI that names a person rather than a committee. For the concerns control, an actual route: a mailbox, a form, a line in the whistleblowing procedure, plus evidence that somebody would see it. Auditors test the concerns control by asking a random engineer what they would do if they thought a model was behaving badly. If the answer is a shrug, the control is not implemented no matter what the policy says.
Where it goes wrong
The commonest failure is an AI policy written by a consultant that contradicts the acceptable use policy HR published a year earlier, usually about whether staff may put customer data into a commercial assistant. A.2.3 exists specifically to catch that, and an auditor who finds two live documents saying opposite things will raise it.
A.4, resources, which is an inventory in disguise
Five controls covering documentation of the resources behind each AI system, then data, tooling, system and computing resources, and human resources individually. Read plainly it looks like an asset register requirement, and it is, but the reason it is here is that you cannot assess the risk of a system whose inputs you cannot enumerate.
The evidence is a per-system record showing which datasets feed it, which model or API sits underneath, which frameworks and libraries are in the pipeline, where it runs and on whose compute, and who is competent to operate it. The part that trips organizations up is human resources: the control asks you to show that the people running the system have the competence to do so, which for a fine-tuned model means somebody who understands what happens when the evaluation set stops representing production traffic.
The inventory is the gating item, not the audit
Almost every ISO 42001 project that runs long runs long here. The inventory turns up AI systems nobody counted: a support macro built on a model API, a lead-scoring feature in the CRM, a summarizer somebody shipped in a sprint. Each one has to be classified by role, assessed, and either brought into scope or explicitly left out with a reason. Do this before you ask anyone for a quote, because it is the input to the scope and the scope is the input to the price. The readiness check asks the same questions a certification body asks at scoping.
A.5, assessing impacts, which has no ISO 27001 counterpart
Four controls: a documented process for AI system impact assessment, the documentation of the assessments themselves, assessment of impact on individuals or groups of individuals, and assessment of societal impacts. This is the group that makes ISO 42001 a different standard rather than ISO 27001 with AI in the title.
ISO 27001 asks what could happen to your information. A.5 asks what your system could do to the people it is pointed at, including people who are not your customers and never agreed to anything. A hiring screen affects candidates. A pricing model affects the people being priced. A content filter affects the people whose content is removed. None of those are your organization, and none of them appear in an information security risk register.
What satisfies it is an assessment per AI system, or per coherent group of systems, that names the affected populations, describes the plausible harms with something more specific than the word bias, records what you did about each, and is dated and owned. ISO/IEC 42005 is the dedicated guidance standard for how to run one, and it is worth the purchase price if this group is new to you.
A.6, the life cycle, nine controls and the biggest evidence load
The two subgroups
A.6 splits into objectives and processes for responsible development, then the life cycle itself: requirements and specification, documentation of design and development, verification and validation, deployment, operation and monitoring, technical documentation, and recording of event logs.
What an auditor samples
They pick one AI system and walk it end to end. Show me the requirements you wrote before you built this. Show me the design decisions and why you chose this approach. Show me how you validated it before release and against what threshold. Show me the release approval. Show me what you monitor in production and what number would make you roll it back. Show me the logs for the last incident.
Most of this exists already in an engineering organization, in tickets, pull requests, evaluation notebooks and dashboards. The work is not creating it, it is making it findable and showing the thread runs unbroken from a requirement to a monitored production system. Teams that have been through an ISO 27001 implementation recognise this immediately, because it is the same change management argument applied to models instead of code.
The control that surprises people
Recording of event logs. Not application logs generally, but a record of what the AI system did that is sufficient to reconstruct a decision after the fact. If a customer disputes an automated outcome six months later and you cannot say which model version, which inputs and which threshold produced it, the control is not met. This is also the control that quietly protects you under Quebec's Law 25, which gives an individual the right to be informed about a decision based exclusively on automated processing and to make representations about it. You cannot answer that request without the log.
A.7, data, five controls and the ugliest paperwork
Data for development and enhancement, acquisition of data, quality of data, data provenance, and data preparation. This group asks four questions per dataset that most teams have never written answers to: where did it come from, what are we permitted to do with it, how good is it, and what did we do to it before training.
| Control area | The question underneath | Evidence that works |
|---|---|---|
| Data for development and enhancement | Which datasets train, tune and evaluate this system | A dataset register keyed to the AI system inventory, with versions |
| Acquisition of data | Are we allowed to use it for this | Licence terms, contract clauses, consent basis, scraping policy, a legal sign-off that names the purpose |
| Quality of data | How do we know it is good enough | Defined quality criteria, completeness and representativeness checks, a record of what failed and what you did |
| Data provenance | Where did each record originate and what happened to it since | Lineage documentation, source system to feature store to training set, retained for the life of the model |
| Data preparation | What transformations were applied and by whom | Versioned preparation code, documented labelling instructions, inter-annotator agreement if humans labelled it |
The acquisition control is where the Canadian angle bites hardest. If personal information is in the training data, the purpose it was collected for has to cover training a model, and under PIPEDA or the provincial statute that displaces it, a purpose invented after collection is not a purpose the individual consented to. Auditors are not privacy regulators and will not rule on that, but they will ask for the legal basis and write up its absence as a gap against the control.
A.8, A.9 and A.10, what you tell people and who is responsible
A.8, information for interested parties
Four controls: system documentation and information for users, external reporting, communication of incidents, and information for interested parties generally. In practice this is your model card or system description, the channel by which someone outside can report a problem with an AI output, and the process for telling affected parties when something went wrong. The external reporting control is the one most companies have no answer for, because there is no route from the public into the team that owns the model.
A.9, use of AI systems
Three controls: processes for responsible use, objectives for responsible use, and intended use. Intended use is doing more work than it looks. Writing down what a system is for creates the boundary that makes off-label use detectable, and off-label use is how a support classifier ends up making eligibility decisions without anyone assessing it. If you are a deployer rather than a developer, A.9 is the group your certificate will mostly rest on.
A.10, third parties and customers
Three controls: allocating responsibilities across the value chain, suppliers, and customers. The allocation control is the useful one. For every AI system you are somewhere in a chain, and the control asks you to write down which obligations are yours, which are your model provider's, and which land on your customer. Companies building on a commercial model API discover here that their supplier's terms give them almost nothing on data provenance or evaluation, and that gap has to be documented as a risk rather than assumed away. This is the same supplier problem ISO 27001 has, with less mature contracts on the other side.
Which controls can you defensibly exclude?
Exclusion is legitimate and it works the same way as in ISO 27001: the justification has to follow from your role and your risk assessment rather than from the budget. The role is what does most of the work, because a deployer genuinely does not develop.
| Controls | Reason usually given | Does it hold |
|---|---|---|
| Parts of A.6, development objectives, design documentation, verification and validation | We deploy a vendor's model and build nothing | Partly. Deployment, operation and monitoring, technical documentation and event logs still apply. Prompt systems, retrieval pipelines and agent scaffolding are development in an auditor's reading. |
| A.7 data controls | We never train or tune, so we hold no training data | Sometimes. Retrieval corpora, few-shot examples and evaluation sets are data for the AI system. If you genuinely pass prompts through and store nothing, the exclusion is clean and you should say exactly that. |
| Societal impact assessment | Our system is internal and low stakes | Weak as an exclusion, easy as a short assessment. A one-page assessment concluding the societal impact is negligible, with reasons, reads far better than an exclusion. |
| A.10 customers | We have no downstream customers using the AI | Yes for a purely internal system, and it is one of the cleaner exclusions available. |
| External reporting in A.8 | Nobody outside interacts with the system | Only if that is true. A customer-facing feature has people outside interacting with it whether or not they know a model is involved. |
The exclusion that will not survive contact with a buyer
Excluding the impact assessment group is technically arguable for some scopes and commercially self-defeating in all of them. Impact assessment is the part of ISO 42001 that a customer asking about AI governance is actually asking about. A certificate whose Statement of Applicability excludes it answers a question nobody asked.
Where should you start with the annex?
Not at A.2 and not by grading yourself against all 38. Start with the AI system inventory and your role for each system, because the role decides which groups are live for you and the inventory decides how big the evidence job is. Then run one impact assessment properly on the system your customers ask about most, because it is the deliverable that teaches the organization what the standard is actually for. Only then walk the annex as the completeness check clause 6.1.3 asks for.
If you are still deciding whether to certify at all, the honest test is on who needs ISO 42001 and who should wait, and the answer is no for more companies than the vendor material admits. If the decision is made, the certification process, cost and timeline covers what a Canadian body will charge and how to check its accreditation actually extends to this standard. And if the driver is a European customer, read what the EU AI Act asks of a Canadian supplier first, because the certificate does not answer it.
Get quotes for ISO 42001 readiness
Tell us what your AI systems do and which role you play for each, and we will match you with Canadian firms that do this work.
Get matchedCommon questions
How many controls are in ISO 42001 Annex A?
38 controls, grouped under nine headings numbered A.2 through A.10. The largest group is the AI system life cycle with 9 controls, and the smallest is internal organization with 2. The numbering starts at A.2 because A.1 is the general clause introducing the annex.
Do we have to implement all 38 ISO 42001 controls?
No. You have to consider all 38 and record a decision on each in the Statement of Applicability required by clause 6.1.3. Controls that do not treat a risk in your scope can be excluded with a justification tied to your role and your risk assessment. A deployer who builds nothing will legitimately exclude more of the life cycle group than a company that trains its own models.
What is the difference between Annex A and Annex B in ISO 42001?
Annex A lists the 38 controls as short normative statements and is what your Statement of Applicability is built against. Annex B is the implementation guidance for those same controls, explaining what each one means in practice. Annex C lists potential AI-related organizational objectives and risk sources for use in the risk assessment, and Annex D covers using the management system across different domains and sectors.
Are the ISO 42001 controls the same as the ISO 27001 controls?
No. They are different sets addressing different subjects. ISO 27001 Annex A has 93 controls in four themes about information security, while ISO 42001 Annex A has 38 controls about how AI systems are governed, built, fed with data and used. There is real overlap in supplier management, logging and change control, which is why organizations already certified to ISO 27001 find the second project much smaller.
Which ISO 42001 control covers training data?
Five of them, all under A.7. They cover the data used for development and enhancement, how data was acquired and on what legal basis, how its quality is judged, its provenance, and how it was prepared before use. If personal information is involved, the acquisition control is where Canadian privacy law meets the standard, because the purpose the data was collected for has to cover model training.
Does a deployer need the AI system life cycle controls?
Some of them. Deployment, operation and monitoring, technical documentation and event logging apply to anyone running an AI system in production, regardless of who built the model. The development-side controls can be excluded if you genuinely build nothing, but retrieval pipelines, prompt systems and agent scaffolding count as development, so the clean exclusion is narrower than most deployers assume.