An ISO 42001 audit checklist for auditors is the working document an auditor uses to test an AI management system (AIMS) against ISO/IEC 42001:2023. Each line pairs a requirement with a question, the evidence to sample and the finding a gap would produce. The organization being audited writes a different list, a readiness checklist, to prepare.
The Global AI Certification Council (GAICC) wrote this guide for the person holding the clipboard. That person may be a second-party auditor checking an AI supplier or a certification body auditor at Stage 1 or Stage 2. Internal auditors who want third-party rigor can use it too. GAICC’s ISO/IEC 42001 Internal Auditor certification examines that first-party work, from audit planning to findings.
Two documents shape the method. ISO 19011:2026 guides audit practice, and ISO/IEC 17021-1 governs certification audits. GAICC’s ISO/IEC 42001 Lead Auditor credential and its exam test the same method. In that exam, the domain on auditing implementation and operational control carries 40 percent of the weight.
What an auditor’s checklist is, and what it is not
An auditor’s checklist is a set of tests chosen for one audit, with room to record what was seen. It belongs among the work documents ISO 19011:2026 covers under clause 6.3.4, “Preparing documented information for the audit”. A readiness checklist asks the auditee “do we have this?”. An auditor’s checklist asks “show me that this worked, on these samples, over this period”.
| Feature | Readiness checklist (auditee) | Auditor’s working checklist |
| Who writes it | The organization or its consultant | The auditor or audit team leader |
| Typical line | “AI policy approved” | “Policy approved by top management; trace two systems to policy commitments; interview one system owner on what the policy asks of them” |
| What it proves | Documents exist | Requirements are met and the AIMS works |
| Source of the lines | Clause headings and templates | The audit criteria, the audit scope and the risks found in planning |
| What it leaves behind | A ticked list | Recorded evidence that supports findings and the audit conclusion |
The checklist also differs from the audit plan. ISO 19011:2026 defines the plan as the description of the activities and arrangements for an audit. In certification audits, ISO/IEC 17021-1 has the plan communicated to the client in advance. The checklist stays with the auditor. Three habits separate a useful checklist from a copied one. Every line cites a clause, a control or an organization document, so each finding has an anchor. Every line names the evidence and the sample, so a second auditor would run the same test. And the checklist changes with the audit: a surveillance visit, a supplier audit and an initial Stage 2 deserve different lines.
A checklist is a guide, and the auditor still follows the evidence. A good interview answer may open a line of inquiry the plan never listed. Note it, test it, and add it to next year’s list.
Organizations preparing their own first-party audits should start from an organization’s clause 9.2 internal audit program. That guide covers schedules, auditor independence and an internal test library.
The audit criteria behind every checklist line
Audit criteria are the requirements you compare evidence against, and ISO 19011:2026 defines them that way in clause 3.8. Its note lists policies, procedures, legal requirements, contracts and industry standards as possible criteria. For an AIMS audit, four sources supply nearly every line.
| Criteria source | What it supplies | Where you find it | How it shapes the checklist |
| ISO/IEC 42001 clauses 4 to 10 | The “shall” requirements every AIMS must meet | The purchased standard | One or more tests per sub-clause |
| Annex A controls, as selected | Controls the organization chose to treat its AI risks | The Statement of Applicability (SoA) | Tests for included controls; a justification test for each exclusion |
| The organization’s AIMS documents | Its own policy, risk criteria, impact assessment method, procedures and objectives | Document control system | Tests that the organization does what it wrote |
| Legal and contract requirements in scope | Duties the organization recorded under clause 4.2 | Interested-party register, contracts | Tests that the AIMS addresses what it said it would |
Annex A is normative, yet no organization must apply every control. ISO/IEC 42001 defines the SoA in clause 3.26 as the documentation of necessary controls with a justification for including or excluding each. The SoA therefore tells you which Annex A lines belong on your checklist. Before testing an entry on site, read how an organization justifies each SoA entry, because the reason given is the first thing you test.
The organization’s own documents matter as much as the standard. Suppose the impact assessment procedure promises a reassessment after every model change. That promise becomes a criterion, and an unrecorded reassessment becomes a nonconformity against the procedure, even where the standard alone would leave room.
Certification audits add a fifth layer, which governs the auditor. ISO/IEC 17021-1:2015 sets requirements for every management system certification body. ISO/IEC 42006:2025 adds requirements for bodies that audit and certify an AIMS. Neither is a criterion for the auditee, but both shape how a certification auditor plans, samples and reports.
First, second and third-party checklists
The same clause can need a different line depending on who asked for the audit. ISO 19011:2026 sets out three types: first-party internal audits, second-party audits of external providers, and third-party certification audits. Its introduction says the guidance concentrates on the first two, while ISO/IEC 17021-1 provides the requirements for third-party certification.
| Audit type | Who audits | Rules the auditor follows | Checklist emphasis |
| First party (internal) | The organization, or an external party on its behalf | ISO/IEC 42001 clause 9.2; ISO 19011:2026 | Full coverage over the program cycle |
| Second party (supplier) | A customer, or someone acting for it | The contract and agreed criteria; ISO 19011:2026 | The supplied AI system, the customer’s contract terms and the supplier’s Annex A.10 controls |
| Third party (certification) | An accredited certification body | ISO/IEC 17021-1 and ISO/IEC 42006 | Stage 1 readiness, Stage 2 implementation and effectiveness, then surveillance samples |
GAICC’s Lead Auditor credential is aimed at the last two. Its Candidate Handbook describes it as confirming competence to lead second-party and initial third-party AIMS audits at Stage 1 and Stage 2. Audit work for a certification body also needs that body’s own approval, which approval to audit for a certification body explains.
ISO 19011:2026 principles as checklist design rules
ISO 19011:2026 lists seven principles of auditing in clauses 4.2 to 4.8, and each one changes how you build a checklist. The fourth edition, published on 27 May 2026, replaced the 2018 edition. Its main changes add remote auditing guidance drawn from ISO/IEC TS 17012 and expand Annex A on remote methods and virtual locations.
| Principle (ISO 19011:2026) | What it asks of the auditor | Checklist design rule for an AIMS audit |
| 4.2 Integrity | Work ethically and only where competent | Add a technical expert line for any AI technique the team cannot judge, such as retrieval or fine-tuning |
| 4.3 Fair presentation | Report truthfully, including obstacles and unresolved disagreements | Leave a field for evidence that was refused or unavailable |
| 4.4 Due professional care | Apply diligence and reasoned judgment | Write lines as “show me” requests, never yes or no questions |
| 4.5 Confidentiality | Protect information gathered | Record where model, prompt and personal data evidence was viewed, and that copies were not kept |
| 4.6 Independence | Stay free of bias and conflict of interest | Remove lines for any process you designed, advised on or operated |
| 4.7 Evidence-based approach | Use verifiable evidence based on samples | Name the sample and its period on every line |
| 4.8 Risk-based approach | Let risks and opportunities shape planning, conduct and reporting | Weight lines toward high-impact AI systems and recent changes |
The evidence-based principle carries a warning that applies to every AIMS audit. ISO 19011:2026 says audit evidence should rest on samples of the information available, because an audit has limited time and resources. It ties the use of sampling to the confidence that can be placed in the audit conclusions. A checklist that hides its samples hides the limits of its conclusion.
With the criteria fixed and the principles turned into design rules, the checklist itself can be written.
Clause-by-clause tests for clauses 4 to 10
Clause tests check that the management system itself conforms and works. The table is GAICC’s editorial analysis of common AIMS audit practice. Clause titles come from the standard’s table of contents. The questions paraphrase the requirements, so check each line against your licensed copy of ISO/IEC 42001.
| Clause | What to ask | Evidence to sample | Typical finding |
| 4.1 Context | Which AI systems are developed, provided or used, and what role was decided for each? Was climate change judged relevant? | Context record; role per system; climate determination | One role decided for the whole company |
| 4.2 Interested parties | Which interested-party requirements will the AIMS address? | Register; two customer contracts with AI terms | A contract requires model change notices that nobody sends |
| 4.3 Scope | Where are the boundaries, and which AI systems sit inside? | Scope statement; system list; procurement and sign-on data | AI features in bought tools left out with no reason |
| 5.2 AI policy | Is the policy suitable, approved and communicated? | Approved version; awareness records | Commitments no objective or control carries out |
| 5.3 Roles | Who ensures conformity, and who reports performance to top management? | Role assignments; one performance report | Reporting duty held by someone who left |
| 6.1.2 AI risk assessment | Are criteria set, and are results repeatable and current? | Risk criteria; register; three assessed systems | Scores with no defined criteria |
| 6.1.3 AI risk treatment | Do treatments name controls that match the SoA, and did designated managers accept residual risk? | Treatment plan; SoA version; approvals | A treatment names a control the SoA excludes |
| 6.1.4 Impact assessment | Is there a process for effects on individuals, groups and societies, and do results feed the risk assessment? | Process; two assessments; matching risk entries | An impact that never reaches the register |
| 6.2 AI objectives | Are objectives measurable where practicable and monitored? | Objectives; measures; results | Objectives with no measure or owner |
| 7.2 Competence | Is the competence needed for work affecting AI performance defined and evidenced? | Competence matrix; three people’s records | Model reviewers with no recorded training |
| 7.5 Documented information | Are AIMS documents approved, versioned and protected? | SoA and register version history | Two live versions of the risk register |
| 8.1 Operational control | Do processes run to their criteria? | Release approvals; one observed process | Releases approved outside the defined gate |
| 8.2 and 8.3 Risk work in operation | Are assessments rerun at planned intervals or on significant change, and is the treatment plan carried out? | Reassessments after the last two changes | No reassessment after a provider model swap |
| 8.4 Impact work in operation | Are impact assessments repeated at planned intervals or when significant changes are proposed? | Change log against dated assessments | A retrained model under its old assessment |
| 9.1 Monitoring | What is monitored, when, and are results analyzed? | Monitoring plan; drift or error reports | Dashboards never evaluated |
| 9.2 Internal audit | Is there a program with impartial auditors and reported results? | Program; two reports; assignments | The implementer audited their own risk method |
| 9.3 Management review | Were the required inputs reviewed and decisions recorded? | Minutes; input pack | No decision on changes or improvements |
| 10.2 Corrective action | Are causes found, actions taken and effectiveness reviewed? | Corrective action log; three closed items | Items closed on correction alone |
Use the table differently at each stage of a certification audit. At Stage 1 the questions point you at documents and readiness. At Stage 2 the evidence column carries the weight, because ISO/IEC 17021-1 makes Stage 2 an evaluation of implementation, including effectiveness. The organization’s side of that sequence is set out in the certification cycle from Stage 1 to recertification.
Write questions as open requests. “Is there a risk method?” invites a yes. “Walk me through how the risk score for the claims model was reached” invites evidence, and the answer tells you which record to pull next.
Testing Annex A controls by objective
Annex A testing checks that each included control operates and that each exclusion still holds. Annex A sets out control objectives and controls in nine areas, A.2 to A.10. The IDs and short titles below follow public enumerations of the standard and should be checked against your licensed copy. GAICC wrote the tests as editorial suggestions, and the standard prescribes no test list.
| Area (Annex A) | Test | Evidence | Sampling note |
| A.2 Policies related to AI (A.2.2 to A.2.4) | Policy aligns with other policies and is reviewed | Review record; security and privacy policies | One review cycle is the whole population |
| A.3 Internal organization (A.3.2, A.3.3) | Roles assigned; concerns reported and handled | Role list; concern reports | Take every concern raised, if few |
| A.4 Resources for AI systems (A.4.2 to A.4.6) | Data, tooling, computing and human resources documented per system | Resource records | Pick systems from different teams |
| A.5 Assessing impacts (A.5.2 to A.5.5) | Process exists; assessments documented; individual and societal impacts both covered | Assessments; approvals | Weight toward systems that affect people |
| A.6 AI system life cycle (A.6.1.2 to A.6.2.8) | One release traced from requirements to validation, deployment, monitoring and event logs | Release file; test results; log extracts | Sample releases, then follow each end to end |
| A.7 Data for AI systems (A.7.2 to A.7.6) | Acquisition, quality, provenance and preparation recorded | Dataset records; source and rights basis | Datasets used for training, fine-tuning or retrieval |
| A.8 Information for interested parties (A.8.2 to A.8.5) | User documentation, external reporting and incident communication | Published information; incident notices | Incidents first |
| A.9 Use of AI systems (A.9.2 to A.9.4) | Use follows defined processes and intended use | Oversight records; out-of-purpose use | Decisions meant for human review |
| A.10 Third-party and customer relationships (A.10.2 to A.10.4) | Responsibilities allocated; suppliers and customers managed | Contracts; supplier reviews | Suppliers of the highest-impact systems |
One well-chosen A.6 release can test design, validation, deployment and logging in a single walkthrough. A.10 carries the most weight in supplier audits. The organization’s side of each control is set out in what implementing each Annex A control involves.
For certification audits, plan the team as well as the lines. In its published text, ISO/IEC 42006 requires the audit team to have collective knowledge of all Annex A controls and their implementation. A checklist with A.7 lines needs someone on the team who can read a data provenance record.
Testing a control the SoA excludes
An excluded control gets a justification test. ISO/IEC 42001 allows exclusion where the risk assessment shows the control is not needed, or where external requirements do not call for it. Read the reason in the SoA, then look for evidence that contradicts it. Suppose A.8.4 on communication of incidents is excluded because the organization has “no external users”, yet a customer-facing assistant answers account questions. The exclusion fails the test. Record the gap against clause 6.1.3, since that clause governs the SoA, and test whether any risk went untreated.
Sampling AI systems
Sampling decides which AI evidence you see, so record it on the checklist as carefully as the tests. Neither ISO/IEC 42001 nor ISO 19011:2026 sets a sample size, so the size is a judgment each auditor has to make and defend. ISO/IEC 17021-1 requires appropriate sampling and verification of information in certification audits.
Choosing the unit of audit
The unit of audit is the thing you count and select. For an AIMS, several units are possible, and each answers a different question.
| Unit | Use it to test | Population comes from |
| AI system | Scope, roles, impact and risk coverage | The system list and the scope statement |
| Model release or change | Life cycle controls and reassessment triggers | Change log, model registry, release tickets |
| Decision or output | Human oversight and intended use | Case logs, review queues |
| Dataset | Data acquisition, quality and provenance | Data catalog, training records |
| Supplier | Third-party controls and contract terms | Supplier register, purchase records |
| Incident or concern | Reporting, communication and corrective action | Incident log, concern channel |
Pick the unit before the sample. An auditor who samples “five AI systems” when the question is about release control will see five sets of documents and no releases.
Risk-based selection
Risk sets the sample, and the size follows. ISO 19011:2026 asks audit programs to give priority to matters with higher inherent risk and lower levels of performance. Its risk-based principle carries the same logic into each audit. GAICC suggests four strata for AI evidence. They are the impact level recorded for each system, the volume of change since the last audit, incidents and complaints, and open or repeat findings. Take most of the sample from the high strata. Keep a few low-strata items to test that the ranking itself is right.
Tracing in both directions
Traceability runs two ways, and a checklist should test both. Forward tracing starts at a risk in the register and follows it to the treating control in the SoA. It then asks for records that show the control operating. Backward tracing starts at an operating record, such as a production log entry or a human review decision. It asks which control the record belongs to and which risk that control treats. Forward tracing finds controls that exist only on paper. Backward tracing finds activity the AIMS does not govern. Together the two traces form the audit trail for one system. An orphaned record, with no control or risk behind it, often points to an AI system missing from scope.
Recording the sample
Each sampled line should state the unit, the population and its source, the items chosen, the period covered and the reason for the choice. Write it down at the time. Certification audit reports must carry a statement that auditing rests on a sample of the information available. The rule comes from ISO/IEC 17021-1, as summarized in the International Accreditation Service’s training slides on section 9. The recorded sample is what makes that statement honest.
Remote audit notes for AI evidence
Remote auditing suits much AIMS evidence, because model registries, logs and approval trails often live in online systems. ISO 19011:2026 takes its definition from ISO/IEC TS 17012:2024: a remote auditing method is used from any place other than the auditee’s location. A note extends it to virtual locations, where work happens in an online environment wherever people sit.
Certification audits add binding rules. IAF MD 4:2025 is the mandatory document on information and communication technology (ICT) in conformity assessment. The International Accreditation Forum issued it in January 2025, before its work passed to Global Accreditation Cooperation Incorporated on 1 January 2026, and it applies from 30 January 2026. It makes ICT optional, and its use must be agreed with the client under information security and data protection measures. The body must document the risks and opportunities of using ICT, and the audit plan must show how and how far ICT will be used. Reports must state the extent of ICT use and how effective it was. A virtual site counts as a single site when audit time is calculated. ISO/IEC 42006 also has a clause on the deployment of remote audit, 9.2.4.
GAICC suggests four checklist notes for AI evidence.
- Ask the auditee to open the live system on screen. A screen share of the model registry shows history that a spreadsheet export can hide.
- Check who produced any exported evidence, from which system and when. Exports can be edited.
- Agree in advance how personal data and confidential prompts will be shown, and record that nothing was copied.
- Keep on-site or live-observed lines for anything physical or interactive, such as a human review desk.
Fieldwork ends at the checklist’s last line, and the results now have to become findings, a report and a plan for the next visit.
Turning checklist results into findings
A finding is the result of evaluating collected evidence against the audit criteria, as ISO 19011:2026 defines it in clause 3.11. A finding shows conformity or nonconformity, and it can also identify risks, opportunities for improvement or good practice. Every checklist line therefore ends in one recorded outcome, with its evidence beside it.
| What the line showed | Record it as | What the line must hold |
| Evidence meets the criteria | Conformity | The sample and an evidence reference |
| A requirement is not met | Nonconformity | The requirement, the objective evidence and a clear statement of the gap |
| Requirement met, practice could improve | Opportunity for improvement | The point observed, with no prescribed fix |
| Practice worth repeating elsewhere | Good practice | Where it was seen and why it works |
| Evidence refused, missing or unreadable | Limitation on the audit (GAICC label) | What was asked for, and why it could not be tested |
The last row comes from the fair presentation principle, which asks auditors to report significant obstacles met during the audit. A line left blank tells the reader nothing. A line that says “event logs for the claims model were not available for the period” tells the report writer what the conclusion cannot cover.
Certification audits fix the form of a nonconformity in ISO/IEC 17021-1. Each one names a single requirement, says plainly what is unmet and points to the objective evidence. Those parts come from three checklist fields filled in on the day: clause, sample and evidence reference. Without them, the closing meeting turns into a search through notes.
Grading comes after the finding is written. Whether a gap is major or minor depends on how far it weakens what the AIMS is meant to deliver. The full method, with worked examples for AI systems, is in writing and grading ISO 42001 nonconformities.
From checklist to audit report and follow-up
The audit report is built from the checklist, so the checklist must keep what the report needs. Under ISO/IEC 17021-1, a certification audit report covers a long list of items. Several come straight from the checklist: the criteria, the objectives, the scope, any deviation from the plan and the findings with evidence references. The report also carries the sampling statement, the team’s recommendation and a statement on the conformity and effectiveness of the management system. For first and second-party audits, ISO 19011:2026 gives parallel guidance in clause 6.5, “Preparing and distributing the audit report”. Follow-up sits in clause 6.7.
| Report element | Checklist field that feeds it |
| Criteria and scope | Header: standard, SoA version, organization documents, systems and period in scope |
| Deviations from the plan | Lines not tested, with the reason |
| Findings and evidence | Outcome and evidence reference on each line |
| Sampling statement | Unit, population, items and period on each sampled line |
| Statement on effectiveness | Clause 9 lines on monitoring, internal audit and management review |
| Extent of remote methods | A per-line note of remote or on-site testing |
The closing meeting
At the closing meeting, the client first hears the checklist’s results as a whole. Under ISO/IEC 17021-1, a certification audit ends with a formal closing meeting. Attendance is recorded. The team explains how and when the report will arrive, including how findings are graded. It also explains how the certification body handles nonconformities and what they can mean for certification status. The client learns when its response is due and how complaints and appeals work. The team leader tries to resolve disagreements. Unresolved points are recorded. Bring the checklist to the meeting, because the evidence reference on each line is what settles a dispute.
Verifying corrective action on the next visit
Follow-up checks that the organization’s response works. In certification audits, the certification body reviews the corrections, causes and corrective actions submitted and decides whether they are acceptable. It then verifies their effectiveness. The client is told whether that needs an extra full audit, an extra limited audit, or documented evidence confirmed at a later audit. The next report must record whether corrective actions on earlier nonconformities worked. Give every open finding its own line on the next checklist, and test it against the same unit of audit that exposed it.
Surveillance audits: what goes on next year’s checklist
A surveillance checklist is shorter and more targeted than a Stage 2 checklist. ISO/IEC 17021-1 describes surveillance audits as on-site audits that are not necessarily full system audits, and lists topics each one reviews. The table pairs those topics with AIMS samples, and the sample column is GAICC’s suggestion.
| Topic each surveillance reviews (ISO/IEC 17021-1) | AIMS sample to put on the checklist |
| Internal audits and management review | Audit reports and review minutes since the last visit |
| Actions on nonconformities from the previous audit | Each earlier finding, retested on the same unit |
| Complaints handling | AI-related complaints and concerns raised under A.3.3 |
| Effectiveness in meeting objectives and intended results | Monitoring results against AI objectives |
| Progress on continual improvement | Improvement actions from the last management review |
| Continuing operational control | One new or changed AI release, traced end to end |
| Review of changes | New AI systems, scope changes and SoA versions since certification |
| Use of marks and references to certification | Customer-facing claims about the certificate |
Change drives most surveillance lines. A new AI system, a provider model swap or a new SoA version since the last audit should each earn a test. A line that found nothing on two visits in a row can wait for a later one. Keep one standing line for the certificate itself: ISO/IEC 42006 requires an AIMS certificate to name the SoA version it rests on, so check that version against the SoA now in use.
Recertification in year three works from the whole cycle. Under ISO/IEC 17021-1, the recertification activity reviews earlier surveillance reports and confirms continued conformity and effectiveness for the scope of certification. Significant changes to the AIMS or to the law can call for a Stage 1 again. Build the recertification checklist from the surveillance reports, so areas that were never sampled during the cycle get covered.
Keeping the checklist after the audit
A completed checklist is an audit record, and certification bodies keep the reasoning behind it. Their client records under ISO/IEC 17021-1 include the justification of the sampling method and the verification of corrections and corrective actions. Store each checklist with the report it supports, and reuse it as the starting point for the next visit to the same client. Mark which lines were tested remotely, so the next team knows where on-site evidence is still owed.
Building audit programmes, checklists, audit criteria and timelines is a listed topic of the GAICC Lead Auditor course’s audit planning module. The course page also lists Stage 1 and Stage 2 audit modules and a mock audit module.
Frequently Asked Questions
Is there an official ISO 42001 audit checklist?
No. ISO and IEC publish ISO/IEC 42001, and ISO publishes the auditing guidance in ISO 19011:2026, but neither provides a ready-made checklist for auditors. Certification bodies prepare their own work documents, and the rules they audit under come from ISO/IEC 17021-1 and ISO/IEC 42006. Any checklist you download is someone’s interpretation, so trace each line back to a clause, a control or an organization document before relying on it.
Can I use an ISO 27001 audit checklist for an ISO 42001 audit?
Partly. Both standards follow the harmonized structure, so lines for document control, internal audit, management review and corrective action carry over with small edits. AI-specific lines need writing from scratch. They cover role decisions under 4.1, the impact assessment under 6.1.4 and 8.4, and the Annex A controls on life cycle, data and use. Check that the reused 27001 lines name AI evidence too.
How many questions should an ISO 42001 audit checklist have?
No standard sets a number. The right size depends on the audit scope, the time available and the risks found in planning. In GAICC’s view, a Stage 2 checklist needs at least one line per sub-clause of clauses 4 to 10, plus one per included Annex A control. A surveillance checklist is shorter. Count samples as well as lines when you plan time.
Should the auditee see the checklist before the audit?
The audit plan goes to the auditee, and the checklist is the auditor’s own work document. Sharing the topics helps the organization have the right people and systems ready. Sharing every test invites rehearsal. A workable middle course is to share the plan and areas of focus, and keep sample choices until fieldwork.
Can an AI tool draft my audit checklist?
An AI tool can draft lines, but the auditor stays responsible for every one. ISO 19011:2026 asks auditors to act only where competent and to base conclusions on verifiable evidence. Check each drafted line against the standard’s actual wording and the organization’s documents. Never paste confidential audit evidence into a tool the client has not agreed to.
What changes for a second-party audit of an AI supplier?
The audit criteria change first. A customer auditing a supplier usually tests the contract and the supplied AI system before the wider AIMS. The supplier’s controls under A.10 and A.8 come next. If the supplier holds an ISO/IEC 42001 certificate, read its scope and the SoA version it cites. Then focus your tests on what the certificate does not cover.
