ISO 42001 Annex A
Annex A in practice: what each AI control asks you to prove.
Clauses 4 to 10 of ISO/IEC 42001 say how the management system must run. Annex A is the menu of controls you choose from once your risk and impact assessments show what is needed. Below, that menu is regrouped around four questions an auditor will put to you, with the record that usually answers each one.
Back to ISO 42001 services01 · How it is built
How the annex is put together
Nine objectives numbered from A.2, and three informative annexes behind them.
Numbering starts at A.2 because the first sub-clause of each objective states its aim, and the controls follow it. Across the nine objectives there are thirty-eight controls in total. Annex A is normative: every control must be considered. The annexes after it are informative and carry no requirement of their own.
- Annex A
- The control list. Each entry must be weighed, then kept or dropped with a reason.
- Annex B
- Implementation guidance, control by control. Useful for intent; not audited as a requirement.
- Annex C
- Example organisational objectives and sources of risk, handy as prompts for your assessments.
- Annex D
- Notes on running an AIMS across different sectors and domains.
- Statement of Applicability (SoA)
- Your record of the decision taken on each control, with the reason and its status (clause 6.1.3).
02 · Four questions
Four questions hiding inside nine objectives
Regrouped this way, the purpose of each control is easier to see.
- Who decides and answers for it
- 5
- A.2 policy, A.3 internal organisation
- What the AI runs on
- 10
- A.4 resources, A.7 data
- What it does to people
- 8
- A.5 impacts, A.8 information
- How it is built, used and sourced
- 15
- A.6 life cycle, A.9 use, A.10 third parties
38 in total.
In the tables that follow, the middle column is our own plain-language reading of each control, not the standard's title or wording. Keep the published text beside you when you draft the SoA.
03 · Who decides
Question 1: who decides, and who answers for it?
Objectives A.2 (policy) and A.3 (internal organisation).
| Ref | What it asks of you | Record an auditor will ask for |
|---|---|---|
| A.2.2 | Put the organisation's position on building and using AI into a policy that leadership signs | The current policy, who approved it and when |
| A.2.3 | Find where the AI policy meets security, privacy, quality and other existing policies, and settle any clash | A cross-reference showing each overlap and how it was resolved |
| A.2.4 | Revisit the policy on a fixed rhythm and whenever something big shifts | Review notes, with changes made or a reason for none |
| A.3.2 | Give named people defined duties for AI from design to retirement | A role list or responsibility matrix tied to real names |
| A.3.3 | Offer staff a safe route to flag worries about an AI system | The channel, how staff learn of it, and what became of past reports |
04 · What it runs on
Question 2: what does the AI run on?
Objectives A.4 (resources) and A.7 (data).
| Ref | What it asks of you | Record an auditor will ask for |
|---|---|---|
| A.4.2 | Know and write down everything each AI system depends on to work | A resource record per system |
| A.4.3 | Describe the datasets each system draws on | Dataset entries linked to the systems that use them |
| A.4.4 | Track the libraries, frameworks, model hubs and platforms behind your models | A tooling list with versions and owners |
| A.4.5 | Account for compute, hosting and infrastructure, cloud regions included | Architecture notes or an infrastructure register |
| A.4.6 | Make sure each person involved has the skills their part needs | Competence records and training plans |
| A.7.2 | Decide what data a system needs to be built and later improved | Data requirements in the design record |
| A.7.3 | Obtain data in a way you can defend: source, licence, consent where it applies | Acquisition records, licences, contracts |
| A.7.4 | Set quality expectations for data and test against them | Quality criteria and the results of checks |
| A.7.5 | Be able to trace where data came from and what has happened to it since | A lineage record per dataset |
| A.7.6 | Control how data is cleaned, labelled, sampled and transformed | Preparation procedures and labelling guidelines |
05 · What it does to people
Question 3: what does it do to people, and who gets told?
Objectives A.5 (impacts) and A.8 (information).
| Ref | What it asks of you | Record an auditor will ask for |
|---|---|---|
| A.5.2 | Follow a set method for weighing the consequences a system could have | The method, plus the events that trigger it |
| A.5.3 | Keep the output of every such assessment | Completed, dated assessments with sign-off |
| A.5.4 | Consider what the system could do to individual people and to groups of them | Named affected groups, harms and mitigations |
| A.5.5 | Consider effects that spread beyond direct users into wider society | A societal section that says something specific |
| A.8.2 | Give users what they need to work with the system properly | User documentation and in-product notices |
| A.8.3 | Let outsiders tell you about harmful effects they see | A public reporting route and its log |
| A.8.4 | Plan who hears about an AI incident, and how | The incident procedure and notification records |
| A.8.5 | Decide what regulators, customers and other stakeholders are owed | A disclosure plan or register |
06 · Built, used, sourced
Question 4: how is it built, used and sourced?
Objectives A.6 (life cycle), A.9 (use) and A.10 (third parties).
| Ref | What it asks of you | Record an auditor will ask for |
|---|---|---|
| A.6.1.2 | Set goals that steer engineering toward trustworthy outcomes | Documented development goals |
| A.6.1.3 | Define how design and engineering work gets done | A development procedure |
| A.6.2.2 | Write down what a new system or change must achieve, ethical needs included | Requirement specifications |
| A.6.2.3 | Capture design choices and the reasons behind them | Design records and decision logs |
| A.6.2.4 | Show the system meets its requirements before it goes live | Test plans, results and sign-off |
| A.6.2.5 | Go live under a plan with explicit release criteria | A deployment plan and its approval |
| A.6.2.6 | Watch the system once live, including for drift and error patterns | Monitoring views, alerts and follow-up actions |
| A.6.2.7 | Keep technical documentation the right readers can actually use | Current technical documents |
| A.6.2.8 | Choose which events to log, then keep the logs | Logging configuration and sample entries |
| A.9.2 | Define how the organisation goes about using AI with care | A usage procedure |
| A.9.3 | Set goals for that use | Documented usage goals |
| A.9.4 | Keep each system to the purpose it was designed and documented for | Purpose statements and checks on real use |
| A.10.2 | Split duties clearly between you, partners, suppliers and customers | Contracts or a responsibility matrix |
| A.10.3 | Pick and manage suppliers of models, data and AI services in line with your approach | Supplier assessments and contract clauses |
| A.10.4 | Account for what customers expect and need when you supply AI to them | Customer-facing documentation and terms |
07 · SoA decisions
Deciding in or out, one control at a time
A good SoA line reads like a short argument, not a tick.
Weak line
A.7.3: excluded
Reason given: N/A, we do not collect data.
Defensible line
A.7.3: excluded
Illustrative. We call a vendor's hosted model and train nothing, so no data is obtained for development. Revisit if fine-tuning starts. Linked to risk entry R-12.
- Point at the assessment. Each control kept in names the risk or impact it treats.
- Explain exclusions in your system's terms. State the fact about your AI that makes the control irrelevant, and what would change it.
- Record status as well as choice. Planned, partly in place, or operating. Auditors read status against the evidence.
- Go beyond the list when needed. The annex is not a ceiling. Clause 6.1.3 lets you add controls of your own where the assessments call for them.
Sources: ISO/IEC 42001:2023 clause and Annex A numbering and objective titles as publicly listed, clause 6.1.3, and the informative role of Annexes B, C and D. Every control description above is our own plain-language summary, not the standard's text; the published standard holds the normative wording.
Working questions on Annex A
Can we leave a control out entirely?
Yes, with a reason tied to your AI.
Exclusion is allowed. What fails audits is an exclusion with no link to the scope or the assessments. Write down the fact that makes the control irrelevant, and what would bring it back in.
We only buy AI. Do the life cycle controls still apply?
Fewer of them, and in a different form.
Much of A.6 is aimed at teams that design and train systems. A buyer still configures, releases and monitors, so the go-live and monitoring controls usually stay, while A.10 on suppliers moves to the centre. The AI role emulator helps work out which role you hold.
Does our ISO 27001 work count toward any of this?
It supports some controls and replaces none.
Security controls for logging, suppliers and incidents produce evidence you can reuse, for example for event logs or supplier checks. The AI concerns, such as effects on people, data lineage and purpose limits, have no counterpart in an ISMS.
Will the auditor check us against Annex B?
Not as a requirement.
Annex B explains ways a control might be put into practice. Auditors judge whether your control works for your systems, not whether you followed the guidance line by line. It is still the quickest way to understand what a control is for.
Turn the menu into decisions.
An ISO 42001 readiness assessment walks every Annex A control against your systems and drafts the SoA reasoning with your owners.