ISO 42001 Checklist: What an Auditor Actually Asks to See
Most ISO 42001 checklists you will find are the clause list with tick boxes next to it. They are easy to produce and nearly useless, because they confirm you have read the standard rather than that you have implemented it.
This one is organised differently: by what each requirement has to produce. An auditor does not ask whether you have a procedure. They ask to see the record the procedure was supposed to generate, and they check the date on it.
How to use a checklist without it becoming theatre
Two rules make the difference.
Check for the record, not the document. A procedure describing how risk assessment works proves nothing. The risk register with entries, dates and owners proves the process ran. When you work through the list below, the question for each line is not “do we have a document about this” but “what would I hand someone who asked for evidence”.
Check the dates. Records all created in the same week, shortly before an audit, tell their own story. A management system that has been running produces records spread across time.
Part 1 — The 17 documented information requirements
ISO/IEC 42001 requires documented information in seventeen places across clauses 4 to 10. These are the ones a certification body will ask for by name.
| # | What must exist | Where it usually lives |
|---|---|---|
| 1 | The scope of the AI management system | Manual or scope document |
| 2 | The AI policy, approved by top management | Signed policy |
| 3 | AI risk criteria | Risk procedure |
| 4 | The AI risk assessment process | Risk procedure |
| 5 | The risk treatment process | Risk procedure |
| 6 | The Statement of Applicability | Register |
| 7 | The risk treatment plan | Risk register |
| 8 | The AI system impact assessment process | Impact procedure |
| 9 | The results of impact assessments | One record per system |
| 10 | AI objectives and the plans to achieve them | Objectives register |
| 11 | Evidence of competence | Competence records |
| 12 | Control of documented information | Document control procedure |
| 13 | Evidence that processes ran as planned | Life cycle records |
| 14 | Results of risk assessments and treatments | Risk register |
| 15 | Monitoring and measurement results | Indicator records |
| 16 | The internal audit programme and its results | Audit reports |
| 17 | Management review results | Review minutes |
Figure 1 — The seventeen documented information requirements, grouped by the process that produces them.
Everything else in clauses 4 to 10 still has to be done. These seventeen are simply the ones where the standard says the evidence must be written down.
Part 2 — The 38 Annex A controls
Annex A of ISO 42001 contains 38 controls across nine objectives. Unlike ISO 27001, where implementation guidance sits in a separate standard, Annex B of ISO 42001 is normative — the guidance is part of the standard.
| Objective | Controls | What it covers |
|---|---|---|
| A.2 Policies related to AI | 3 | The AI policy, its alignment with other policies, its review |
| A.3 Internal organization | 2 | Roles and responsibilities; reporting of concerns |
| A.4 Resources for AI systems | 5 | Documenting data, tooling, computing and human resources |
| A.5 Assessing impacts | 4 | The impact assessment process and its documentation |
| A.6.1 Development guidance | 2 | Objectives and processes for responsible development |
| A.6.2 AI system life cycle | 7 | Requirements, design, validation, deployment, operation, documentation, logs |
| A.7 Data for AI systems | 5 | Acquisition, quality, provenance, preparation |
| A.8 Information for interested parties | 4 | User information, external reporting, incident communication |
| A.9 Use of AI systems | 3 | Responsible use, use objectives, intended use |
| A.10 Third parties and customers | 3 | Responsibility allocation, suppliers, customers |
The checklist item here is not “have we implemented all 38”. It is: has every one of the 38 been decided on, with a reason recorded? Your Statement of Applicability must cover all of them, including the ones you exclude, and an exclusion needs a justification just as much as an inclusion does.
The most common finding is a Statement of Applicability that lists only the controls the organisation applies. That document is incomplete by definition.
Part 3 — The ten things auditors sample first
In practice, an auditor working through a stage 2 audit reaches for the same records early. If these ten exist, are complete and are dated across a period, the audit goes well.
1. The AI system inventory. Every system in scope, with an owner and the organisation’s role for it. Auditors compare this against what they can see the organisation actually using — including tools mentioned in passing during interviews.
2. The scope statement. Checked against the inventory. A scope narrower than the reality of the business is the finding that unravels everything after it.
3. The signed AI policy. With a date, and evidence it was communicated.
4. The risk register. Entries with sources, consequences assessed for both the organisation and for people, treatment decisions and owners.
5. The Statement of Applicability. All 38, decided and justified.
6. Impact assessment records. One per system, performed before deployment. Auditors check the date against the system’s go-live date.
7. Life cycle records. For at least one system, walked through from requirements to deployment, checking that each stage gate was passed on evidence.
8. Information given to users. The actual text users see, not the internal document describing what they should be told.
9. The internal audit report. With findings. An internal audit that found nothing invites the question of how thoroughly it was performed.
10. Management review minutes. With decisions. Minutes that record a discussion and no decisions suggest a meeting held to satisfy a requirement.
Figure 2 — The evidence an auditor samples first, and the process that should have produced each one.
The gaps that come up most often
The impact assessment is the gap that appears most often and takes longest to close — what an auditor looks for in one works through the six sections and the three failures.
One gap sits outside the standard altogether: the obligations the EU AI Act places on you regardless of certification. ISO 42001 helps you organise the work; it does not discharge the legal duty.
No inventory, or an incomplete one. The AI tools people signed up for individually, the AI features inside software already licensed, and the model behind a supplier’s service all count. An hour spent asking around fills more gaps than a week of writing.
Impact assessment treated as a form filled after deployment. The requirement is to assess before deployment, and the record’s date shows which happened.
Human oversight that cannot in practice contradict the system. A reviewer who approves 200 outputs an hour is not exercising oversight. Auditors ask how many were overridden and what happened when one was.
No approval record for bought-in AI. Purchase approval exists for anything with an invoice; nothing covers the tool someone signed up for with a work email. Decide explicitly what approval a free or trial tool requires.
Suppliers with no responsibility allocation. In particular, nobody has written down who answers when a person affected by an AI decision asks why. That question arrives eventually.
Data used without confirmed rights. Whether you may use a dataset for the purpose intended is far cheaper to answer before a model has been trained on it.
The honest readiness test
For the wider picture of what you are assembling, what an AI governance framework actually consists of covers the three layers and which parts a standard requires.
For medical device manufacturers this test is easier than it looks, because the QMS already produces most of the records — see ISO 42001 for medical devices.
If you have not yet decided whether to certify at all, what ISO 42001 certification actually involves covers the two-stage audit and what the certificate does and does not prove.
Pick one AI system. Ask someone who did not build it to assemble, in an hour: what it is for, what data it uses and where that data came from, what could go wrong for the people it affects, who approved it, what is monitored, and what happens when it misbehaves.
If they can produce that from existing records, you are close to ready. If they have to interview three people and write something new, the documentation exists but the management system does not — and that gap is what stage 2 is designed to find.
Our ISO 42001 kit contains the documents an AI management system needs, including a Statement of Applicability pre-populated with all 38 controls, each mapped to the kit document that implements it. €590 excl. VAT. If you’re writing the SoA itself, how to write one that survives Stage 1 covers the two inputs it needs and the exclusions that get rejected.