ISO 42001 internal audit: how to plan and run an audit of your AI management system

What does ISO 42001 clause 9.2 require?

ISO/IEC 42001 follows the harmonised structure, so its internal audit clause carries the core obligations known from ISO 9001 or ISO/IEC 27001: at planned intervals, establish whether the AIMS conforms to your own requirements and to the standard, and whether it is effectively implemented and maintained.

• A programme, not a one-off. You plan and maintain an audit programme that sets frequency, methods, responsibilities, planning requirements and reporting, weighted by the importance of the processes and by what earlier audits found.
• Defined audits. Each audit has its own objectives, criteria and scope.
• Objectivity and impartiality. Auditors are chosen, and audits run, so that nobody marks their own homework.
• Reporting and evidence. Results reach the relevant managers, and documented information is available as evidence of the programme and its results.

Findings move into corrective action under clause 10.2, and results feed the management review in clause 9.3; the ISO/IEC 42001 management review guide covers that meeting. The certification body looks at this early: its Stage 1 readiness review checks that internal audits and management reviews are planned and performed, and Stage 2 examines how well they work.

How auditing an AIMS differs from other internal audits

The clause is familiar; the audit criteria are not. Beyond clauses 4 to 10, an AIMS audit tests your AI policy, your risk criteria, the controls chosen in the Statement of Applicability and the justifications for leaving any out.

The chain of documents must agree

Each AI system in the inventory should have an impact assessment covering intended use and foreseeable misuse; its results should feed the AI risk assessment; treatments should map to controls in the Statement of Applicability; and designated management should have approved the treatment plan and residual risk. Following one system along that chain finds more than reading each document separately.

The system keeps changing

Clauses 8.2 and 8.4 require the risk and impact assessments to be repeated at planned intervals or on significant change. Retraining, a new data source or a vendor's model update are candidates, so the audit asks what changed and whether anyone reassessed it.

Much of the AI is not yours

Where a model comes from a third party, the Annex A controls on suppliers and allocating responsibilities apply; the audit checks what the contract and supplier documentation actually give you.

Nor is the internal audit a rehearsal of the external one. Your programme can go deeper than the certification body's sample, while there is still time to fix what it finds.

An AIMS audit programme over twelve months

With a handful of AI systems in scope, one full cycle a year with the higher-impact systems visited twice works well. Choose systems by the consequences their impact assessments identified, not by which team is easiest to schedule.

Before initial certification, compress the cycle so every clause and applicable control is audited, and findings acted on, before Stage 1. Add audits after a significant change or an AI incident.

Conducting the audit with ISO 19011:2026

ISO 19011, Guidelines for auditing management systems, supplies the method. Its fourth edition, ISO 19011:2026, published in May 2026, replaced the 2018 text and expands the guidance on remote auditing and digital tools, useful for an AIMS whose evidence sits in repositories, model registries and monitoring dashboards.

Prepare, interview and trace

Send the plan to the system owner in advance; read the system's impact assessment, its risk entries, the Statement of Applicability and the last report. Then talk to the people who build, deploy and monitor the system, not only the AIMS lead: how is a model change approved, who judged the new data source fit for use, what alert fires when performance drifts? Choose the sample yourself and follow one change from request to post-release monitoring.

Write the finding

A finding states the requirement, evidence someone else could verify and the gap. An illustrative example:

• Requirement: clause 8.4 requires the AI system impact assessment to be repeated when significant changes occur.
• Evidence: the customer-scoring model was retrained in the second quarter on a newly acquired data set covering a new region; the only impact assessment on file predates that release.
• Gap: a significant change was deployed without the impact assessment being repeated.

Reporting, grading and the audit record

ISO/IEC 42001 sets no grading scheme for internal findings, so define one in your procedure, ideally in the certification body's terms: major, minor and opportunity for improvement. The ISO/IEC 42001 nonconformities guide explains how those grades are applied.

Issue the report promptly to the system owner and top management: objectives, scope, criteria, auditors, what was sampled, each finding with evidence, and a conclusion on conformity and effectiveness. Closure needs more than an updated document; the auditor later confirms the corrective action worked, for instance that every release since carries a dated reassessment.

The record auditors ask for is the programme, plans, reports, findings and their closure, and auditor competence evidence. In Effivity, a master schedule and audit plans set who audits what and when, and nonconformities pass to corrective action with reminders when actions run late. Effivity, used in 50+ countries, is included with the engagement, at no additional cost.

Who should audit: competence and independence

ISO/IEC 42001 names no internal auditor qualification. Auditors fall under the competence requirements of clause 7: competence determined for the role, based on education, training or experience, and retained as documented information. ISO 19011 adds guidance on what auditor competence includes and how to evaluate it.

For an AIMS, competence has two halves: management system audit skill, and enough AI life-cycle understanding to judge whether a validation report, provenance record or event log shows what it claims. Many organisations pair a trained auditor with a technical colleague from another team. Independence follows the same logic: a data scientist does not audit the model they trained, and someone other than the AIMS lead audits the programme and the risk process. The ISO/IEC 42001 training guide covers who needs what.

Where AIMS internal audits go wrong

• Reading documents, not systems. Checking the policy and risk register without opening a release record or event log tests nothing that operates.
• Ignoring excluded controls. Every exclusion in the Statement of Applicability needs a justification that still holds; a vendor switch or a new use can remove it.
• Sampling only the easy system. Auditing the internal chatbot while the model used in decisions about people goes unexamined inverts the risk-based approach.
• Leaving it too late. An audit in the week before Stage 1 finds gaps nobody can close in time; the ISO/IEC 42001 common mistakes guide covers the wider list.

ISO 42001 internal audit: questions buyers ask