ISO 42001 Annex A controls
ISO 42001:2023 Annex A lists 38 reference controls under nine headings, A.2 to A.10, from the AI policy (ISO 42001:2023 Annex A 2.2) to supplier and customer relationships. Clause 6.1.3 asks you to compare the controls your risk treatment needs with Annex A and justify each inclusion and exclusion in a Statement of Applicability.
The requirement in plain English
Annex A is a reference set, not a list you must complete. Under ISO 42001:2023 6.1.3 you choose controls from your risk treatment and your impact assessments, take them from Annex A or from anywhere else, and then check Annex A so nothing necessary is missed. The Statement of Applicability records the controls you need, why each is included, whether it is in place, and why any Annex A control is left out. Annex B explains how to implement each control, and auditors use it to judge whether yours is real.
The 38 controls group by what they are for. The table describes the purpose of each heading in plain words; it does not list the controls or reproduce their titles.
| Heading | What its controls are for | Controls |
|---|---|---|
| A.2 | Direction: an AI policy that fits your other policies and stays current | 3 |
| A.3 | Organisation: clear accountability for AI, and a route for people to raise concerns | 2 |
| A.4 | Resources: a written account of everything each AI system depends on to work | 5 |
| A.5 | Impact: judging, and recording, what each AI system could do to people and to society | 4 |
| A.6 | Building and running AI: goals and processes for responsible development, then control of each stage of a system’s life from specification to monitoring, with records along the way | 9 |
| A.7 | Data: deciding what data a system may be built on, and keeping a trustworthy account of where it came from and how it was handled | 5 |
| A.8 | Information for others: telling users and other interested parties what they need to know, and giving them a way to report harm and hear about incidents | 4 |
| A.9 | Use: making sure AI is used responsibly and only for what it was meant for | 3 |
| A.10 | Third parties: agreeing who answers for what with partners, suppliers and customers | 3 |
A few controls carry most of an auditor’s attention. ISO 42001:2023 Annex A 3.2 is where named roles live. ISO 42001:2023 Annex A 5.2 requires the impact assessment process that clause 6.1.4 calls for. ISO 42001:2023 Annex A 6.2.6 covers operation and monitoring, where drift and misuse show up. ISO 42001:2023 Annex A 7.5 asks you to record where data came from. ISO 42001:2023 Annex A 8.3 gives people outside the organisation a way to report harm. ISO 42001:2023 Annex A 9.4 keeps use within the intended purpose, and ISO 42001:2023 Annex A 10.3 makes sure suppliers’ AI fits your approach.
Annex A has no information security controls. Security of models, data and infrastructure comes from your security controls, usually ISO 27001 Annex A, which is why the two standards are often certified together.
This is guidance to help you understand the requirement, not legal advice.
What good looks like
A 45-person health analytics company develops one prediction model and uses three bought-in AI tools. Its Statement of Applicability has 38 rows plus two controls of its own.
Each row names the control by number and short title, says whether it applies, gives a justification that points to a risk, an impact finding or a contract, states the implementation status honestly (in place, partly in place, planned with a date), and points to the evidence. A control owner is named on every applicable row.
Because it develops a model, the company applies all nine lifecycle controls and all five data controls; its dataset records show provenance and preparation for every training set. For the bought-in tools, the use and third-party controls do the work: each tool has an approval record stating its intended purpose, and each supplier was assessed against the company’s AI policy.
It adds two controls not in Annex A: a clinical safety sign-off before each model release, and a quarterly fairness review shared with a customer’s ethics board. Both trace to impact findings.
The Statement of Applicability is versioned, reviewed after each risk and impact reassessment, and approved by the head of AI governance.
Evidence an auditor expects
- Statement of Applicability (required documented information): every Annex A control listed with inclusion or exclusion, justification and status.
- Justified exclusions: each traced to a scope fact, a role you do not play or a risk you do not have.
- The AI policy and role allocations: the documents behind the direction and organisation controls.
- Impact assessments: one per AI system, as the impact controls require.
- Lifecycle and data records for a sample system: requirements, verification and validation, deployment approval, monitoring results, dataset provenance.
- Information for users and a concern or adverse-impact channel: what users receive, and evidence the channel works.
- Supplier and customer records: assessments and allocated responsibilities for third-party AI.
Common mistakes
Exclusions with no reason
“Not applicable” is not a justification. Say why: no AI development in scope, no training data held, no customers receiving AI outputs.
Deployers excluding the impact and reporting controls
Using bought-in AI still affects people. The impact assessment and the external reporting channel rarely have a defensible exclusion.
Rows that restate the control
“AI policy: implemented” tells the auditor nothing. Point to the approved document, its version and its last review.
Ignoring Annex B
Auditors read Annex B to see what a control is expected to involve. A control implemented without its guidance often turns out partial on sampling.
Assuming Annex A covers security
It does not. Without security controls from another source, model theft, data poisoning and access to training data go untreated.
How Sted helps
- Sted keeps a Statement of Applicability for each adopted standard with a control catalogue.
- Only standards with a control catalogue get a Statement of Applicability card.
- Each Statement of Applicability card on the Summary lists the standard’s controls by theme as Applicable, Excluded or Not addressed, with any exclusion reason, the implementation status and when each was last verified; below administrator it is marked as a partial view, and its PDF needs a paid plan.
- You can exclude a control with a coded reason and justification and record its implementation status.
- An excluded control needs one of nine coded reasons, Other needs a written justification, and an excluded control counts as decided for audit readiness; a document’s controls cannot be decided while a newer draft of it is in progress.
- Under the AI System Lifecycle Procedure (PRC-AISL) Sted’s knowledge base carries a record for each stage of an AI system’s life, the AI Development Plan (REC-AIDP), Dataset Record (REC-DSET), Experiment Record (REC-AIER), Model Evaluation Report (REC-AIME), Bias and Fairness Assessment Record (REC-AIBF), Deployment Readiness and Integration Test Record (REC-AIDR), Post-Deployment Monitoring Plan (REC-PDMP) and Post-Deployment Monitoring Record (REC-AIPD), tagged to the ISO 42001 Annex A lifecycle, data and resource controls.
- Records are part of the Full Management System plan.
Sted lists the controls and records your decisions. Which controls you need, and why, comes from your own risk and impact assessments.
Related guides and terms
- ISO 42001: the hub, with how Annex A fits the clauses.
- AI risk and impact assessment: where the decisions behind each control come from.
- Statement of Applicability guide: writing inclusion and exclusion reasons an auditor accepts.
- Control: what counts as a control, and how it differs from a policy.
- ISO 42001 performance evaluation and improvement: how the internal audit tests the controls you chose.
- Statement of Applicability in Sted: the card that lists these controls with your decisions.
- ISO 42001 operation and the AI system lifecycle: the lifecycle and data controls, A.6 and A.7, in practice.
Frequently asked questions
How many controls are in ISO 42001 Annex A?
38, under nine headings numbered A.2 to A.10. Numbering under each heading starts at its second number, such as A.2.2, and the lifecycle heading has two sub-groups, A.6.1 and A.6.2, each with its own objective. Annex B gives implementation guidance for each control.
Can we exclude Annex A controls if we only use AI built by others?
Yes, with a reason an auditor can check. A user of bought-in AI often excludes the controls on designing and developing systems and on training data. The controls on responsible use, suppliers, reporting concerns and impact assessment usually stay, because they apply to how you use the system.