According to a February 2026 Gartner press release, organisations that deploy AI governance platforms are 3.4 times more likely to achieve high effectiveness in AI governance than those without one yet $492 million in platform spending is projected for 2026 alone, which tells you how many organisations are still catching up. The audit is no longer a theoretical future event. ISO 42001 certification programmes are active. EU AI Act obligations are in force for providers and deployers in scope. Boards and regulators are requesting evidence.
This checklist covers 38 specific pre-audit checks, organised by control domain, with framework attribution and evidence type for each item. Whether you are preparing for an ISO/IEC 42001:2023 Stage 1 or Stage 2 audit, an internal AI governance review, or a board-requested readiness assessment, this is the structure your team needs.
Why AI Governance Audits Fail and What Auditors Actually Look For
The single most common cause of audit non-conformities is not a missing control it is a control that exists but cannot be evidenced. An auditor reviewing an AI management system (AIMS) under ISO 42001 is not evaluating your intentions. They are evaluating documented evidence that your intentions are implemented, monitored, and maintained.
ISO 42001 certification audits proceed in two distinct phases. Stage 1 is a document review: the auditor assesses whether your documented system is designed to meet the standard’s requirements. Stage 2 is an implementation audit: the auditor checks whether your implemented system matches your documentation. Most organisations that fail Stage 1 have documentation gaps. Most that fail Stage 2 have implementation gaps the policy exists, but the evidence of its execution does not.
| The 5 most common AI governance audit non-conformities: 1. Scope too narrow AI systems in use are not captured in the defined AIMS scope 2. Risk assessments that identify risks but do not document treatment decisions or residual risk acceptance 3. Competency records missing or generic training logs that do not link to specific AI roles or responsibilities 4. Third-party AI systems outside the scope of supplier assessment processes5. Internal audit programme exists on paper but has not been executed no internal audit report available |
The EU AI Act adds a further layer. For high-risk AI systems under Annex III of the regulation, operators must maintain technical documentation covering the system’s intended purpose, design logic, data governance, human oversight measures, and performance monitoring. This documentation must be available for inspection by national competent authorities a different evidentiary standard from ISO 42001, but one with significant overlap.
The NIST AI RMF, while voluntary in the US, provides the most operationally detailed framework for what “good” AI risk management looks like at the control level. Its GOVERN, MAP, MEASURE, and MANAGE functions map closely to ISO 42001’s Plan-Do-Check-Act structure, and organisations that have implemented NIST AI RMF controls find ISO 42001 audit preparation significantly more tractable.
The 38 checks below are organised into seven domains. Each item includes the primary framework clause or article it addresses and the evidence type an auditor would expect to see.
Section 1 – Scope, Context and AI System Inventory (Checks 1–7)
Every AI governance audit begins with scope. If a system is not in scope, it will not be audited but it also will not be governed. Organisations regularly discover, mid-audit, that vendor-provided AI features embedded in enterprise software were never registered, scoped, or risk-assessed. Auditors look for this.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 1 | AI system inventory is complete: all AI systems, tools, agents, and embedded vendor AI in production are catalogued | ISO 42001 Cl. 4.3 | EU AI Act Art. 6 | NIST AI RMF GOVERN 1.1 | AI model registry / system inventory document with system name, owner, purpose, and risk classification |
| 2 | AIMS scope statement is documented: defines which organisational units, systems, and AI activities are in scope | ISO 42001 Cl. 4.3 | Scope document, approved by top management |
| 3 | Each AI system has a designated owner or accountable role | ISO 42001 Cl. 5.3 | EU AI Act Art. 25 | Roles and responsibilities matrix or RACI linked to each system in the inventory |
| 4 | External context has been assessed: regulatory environment, stakeholder expectations, and AI-specific risks in your operating context are documented | ISO 42001 Cl. 4.1–4.2 | Context analysis document or PESTLE/stakeholder assessment with AI governance lens |
| 5 | High-risk AI systems under EU AI Act Annex III have been identified and flagged in the inventory | EU AI Act Art. 6, Annex III | Annotated inventory with risk classification column; high-risk systems marked |
| 6 | AI systems developed by third parties and deployed by your organisation are included in scope | ISO 42001 Cl. 8.4 | EU AI Act Art. 25 | Inventory entries for vendor AI; supplier assessment records |
| 7 | Scope changes are controlled: a process exists to add new AI systems to the registry as they are deployed | ISO 42001 Cl. 8.1 | NIST AI RMF GOVERN 5.1 | Change management procedure or AI intake process documentation |
On Check 1: “AI system” under ISO 42001 is broader than most teams initially assume. It includes AI components embedded in SaaS tools your teams use daily – CRM lead-scoring models, HR screening tools, financial forecasting modules. If your organisation uses these systems to make or inform material decisions, they belong in scope.
Section 2 – AI Policy, Objectives and Leadership Accountability (Checks 8–14)
ISO 42001 Clause 5 is the leadership and commitment domain. Auditors want to see that top management has actively shaped the AIMS, not delegated it entirely to the compliance team. The AI policy must bear visible leadership ownership and the objectives flowing from it must be measurable, not aspirational.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 8 | An AI policy exists, is documented, and has been approved by top management | ISO 42001 Cl. 5.2 | Signed AI policy document with version control and approval date |
| 9 | The AI policy covers the organisation’s commitments to responsible AI, applicable regulations, and continual improvement of the AIMS | ISO 42001 Cl. 5.2 | EU AI Act Art. 4 | Policy content — auditors check coverage, not just existence |
| 10 | AI objectives have been established, are measurable, and are linked to the AI policy commitments | ISO 42001 Cl. 6.2 | AI objectives register with KPIs, measurement methods, and owners |
| 11 | Top management demonstrates commitment evidence that leadership reviews AI governance performance, not just delegates it | ISO 42001 Cl. 5.1 | Management review minutes, board AI risk reports, leadership communications on AI governance |
| 12 | Roles, responsibilities, and authorities for AI governance are formally assigned and communicated | ISO 42001 Cl. 5.3 | EU AI Act Art. 25 | Organisational chart with AI governance roles; job descriptions or TORs for AI governance function |
| 13 | An AI governance function or equivalent exists with the authority and resources to perform its mandate | ISO 42001 Cl. 5.1 | EU AI Act Art. 4 | Budget allocation records, headcount or FTE evidence, governance committee terms of reference |
| 14 | Communication of the AI policy and objectives to relevant internal stakeholders is documented | ISO 42001 Cl. 7.4 | Communication records email distribution, intranet publication, training completion logs |
On Check 11: Auditors look for management review minutes that show genuine engagement with AI governance data not a rubber-stamp approval of a report that was never discussed. Minutes should record what was reviewed, decisions made, and actions assigned.
Section 3 – Risk Assessment and Treatment Records (Checks 15–21)
Risk assessment is the operational heart of ISO 42001. Clause 6.1 requires a systematic process for identifying, analysing, and treating AI-related risks and the evidence of that process is what Stage 2 auditors scrutinise most carefully. A risk register that lists risks without documenting treatment decisions, residual risk acceptance, or review dates will generate non-conformities.
The EU AI Act’s Article 9 risk management requirements align closely with ISO 42001 Clause 6.1 for high-risk systems, but add additional specificity: the risk management system must be continuous and iterative, updated throughout the AI system’s lifecycle, and documented in technical files accessible to competent authorities.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 15 | An AI risk assessment methodology is documented criteria for risk identification, analysis, and evaluation are defined | ISO 42001 Cl. 6.1.2 | NIST AI RMF MAP 1.5 | Risk assessment methodology document or procedure |
| 16 | Risk assessments have been conducted for all in-scope AI systems | ISO 42001 Cl. 6.1.2 | EU AI Act Art. 9 | Completed risk assessment records, one per system or system category |
| 17 | Risks include AI-specific dimensions: bias, explainability, data quality, model drift, and adverse societal impacts | ISO 42001 Cl. 6.1.2 | NIST AI RMF MAP 5.1 | Risk register entries covering these specific risk categories |
| 18 | Risk treatment decisions are documented for each identified risk, the treatment option (accept, mitigate, transfer, avoid) is recorded with rationale | ISO 42001 Cl. 6.1.3 | Risk treatment plan linked to the risk register |
| 19 | Residual risk acceptance is documented and approved at the appropriate organisational level | ISO 42001 Cl. 6.1.3 | EU AI Act Art. 9 | Risk acceptance records with approver name, role, and date |
| 20 | Impact assessments have been completed for high-risk AI systems covering fundamental rights and safety impacts | EU AI Act Art. 9, Annex IV | NIST AI RMF MAP 5.2 | Fundamental rights impact assessment or AI impact assessment document |
| 21 | Risk assessments are reviewed and updated when AI systems change materially or on a defined periodic schedule | ISO 42001 Cl. 6.1.2 | EU AI Act Art. 9(2) | Review schedule in the risk register; evidence of periodic reviews with dates |
Section 4 – Operational Controls, Monitoring, and Human Oversight (Checks 22–28)
Clause 8 of ISO 42001 covers the operational execution of your AI management system. This is where plans become practice and where Stage 2 auditors spend significant time. Human oversight, in particular, is a concept that appears across both ISO 42001 and the EU AI Act, but the evidence requirements differ.
Under EU AI Act Article 14, high-risk AI systems must have human oversight measures that enable the individuals responsible to effectively oversee the system’s operation, intervene when necessary, and override or suspend the system if required. For ISO 42001, Clause 8.3 requires controls that ensure humans retain meaningful involvement in AI-driven decisions. Both requirements demand documented procedures and evidence that the procedures are followed.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 22 | Documented procedures exist for each stage of the AI system lifecycle: development/procurement, testing, deployment, monitoring, and decommissioning | ISO 42001 Cl. 8.1–8.6 | NIST AI RMF MANAGE 1.1 | Lifecycle procedures or standard operating procedures (SOPs) per stage |
| 23 | AI system logging is active systems generate logs of inputs, outputs, and key decision points sufficient for audit trail purposes | ISO 42001 Cl. 8.5 | EU AI Act Art. 12 | System logging configuration records; sample log extracts |
| 24 | Human oversight controls are implemented and documented for AI systems making or influencing material decisions | ISO 42001 Cl. 8.3 | EU AI Act Art. 14 | Human oversight procedures; evidence of human review in decision workflows |
| 25 | Monitoring procedures are in place to detect model drift, performance degradation, and unexpected outputs | ISO 42001 Cl. 8.5 | NIST AI RMF MEASURE 2.5 | Monitoring schedule or dashboard; alert thresholds and escalation procedures |
| 26 | Access controls for AI systems are documented and enforced who can modify models, access training data, or alter system parameters | ISO 42001 Cl. 8.1 | NIST AI RMF GOVERN 6.1 | Access control policy; system access logs; privileged access review records |
| 27 | An incident response procedure covers AI-specific incidents: unexpected model outputs, bias events, system failures, and misuse | ISO 42001 Cl. 10.1 | EU AI Act Art. 73 | AI incident response procedure; incident log (even if no incidents have occurred the log must exist) |
| 28 | Transparency and explainability measures are documented for AI systems where users or affected parties require an explanation of decisions | ISO 42001 Cl. 8.2 | EU AI Act Art. 13 | Explainability methodology; user-facing documentation or notice; sample explanations |
On Check 27: A clean incident log is not the same as an empty incident log. Auditors want to see the log exists, is actively maintained, and has a defined review cadence. An organisation with no AI incidents should still have an incident log with zero entries not a log that has never been created.
Section 5 – People, Training and Competency Records (Checks 29–32)
ISO 42001 Clause 7 is about people not headcount, but competence. Auditors assess whether the individuals performing AI governance roles have the knowledge and skills those roles require, and whether your organisation can prove it. Generic “AI awareness training” completed by everyone is not the same as role-specific competency documented for the people who actually own AI risk decisions.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 29 | Competency requirements for AI governance roles are defined knowledge and skills required for each role are documented | ISO 42001 Cl. 7.2 | Competency framework or role profiles with AI governance competency requirements |
| 30 | Competency evidence exists for individuals in AI governance roles qualifications, experience records, or training completion linked to defined requirements | ISO 42001 Cl. 7.2 | Training completion records; qualification certificates; experience logs linked to role requirements |
| 31 | AI awareness training has been completed by personnel whose work affects AI governance not just the governance team | ISO 42001 Cl. 7.3 | EU AI Act Art. 4 | Training records with completion dates, participant lists, and content summaries |
| 32 | Gaps between required and demonstrated competency are identified and addressed a plan exists to close competency gaps | ISO 42001 Cl. 7.2 | Gap analysis records; training plans with completion targets and accountability |
EU AI Act Article 4 introduced a specific obligation for AI literacy: providers and deployers must ensure their staff have sufficient AI literacy to perform their roles responsibly. This is intentionally broad it covers not just governance professionals but also the product managers, data scientists, and business unit leaders who interact with AI systems. Competency records should reflect this wider population.
Section 6 – Third-Party and Vendor AI Governance (Checks 33–35)
Third-party AI risk is the blind spot in most organisations’ AI governance programmes. Most teams govern the AI systems they built. Fewer govern the AI systems they bought. ISO 42001 Clause 8.4 requires that externally provided AI systems and services that are within scope of your AIMS are subject to appropriate controls which means supplier assessment, contractual controls, and ongoing oversight.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 33 | Third-party AI systems in scope have been assessed for governance, security, and compliance characteristics before deployment | ISO 42001 Cl. 8.4 | EU AI Act Art. 13, 25 | Supplier AI assessment questionnaire or evaluation records; procurement due diligence documentation |
| 34 | Contracts with AI vendors include provisions for transparency, data use, audit rights, and incident notification | ISO 42001 Cl. 8.4 | EU AI Act Art. 25 | Reviewed contract clauses covering AI-specific obligations; if absent, a remediation plan |
| 35 | Ongoing monitoring of third-party AI systems is in place not a one-time assessment at procurement | ISO 42001 Cl. 8.4 | NIST AI RMF MANAGE 3.2 | Vendor review schedule; periodic reassessment records; monitoring evidence |
One thing that consistently separates organisations that pass their first audit from those that don’t is the depth of their vendor AI documentation. Many organisations have excellent internal controls and weak supplier governance. Auditors find this gap consistently and it generates major non-conformities, not minor ones.
Section 7 – Internal Audit, Management Review, and Continual Improvement (Checks 36–38)
The final three checks address the system’s self-evaluation mechanisms. ISO 42001 Clauses 9 and 10 require that your AI management system monitors its own effectiveness, reviews its performance at the leadership level, and has a structured process for improving when deficiencies are identified. An AIMS without evidence of internal audit and management review is not a functioning management system it is a set of policies.
| # | Check | Framework Reference | Evidence Required |
|---|---|---|---|
| 36 | An internal audit programme has been established and executed at least one complete internal audit cycle is documented | ISO 42001 Cl. 9.2 | Internal audit programme; internal audit report with findings, conclusions, and corrective actions |
| 37 | Management review of the AIMS has been conducted by top management, covering performance data, risk landscape, and improvement opportunities | ISO 42001 Cl. 9.3 | Management review meeting minutes with agenda items, decisions made, and assigned actions |
| 38 | Corrective actions from internal audits, non-conformities, or management review decisions are tracked and closed a corrective action register exists | ISO 42001 Cl. 10.1–10.3 | Corrective action register with root cause analysis, actions taken, and closure evidence |
Govern365.ai’s compliance dashboard provides real-time visibility into which of these 38 checks have documented evidence and which remain open, making it straightforward to assign owners, track progress, and generate a pre-audit readiness report for leadership review.
One of the most important audit checks is confirming that every AI system has been evaluated using a documented AI risk assessment template with approved mitigation actions.
Cross-Framework Control Mapping – ISO 42001 × EU AI Act × NIST AI RMF
Most AI governance teams operate across multiple frameworks simultaneously. The table below maps 14 core control domains to the specific clause, article, or function each framework addresses. Where all three frameworks converge on a control area, that control is non-negotiable regardless of your primary compliance objective.
| Control Domain | ISO/IEC 42001:2023 | EU AI Act (2024/1689) | NIST AI RMF 1.0 |
|---|---|---|---|
| Scope & AI System Inventory | Clause 4.3 – Determining the scope of the AIMS | Art. 6 – Classification of AI systems; Annex III (high-risk) | GOVERN 1.1 – Policies and processes for scope definition |
| AI Policy & Leadership Commitment | Clause 5.1–5.2 – Leadership and AI policy | Art. 4 – AI literacy obligations for providers/deployers | GOVERN 1.4 – Organisational teams are committed to policies |
| Risk Assessment | Clause 6.1 – Risks and opportunities | Art. 9 – Risk management system for high-risk AI | MAP 1.5, MEASURE 2.2 – Risk identification and measurement |
| AI Objectives & Planning | Clause 6.2 – AI objectives and planning | Art. 9(6) – Risk management iterative throughout lifecycle | GOVERN 5.1 – Policies for risk tolerance and objectives |
| Human Oversight | Clause 8.3 – AI system controls | Art. 14 – Human oversight for high-risk AI systems | MANAGE 2.4 – Mechanisms to respond to and recover from AI risks |
| Transparency & Explainability | Clause 8.2 – Transparency in AI systems | Art. 13 – Transparency and provision of information | MEASURE 2.6 – Fairness and bias evaluation; GOVERN 6.2 |
| Data Governance | Clause 8.4 (in part) – Supply chain; training data | Art. 10 – Data and data governance for high-risk AI | MAP 3.5 – Practices for AI data management |
| Monitoring & Logging | Clause 8.5 – Monitoring of AI systems | Art. 12 – Record-keeping for high-risk AI systems | MEASURE 2.5 – AI system performance monitoring |
| Incident Response | Clause 10.1 – Non-conformity and corrective action | Art. 73 – Reporting of serious incidents | MANAGE 3.1 – Responses to AI risks and impacts |
| Supplier / Third-Party Governance | Clause 8.4 – Externally provided processes | Art. 25 – Obligations of deployers of high-risk AI | GOVERN 6.2 – Policies for supply chain risk |
| Competency & AI Literacy | Clause 7.2-7.3 – Competence and awareness | Art. 4 – AI literacy for providers and deployers | GOVERN 4.1 – Policies for AI workforce skills |
| Internal Audit | Clause 9.2 – Internal audit | Not explicit; implied by ongoing compliance obligations | MEASURE 4.1 – Feedback processes for continual improvement |
| Management Review | Clause 9.3 – Management review | Not explicit; implied by governance obligations for operators | GOVERN 1.7 – Processes reviewed and updated by leadership |
| Corrective Action & Improvement | Clause 10.1-10.3 – Nonconformity and continual improvement | Art. 9 – Iterative risk management; Art. 72 – Post-market monitoring | MANAGE 4.1 – Processes to prevent risks from re-emerging |
Where frameworks overlap, a single evidence artefact can satisfy multiple requirements. A robust AI risk register that documents risk identification, treatment, and residual risk acceptance will address ISO 42001 Clause 6.1, EU AI Act Article 9, and NIST AI RMF MAP functions simultaneously reducing total documentation burden when designed correctly.
For organisations building this cross-framework evidence set from scratch, Govern365.ai’s control mapping module automatically links each registered AI system to its applicable clauses across all three frameworks, generating a live compliance gap analysis without manual cross-referencing.
Your audit should also verify that third-party AI providers have been evaluated using an AI vendor risk assessment questionnaire covering security, compliance, governance, and contractual obligations.
Frequently Asked Questions
What is the difference between a Stage 1 and Stage 2 ISO 42001 audit?
Stage 1 is a documentation review conducted off-site or briefly on-site. The auditor assesses whether your AIMS documentation is designed to meet ISO 42001’s requirements. Stage 2 is an on-site implementation audit: the auditor verifies that your documented system is actually operational and that evidence of implementation exists. Organisations should complete a full internal audit cycle before proceeding to Stage 2.
What evidence do AI auditors most commonly request?
Auditors consistently request: the AI system inventory (scope evidence), the risk register and risk treatment plan (Clause 6.1 evidence), internal audit report (Clause 9.2), management review minutes (Clause 9.3), competency and training records (Clause 7.2), and incident logs (Clause 10.1). For high-risk AI systems under the EU AI Act, technical documentation and fundamental rights impact assessments are additionally required.
How long does ISO 42001 certification typically take?
Preparation timelines vary by organisational complexity, but organisations with structured AI governance tooling complete certification preparation in significantly less time than those working manually. The audit itself typically spans one to three days for Stage 2, depending on the number of AI systems in scope. Plan for at least six months of preparation if starting from a low governance maturity baseline.
Do we need ISO 42001 certification to comply with the EU AI Act?
ISO 42001 certification is not a legal requirement under the EU AI Act. However, pursuing ISO 42001 builds the governance infrastructure that EU AI Act compliance requires for high-risk AI systems risk management systems, technical documentation, human oversight controls. Many organisations pursue both simultaneously because the control overlap is substantial.
What happens if we receive a non-conformity during an AI governance audit?
Non-conformities are classified as major (fundamental failure of a clause requirement) or minor (partial implementation or isolated lapse). A major non-conformity must be resolved before certification is granted. A minor non-conformity requires a corrective action plan with an agreed resolution timeline. Most Stage 2 audits produce at least a few minor non-conformities the goal of pre-audit preparation is to eliminate major ones entirely.
Can we use a generic GRC tool for AI governance audit preparation?
Generic GRC tools can capture AI governance data, but they lack the AI-specific control frameworks, risk taxonomies, and evidence structures that AI audits require. Auditors reviewing an AI management system want to see ISO 42001 clause attribution, EU AI Act Article references, and AI-specific risk categories not generic compliance records repurposed from information security programmes.
How often should we conduct an internal AI governance audit?
ISO 42001 Clause 9.2 requires a planned internal audit programme without specifying frequency. Most organisations conduct a full internal audit cycle annually, with targeted reviews of high-risk AI systems on a more frequent basis. The programme schedule should be documented and approved by management an unscheduled internal audit conducted reactively is not equivalent to a planned programme.
What does “AI literacy” mean under EU AI Act Article 4?
Article 4 requires that providers and deployers of AI systems take measures to ensure their staff have sufficient AI literacy to perform their roles. The regulation does not prescribe specific training content, but it requires that literacy measures are proportionate to the technical knowledge, experience, education, and context of the role. Documentation of training content, completion, and the reasoning behind the proportionality assessment is the expected evidence.
Where to Start
Audit readiness is not a sprint undertaken the week before an auditor arrives. The 38 checks above represent evidence that accumulates over time: a risk assessment conducted six months ago, a management review that happened last quarter, an internal audit programme that has been running for a year. Organisations that treat these checks as operational standards rather than pre-audit scrambles pass their first certification audit with significantly fewer non-conformities.
Start with the AI system inventory. Everything else in this checklist depends on knowing what is in scope. If your inventory is incomplete, every downstream check is incomplete by definition.
Govern365.ai, by the Global AI Certification Council, provides the purpose-built platform to run this entire checklist inventory, risk assessment, control mapping, evidence vault, and internal audit tracking in a single governance environment. Start your 14-day free trial and see your current readiness score within the first session.
