An ISO 42001 internal audit is the first-party audit that clause 9.2 of ISO/IEC 42001:2023 on iso.org, published 18 December 2023, requires at planned intervals. It checks whether your AI management system (AIMS) conforms to your own requirements and to the standard, and whether it is effectively implemented and maintained. Clause 9.2.2 then requires a written audit program that sets frequency, methods, responsibilities, planning requirements and reporting.
The numbering matters, because AI answers and several guides get it wrong. The official table of contents reads:
| Clause | Title in ISO/IEC 42001:2023 | What it covers |
| 9.2 | Internal audit | The parent clause |
| 9.2.1 | General | Why you audit: conformity and effective implementation, at planned intervals |
| 9.2.2 | Internal audit programme | How you audit: the program, each audit’s objectives, criteria and scope, auditor selection, reporting and records |
Source: ISO/IEC 42001:2023 official preview, table of contents.
If a checklist calls the audit program “9.2.1”, it cites the wrong sub-clause.
What ISO/IEC 42001 Clause 9.2 Requires
Clause 9.2 asks for two things: audits at planned intervals (9.2.1) and a managed program that produces evidence (9.2.2). The official preview states that ISO/IEC 42001 applies the harmonized structure: identical clause numbers, titles, core text and definitions shared by management system standards. The internal audit clause is core text, so its requirements match the published harmonized structure wording.
| Requirement | Sub-clause | Record that proves it |
| Audit at planned intervals | 9.2.1 | Program schedule and completed audit dates |
| Check conformity to your own AIMS requirements and to ISO/IEC 42001 | 9.2.1 a) | Audit criteria listing clauses, SoA controls and your procedures |
| Check the AIMS is effectively implemented and maintained | 9.2.1 b) | Sampled operating records, not only documents |
| Plan, establish, implement and maintain a program with frequency, methods, responsibilities, planning requirements and reporting | 9.2.2 | The audit program record |
| Consider the importance of the processes and the results of previous audits | 9.2.2 | Risk rating per audit area; prior findings referenced |
| Define objectives, criteria and scope for each audit | 9.2.2 a) | Audit plan for each audit |
| Select auditors to ensure objectivity and impartiality | 9.2.2 b) | Auditor assignment with independence check |
| Report results to relevant managers | 9.2.2 c) | Distributed audit report |
| Keep documented information as evidence of the program and the results | 9.2.2 | Program, plans, reports, findings log |
Source: harmonized structure core text for clause 9.2 in Annex SL of the ISO/IEC Directives, which ISO/IEC 42001:2023 applies. Paraphrased; the record column is AI Training Skool practice.
ISO/IEC 42001 also defines the term. An audit is a “systematic and independent process” for obtaining evidence and evaluating it objectively against audit criteria (definition 3.18). A note adds that an internal audit is first party and can be run by the organization itself or by an external party on its behalf. That note is what lets a small team bring in outside help without breaking the clause.
The Audit Program Record and What It Must Define
The audit program is one controlled record that answers five questions from clause 9.2.2: how often, by what method, who does what, how each audit is planned, and how results are reported. A calendar of dates alone is not a program.
Below is AI Training Skool’s program layout, filled in as an example for a fictional 200-person US SaaS company with four AI systems in scope.
| Program field | What it records | Example entry (fictional company) |
| Program objective | What the program must prove this cycle | Cover the full AIMS scope before the Stage 1 audit; retest every finding raised in the last cycle |
| Scope of the program | Clauses, Annex A controls and AI systems covered over the cycle | Clauses 4 to 10; all applied SoA controls; AI systems AIS-01 to AIS-04 |
| Audit areas and risk rating | Each area rated by importance and prior results | High: 6.1.2 to 6.1.4 and 8.2 to 8.4. Medium: 7.2, 9.1. Low: 7.4 |
| Frequency | How often each area is audited, and the trigger for an extra audit | High areas twice a year; others once a year; extra audit after a new AI system goes live |
| Methods | How evidence is gathered | Document review, interviews, record sampling, observation of a release; remote where systems allow |
| Responsibilities | Who manages the program, who audits, who approves | Program owner: risk manager. Auditors: two trained staff from finance and security, plus an external auditor for the risk area |
| Planning requirements | What each audit must have before fieldwork | Written plan with objectives, criteria, scope, sample and dates, sent to auditees 10 working days ahead |
| Reporting | Report format, recipients and deadline | Report within 5 working days to the AIMS owner and the head of each audited area; summary to management review |
| Records kept | Where evidence of the program and results lives | Audit folder in the document system; findings in the corrective action log |
| Program review | When the program itself is reviewed | After each management review, or when scope changes |
Source: AI Training Skool program layout, built on the 9.2.2 elements in the harmonized structure text. Example values are fictional.
Building an ISO 42001 Audit Checklist From Your Own Records
A usable ISO 42001 internal audit checklist is built from your own procedures and SoA, not copied from a generic list. Write one line per requirement you will test, the record you expect to see, the sample size and the finding route if the record is missing. A checklist that asks “Is there an AI policy? Yes or no” tests existence, not operation.
How Often to Run ISO 42001 Internal Audits
ISO/IEC 42001 sets no fixed audit frequency: clause 9.2.1 says “at planned intervals”, and 9.2.2 tells you to weigh the importance of the processes and the results of previous audits. “Once a year” is a common choice, not a requirement.
Set frequency by risk. Areas where AI risk lives, such as risk assessment, impact assessment and operational reassessment (6.1.2 to 6.1.4 and 8.2 to 8.4), deserve more attention than awareness or communication. An area with open findings gets audited again sooner. A significant change, such as a new AI system or a vendor model swap, can trigger an unscheduled audit.
Plan the first cycle so the whole AIMS scope has been audited before the certification body arrives. A certification auditor will look for evidence that the program is running and that results reached management. Fitting that first cycle around the rest of the project is part of the ISO 42001 build sequence and timeline.
Applying ISO 19011:2026 to an AI Management System
ISO 19011 is the guidance standard for auditing management systems. Its current edition, ISO 19011:2026 on iso.org, is the fourth, published on 27 May 2026; the 2018 edition is withdrawn. It covers the principles of auditing, managing an audit program and conducting individual audits, plus auditor competence. ISO/IEC 42001 points to ISO 19011 for the definitions of audit evidence and audit criteria (definition 3.18, note 3).
Use its structure as your method. The mapping below uses clause titles from the ISO 19011:2026 table of contents.
| What you do in the AIMS audit | ISO 19011:2026 clause | AI-specific point |
| Set program objectives and weigh program risks | 5.2, 5.3 | Rate AI systems by impact on people, not only by business value |
| Establish the program: roles, competence, scope, resources | 5.4 | At least one auditor must read a model release record or monitoring log |
| Define each audit’s objectives, scope and criteria; pick methods and team | 5.5.2 to 5.5.4 | Criteria include the SoA and the impact assessment procedure |
| Monitor, review and improve the program | 5.6, 5.7 | Add newly registered AI systems to the next cycle |
| Plan the audit and prepare work documents | 6.3.2, 6.3.4 | Pick the AI system you will trace end to end |
| Collect and verify information; generate findings | 6.4.7, 6.4.8 | Compare monitoring output with the thresholds in the risk register |
| Report, complete and follow up | 6.5 to 6.7 | Retest corrective actions on the same AI system |
Source: ISO 19011:2026 table of contents (preview). AI-specific column: AI Training Skool.
Two of the seven auditing principles in clause 4 of ISO 19011:2026 matter most here: independence (4.6) and the risk-based approach (4.8). The fourth edition also expands guidance on remote auditing methods and virtual locations, which suits AI systems that exist only in cloud consoles and repositories.
Auditor Objectivity and Impartiality in a Small AI Team
Clause 9.2.2 b) requires auditors to be selected so the audit is objective and impartial. In practice, nobody audits their own work: the person who wrote the risk method should not audit clause 6.1.2, and the model owner should not audit the model’s monitoring.
Small teams have four options:
- Cross-audit. Staff from finance, security or quality audit the AI processes, and the AI governance lead audits an area they did not build.
- Split by clause. The implementer audits clause 7 support processes they did not design, while someone else audits clauses 6 and 8.
- Bring in an external auditor. Definition 3.18, note 2 allows an internal audit to be conducted by an external party on the organization’s behalf. Many small companies buy in the high-risk areas only.
- Join an existing audit function. If you run internal audit for ISO/IEC 27001 or SOC 2, add AIMS criteria to that program.
Record the independence check on the assignment itself. Corporate internal audit, as the Institute of Internal Auditors frames it, also rests on independence, but an AIMS internal audit needs impartiality from the work audited, not a reporting line to the board. Where the implementer and auditor roles divide, and why the same person should not hold both on one process, is covered in the implementer and auditor split in ISO 42001. If you want to make auditing your job, the routes differ for internal auditor or certification body auditor for ISO 42001.
The Audit Plan for Each ISO 42001 Internal Audit
Every audit in the program needs its own plan stating objectives, criteria and scope, as clause 9.2.2 a) requires. One specific page is enough.
A plan for one audit should name:
- Objective. For example, confirm that AI risk assessment and impact assessment run in operation as planned (8.2, 8.4).
- Criteria. The clauses in play, the SoA controls marked applied, your risk and impact procedures, and any legal or contract requirement recorded under 4.2.
- Scope. Which AI systems, teams, sites and date range the sample covers.
- Sample. Which records you will pull, how many and how you chose them.
- Team and auditees. Names, with the independence check.
- Schedule. Opening meeting, interviews, record review, closing meeting.
For audit criteria, read what each ISO 42001 clause requires and turn each “shall” into a test question. Keep criteria tied to clause numbers so every finding can cite one.
Tracing One AI System End to End: The AI Audit Trail
The most useful test in an AIMS internal audit picks one AI system and follows it through every record that should exist, in order. A gap anywhere in the chain is a finding, and the chain shows whether the AIMS controls real AI systems or only describes them.
- Register entry (4.1, 4.3). The system is in the AI system register, with intended purpose, your AI role and an owner, and it sits inside the scope.
- Impact assessment (6.1.4, 8.4). A dated, approved impact assessment exists for the current version, and it was repeated after the last significant change.
- Risk assessment and treatment (6.1.2, 6.1.3, 8.2, 8.3). The risks for this system are in the register with owners, and each treatment names controls.
- SoA control (6.1.3, definition 3.26). Each control named in treatment appears as applied in the Statement of Applicability, with evidence location.
- Monitoring log (9.1). Monitoring output exists at the frequency you set, such as drift or error-rate checks against the thresholds in the risk register.
- Change record (6.3, 8.1). The last model, data or vendor change was approved, and it triggered the reassessments your procedure promises.
Example. At the fictional SaaS company, the auditor picks AIS-03, a support chatbot. The register entry and impact assessment are in order. The risk register lists prompt injection with a treatment of input filtering, and the SoA shows the matching control as applied. The monitoring log, though, stopped in July, and a vendor model upgrade in August has a change ticket but no reassessment. That is two findings from one trace, and neither would show up in a document review.
At step 4, an SoA exclusion that a live risk still points at is also a finding; see justifying included and excluded ISO 42001 controls for what a defensible row looks like. For the full set of records an external auditor pulls first, by clause, see the evidence pack an ISO 42001 auditor asks for first.
Grading Internal Audit Findings, With Examples
ISO/IEC 42001 defines a nonconformity as the non-fulfilment of a requirement (definition 3.16), but it does not set grades. Our program layout uses three, nonconformity, observation and opportunity for improvement, and flags any nonconformity that would likely be major at certification. Certification bodies split nonconformities further into major and minor, using ISO/IEC 17021-1, where a major nonconformity affects the capability of the management system to achieve its intended results and a minor one does not.
| Grade | Meaning in your program | Example (fictional company) | Route |
| Nonconformity | A requirement of ISO/IEC 42001 or your own AIMS is not met, with evidence | AIS-03 had a model upgrade in August with no impact reassessment, although the procedure requires one after significant change (8.4) | Corrective action log under 10.2 |
| Nonconformity (would likely be major at certification) | A requirement is missing altogether, or a gap repeats across the AIMS | No internal audit has covered clauses 6 and 8 in the cycle; or none of the four AI systems has a current impact assessment | Corrective action, escalated to top management |
| Observation | No requirement is broken yet, but the evidence shows a weakness that could become one | Monitoring for AIS-02 runs, but the threshold in the log differs from the one in the risk register | Owner reviews; retest next audit |
| Opportunity for improvement | Conforming, but could work better | Impact assessments are approved by email; a workflow tool would make approval dates easier to show | Optional; reported to management review |
Source: grades are common audit practice; definitions 3.16 and 3.17 from the ISO/IEC 42001:2023 official preview; major and minor nonconformity definitions paraphrased from ISO/IEC 17021-1:2015 (3.12, 3.13) as quoted by European Accreditation. Examples are fictional.
Write each nonconformity in three parts: the requirement, the evidence you saw and why it does not meet the requirement. “Monitoring is weak” is an opinion. “The AIS-03 monitoring log has no entries after 14 July; the procedure requires weekly checks” is a finding.
Reporting Results Into Management Review (9.3) and Corrective Action (10.2)
Clause 9.2.2 c) requires audit results to reach relevant managers, and two other clauses then use them. Audit results are a named input to management review in the harmonized structure text of clause 9.3.2, alongside trends in nonconformities and corrective actions. Every nonconformity enters clause 10.2.
The report states objectives, criteria, scope, the sample, findings by grade with evidence, and a conclusion on conformity and effectiveness. Send it to the owners of the audited processes and the AIMS owner, and keep the distribution record.
Under clause 10.2, the organization reacts to each nonconformity, finds its cause, checks whether similar ones exist or could occur, acts, and reviews whether the action worked. Corrective action, defined in 3.17, removes the cause, not only the symptom. Fixing the AIS-03 log is the correction; finding out why nobody noticed for six weeks is the corrective action. Root cause analysis techniques such as five whys and Ishikawa diagrams help, provided you check the cause against evidence. In plan-do-check-act terms, the internal audit is part of the check step, and management review and corrective action close the loop.
ISO 42001 Internal Audit vs Certification Audit
An internal audit is run by or for your organization to find and fix problems; a certification audit is run by an accredited certification body to decide whether to issue or keep a certificate. The internal audit is also one of the things the certification audit checks.
| Attribute | Internal audit (clause 9.2) | Certification audit |
| Party | First party: the organization, or an external party on its behalf | Third party: a certification body |
| Rules the auditor works to | ISO/IEC 42001 clause 9.2, your program, ISO 19011 guidance | ISO/IEC 17021-1 plus ISO/IEC 42006:2025 for AIMS |
| Who picks the auditors | Your program owner, for objectivity and impartiality | The certification body, against its competence criteria |
| Frequency | At planned intervals you set by risk | Stage 1 and Stage 2, then surveillance audits and recertification in a three-year cycle |
| Finding grades | Your choice, often nonconformity, observation and improvement opportunity | Major and minor nonconformities, plus observations or opportunities |
| Output | Report to relevant managers; inputs to 9.3 and 10.2 | Certification decision and report |
| Can it certify you? | No | Yes, within the agreed scope |
Source: ISO/IEC 42001:2023 official preview (definition 3.18); harmonized structure text for 9.2; ISO/IEC 42006:2025 catalogue entry on iso.org; ISO/IEC 17021-1:2015 definitions as reproduced above.
The full certification route, from choosing an accredited body to surveillance, is set out in ISO 42001 certification for organizations, end to end.
If your role also includes building parts of the AIMS that someone else will audit, ISO/IEC 42001 Lead Implementer training that covers internal audit and management review takes you through clauses 4 to 10 and Annex A, with templates and a case study workbook.
Frequently Asked Questions
Is an Internal Audit Mandatory for ISO 42001 Certification?
Yes. Clause 9.2 of ISO/IEC 42001:2023 requires internal audits at planned intervals, and clause 9.2.2 requires documented information as evidence of the audit program and its results. A certification body will expect to see a running program, completed audit reports and evidence that results reached management before it recommends certification.
How Often Should ISO 42001 Internal Audits Be Conducted?
ISO/IEC 42001 clause 9.2.1 says internal audits happen “at planned intervals” and sets no fixed frequency. Clause 9.2.2 asks you to weigh the importance of each process and previous audit results. Many organizations audit the full scope once a year and audit high-risk areas, such as AI risk and impact assessment, more often.
Who Can Perform an ISO 42001 Internal Audit?
Anyone competent and impartial toward the work being audited. Clause 9.2.2 requires auditors to be selected for objectivity and impartiality, so people should not audit their own processes. Definition 3.18 of ISO/IEC 42001:2023 notes that an external party can conduct the internal audit on the organization’s behalf, which helps small teams.
What Is the Difference Between Clause 9.2.1 and 9.2.2 in ISO 42001?
In ISO/IEC 42001:2023, clause 9.2.1 (General) sets the purpose: audit at planned intervals to check conformity and effective implementation of the AIMS. Clause 9.2.2 (Internal audit programme) sets the method: a program with frequency, methods, responsibilities, planning requirements and reporting, plus objectives, criteria and scope for each audit.
Which Standard Gives Guidance on How to Audit an AI Management System?
ISO 19011:2026, Guidelines for auditing management systems, published in May 2026 as the fourth edition, gives the general method: audit principles, audit program management, conducting audits and auditor competence. ISO/IEC 42006:2025 adds requirements for certification bodies auditing AI management systems, not for internal auditors.
What Happens to Findings From an ISO 42001 Internal Audit?
Findings are reported to the relevant managers under clause 9.2.2 and become inputs to management review under clause 9.3. Each nonconformity enters clause 10.2: react and correct, find the cause, check for similar cases, act, and review whether the action worked, keeping documented information of each step.
