Gartner’s February 2026 forecast puts global spending on AI governance platforms at $492 million this year alone, driven by regulations expanding to cover 75% of the world’s economies. That figure reflects a hard truth most compliance teams have already absorbed: AI governance is no longer self-certifying. Auditors want proof, not policy PDFs.
The gap between having governance processes and being able to demonstrate them to an auditor’s satisfaction is where certifications stall, findings multiply, and remediation cycles drag on. This checklist maps the specific evidence artifacts required under ISO/IEC 42001:2023, the EU AI Act (Articles 9, 12, and 17), and the NIST AI RMF with a cross-framework table that shows where one document satisfies multiple standards at once.
What AI Audit Evidence Is and What It Isn’t
The ISO 42001 standard uses the term “documented information” rather than “documents,” and the distinction is deliberate. Documented information covers two categories: documents (policies, procedures, guidelines) that define what your organisation intends to do, and records (evidence of activities performed) that prove it actually happened. An AI audit is primarily interested in the second category.
This matters because a well-written AI ethics policy is not audit evidence. Neither is a governance framework deck presented to the board. Evidence is the artifact that links a stated control to a demonstrated action a risk assessment completed for a specific AI system, timestamped and version-controlled; training records tied to named individuals and dated competency reviews; management review minutes that reference specific AI performance metrics.
Where AI audit evidence differs from standard IT audit evidence is scope. IT auditors have established patterns for evaluating access controls, change management logs, and system availability. AI governance auditors are assessing something structurally different: the processes by which an organisation identifies, evaluates, and controls AI-specific risks across a system’s lifecycle. That includes decisions made before deployment (model selection, training data governance, impact assessment), during operation (human oversight mechanisms, monitoring metrics), and after incidents (corrective actions, root cause analysis). A single AI system may generate evidence artifacts touching six or seven different standard clauses.
The practical implication: evidence collection for AI audits should start at design time, not three months before the certification date.
ISO 42001 Clause-by-Clause Evidence Requirements
ISO/IEC 42001:2023 specifies both mandatory evidence (records the standard requires explicitly) and expected evidence (artifacts that auditors have come to look for, even where the standard does not prescribe their exact form). The table below covers the core clauses.
| Clause | Evidence Artifact | Required | Auditor Focus |
| Clause 4.1–4.3 | Context register; AIMS scope statement; issues log | Mandatory | Is scope exclusion justified? |
| Clause 6.1.2 | AI risk assessment records (per system, dated, version-controlled) | Mandatory | Continuous? Covers full lifecycle? |
| Clause 6.1.4 | AI impact assessment (societal, fairness, rights) | Mandatory | Separate from risk assessment? |
| Clause 7.2 | Competence records; role-linked training logs | Mandatory | Role-specific, not generic? |
| Clause 8.2 | AI system risk treatment plans; deployment approvals | Expected | Linked to Clause 6 risk assessment? |
| Clause 9.1 | AIMS performance metrics; monitoring dashboards | Expected | Includes AI-specific KPIs? |
| Clause 9.2 | Internal audit report; findings log | Mandatory | Completed before Stage 2? |
| Clause 9.3 | Management review minutes (with AI metrics) | Mandatory | References AI performance data? |
| Clause 10.2 | Nonconformity records; corrective action evidence | Mandatory | Includes resolution verification? |
| Annex A (A.6.2) | AI system inventory | Expected (critical) | Current? Includes third-party AI? |
Clause 6.1.2 – AI Risk Assessment
This is the most scrutinised evidence artifact in a Stage 2 audit. The standard requires a documented process for identifying risks, evaluating them against defined criteria, and recording the results. What auditors look for in practice: risk assessments conducted per AI system (not a single organisational-level assessment covering all systems), with risk scores, treatment decisions, and residual risk sign-off. Undated risk assessments, or those conducted before the AI system was finalised, trigger findings.
Clause 6.1.4 – AI Impact Assessment
Often confused with risk assessment, the AI impact assessment specifically addresses broader societal impacts fairness, transparency, human rights implications rather than organisational risk. ISO 42001 Annex A control A.6.2 maps directly to impact assessment procedures. Many organisations prepare one assessment document but fail to address both dimensions separately; auditors have started flagging this as a gap.
Clause 7.2 – Competence Records
Training logs, certification records, and role-based competency matrices must be maintained. Generic “AI awareness training” completion certificates are insufficient if the staff member’s role requires substantive AI governance responsibility. Auditors want to see that training content was specific to the responsibilities assigned.
Clause 9.2 – Internal Audit
Completing at least one full internal audit cycle before the certification audit is a practical requirement. Auditors want to see that the organisation can identify and respond to its own findings. An internal audit report with zero findings from a newly implemented AIMS is almost always treated as a red flag rather than a positive signal.
Clause 10.2 – Nonconformity and Corrective Action
If the internal audit produced findings, the evidence trail must show how each was addressed: root cause analysis, corrective action taken, verification that the action was effective. The absence of nonconformity records in an operational AIMS suggests either that the internal audit was not rigorous, or that findings were not documented both concerns for a certification auditor.
EU AI Act Evidence Requirements for High-Risk Systems
The EU AI Act establishes its most demanding evidence obligations for high-risk AI systems, defined primarily by their application domain under Annex III. For organisations developing or deploying systems in areas such as biometric identification, employment screening, credit scoring, or critical infrastructure management, three articles drive the majority of audit evidence requirements.
Article 9 – Risk Management System
Unlike ISO 42001’s risk assessment record (a point-in-time document), Article 9 requires evidence of a continuous risk management system. The documentation must show that risk identification, analysis, estimation, evaluation, and mitigation are ongoing throughout the system’s lifecycle not a single pre-deployment exercise. Evidence should include version-dated iterations of risk analysis as the system evolves, records of testing under normal and reasonably foreseeable misuse conditions, and documentation of how new risks identified post-deployment were addressed.
Article 12 – Logging Requirements
High-risk AI systems must be capable of automatically logging events. Audit evidence here is the logging architecture itself (demonstrating capability) plus sample log outputs confirming the system captures the required data operation period, reference database used, input data identification where applicable, and human oversight actions. Organisations sometimes prepare logging policies without demonstrating that actual logs are being generated; auditors verify both.
Article 17 – Quality Management System
Article 17 requires a documented QMS covering design control, testing and validation procedures, data management practices, and post-market monitoring. The evidentiary footprint is substantial: validation test results with sign-off, data governance records documenting training and test dataset provenance, post-market monitoring plans with evidence of execution. This overlaps significantly with ISO 42001 Clause 8, which means organisations pursuing dual compliance can consolidate much of this documentation.
The EU AI Act’s conformity assessment process for high-risk systems carried out either by notified bodies or through internal assessment for certain categories requires presenting this evidence chain as a coherent package, not a folder of disconnected documents. How that package is structured and navigated matters as much as its contents.
NIST AI RMF Evidence Outputs by Function
The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is voluntary in the US but functions as the evidence substrate that most major AI regulatory regimes effectively reference. A compliance team that implements the AI RMF’s four core functions produces most of the substantive evidence each regime requires.
GOVERN
GOVERN produces the foundational governance documentation: AI risk policy, roles and accountability matrix, vendor and third-party AI risk assessment procedures, and records showing that AI risk decisions are escalating to appropriate organisational levels. GOVERN 1.1 specifically requires that legal and regulatory requirements are documented making this function the logical home for your cross-framework compliance mapping.
MAP
MAP produces AI system inventory records and risk context documentation. Each AI system in scope should be mapped with its intended use, deployment context, affected stakeholders, and applicable regulatory requirements. The July 2024 Generative AI Profile (NIST AI 600-(https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)) extends this mapping to 12 risk categories specific to large language models and generative systems — including confabulation, prompt injection, and data privacy each with associated evidence actions.
MEASURE
MEASURE produces the technical performance evidence: model testing results, bias and fairness assessments, calibration reports, red-team exercise outputs, and runtime monitoring metrics. For organisations subject to the EU AI Act, MEASURE outputs align closely with Article 9 and Article 17 technical documentation requirements.
MANAGE
MANAGE produces operational governance evidence: incident logs (with resolution records), corrective action documentation, and continuous improvement plans. Where MEASURE identifies performance degradation or a bias concern, MANAGE evidence shows what was done about it.
The practical advantage of organising AI audit evidence by AI RMF function is traceability. An auditor who asks “how does your organisation identify risks in deployed AI systems?” can be directed to MEASURE outputs linked to MANAGE responses a logical, documented chain rather than a search through unstructured folders.
The Cross-Framework Evidence Map
The most common inefficiency in AI audit preparation is treating ISO 42001, the EU AI Act, and NIST AI RMF as three separate evidence collection exercises. Many artifacts satisfy requirements across all three frameworks simultaneously.
| Evidence Artifact | ISO 42001 | EU AI Act | NIST AI RMF |
| AI System Inventory | Annex A (A.6.2) | Article 9 (scope) | MAP – AI system register |
| AI Risk Assessment | Clause 6.1.2 | Article 9 (continuous risk mgmt) | MEASURE – risk evaluation records |
| AI Impact Assessment | Clause 6.1.4 | Article 9 (fundamental rights) | MAP – stakeholder impact context |
| AI Policy | Clause 5.2 | Article 17 (QMS strategy) | GOVERN 1.2 – AI risk policy |
| Competence Records | Clause 7.2 | Article 17 (QMS -personnel) | GOVERN 6.2 – accountability roles |
| Data Governance Records | Clause 8 / Annex A (A.8) | Article 17 (data management) | MAP 2.3 – data classification |
| Monitoring Metrics | Clause 9.1 | Article 9 (ongoing monitoring) | MEASURE 2.5 – performance metrics |
| Internal Audit Report | Clause 9.2 | Article 17 (QMS audit) | GOVERN 5.2 – oversight mechanisms |
| Management Review Minutes | Clause 9.3 | Article 17 (QMS review) | GOVERN 2.2 – risk tolerance review |
| Incident & Logging Records | Clause 10.2 | Article 12 (automatic logs) | MANAGE 4.1 – incident response |
| Corrective Action Records | Clause 10.2 | Article 9 (risk treatment update) | MANAGE 4.2 – improvement plans |
| Validation / Test Results | Clause 8.2 / Annex A (A.9) | Article 17 (test procedures) | MEASURE 2.6 – testing records |
When an auditor asks for your EU AI Act Article 9 risk management documentation, pointing to a well-structured ISO 42001 Clause 6.1.2 risk assessment (dated, system-specific, lifecycle-continuous) is a legitimate and accepted response provided the content addresses the Article 9 requirements. The frameworks are complementary by design. The ISO 42001 risk assessment process maps directly to the continuous risk management obligation in Article 9; the Clause 9.2 internal audit produces evidence that supports NIST AI RMF GOVERN 5.2 (oversight mechanisms).
| PRODUCT NOTE: Govern365.ai’s audit evidence management module maintains this cross-framework linkage automatically each evidence artifact is tagged to its applicable clauses and articles, so auditors can query by framework without the team manually maintaining cross-reference spreadsheets. |
What Makes Evidence Auditor-Ready
Having evidence is not the same as having evidence that will satisfy an auditor. This distinction is where most preparation guides stop short.
Version control and timestamps are the first thing auditors check. A risk assessment document with no version history and a modification date of last Tuesday raises obvious questions about when the assessment was actually conducted. Evidence should carry a creation date, a version number, and an author or approver record. For dynamic documents like AI system monitoring metrics, timestamps should be system-generated rather than manually recorded.
Clause labelling sounds administrative but significantly affects audit efficiency. Auditors conducting a Stage 1 review the documentation-only phase before the on-site audit are working through a repository of materials and matching them to clauses. Evidence files named “AI Risk Assessment System X v2.3 2025-11-14 Clause 6.1.2.pdf” take minutes to locate and verify. Evidence in a folder called “Compliance Docs” takes much longer and creates impressions about governance maturity.
Currency requirements vary by evidence type. AI policy documents are generally acceptable if reviewed within the past 12 months and signed by accountable leadership. Risk assessments should reflect the current state of the system if the model has been retrained or the deployment context changed, the risk assessment needs to be updated accordingly. Auditors regularly find risk assessments that predate the live version of the system by 18 months, which satisfies no framework requirement.
Stage 1 vs Stage 2 expectations differ materially. Stage 1 (documentation review) tests that required documents exist, are current, and cover the right scope. Stage 2 (on-site verification) tests that the documents describe what actually happens auditors will ask staff questions, check system logs, and request live demonstration of processes. Evidence that reads like an aspirational procedure rather than an actual operational record will surface in Stage 2.
Organisations that completed ISO 42001 certification with zero major non-conformities like Synthesia in mid-2024, one of the first AI video companies to earn certification attribute much of that outcome to evidence organisation: a read-only, clause-labelled repository where every required artifact was current and accessible before the Stage 1 review began.
Common Audit Findings and the Evidence Gaps Behind Them
Patterns across ISO 42001 certification audits have produced a short list of recurring findings. Each traces back to a specific evidence gap.
Missing or incomplete AI system inventory
Auditors verify AIMS scope against the AI system inventory. When systems are excluded from the inventory without documented justification, or when the inventory does not reflect recent deployments, it creates scope integrity questions. Organisations that rely on informal processes to track AI systems consistently produce inventories that miss recently deployed or third-party AI tools.
Risk assessments that do not reflect lifecycle reality
ISO 42001 Clause 6.1.2 and EU AI Act Article 9 both require that risk assessment is continuous. A single pre-deployment risk assessment, never updated after the model went live, fails both requirements. Auditors look for evidence of periodic review at minimum, triggered by material changes to the system, training data, or deployment context.
Training records disconnected from AI-specific responsibilities
Generic “AI literacy” training completion is noted but not treated as competence evidence for staff with governance roles. An AI risk officer whose training record shows a two-hour e-learning course will raise a Clause 7.2 finding. Competence evidence needs to link specific training content to the responsibilities the individual holds under the AIMS.
Management review minutes lacking AI metrics
ISO 42001 Clause 9.3 requires management review to cover AIMS performance data which includes AI system monitoring metrics, audit results, and risk treatment outcomes. Management review minutes that discuss AI at a strategic level without referencing specific performance data are consistently flagged.
Incident logs without resolution records
An incident log that captures events but not their resolution root cause, corrective action, outcome verification — satisfies the detection requirement of an audit but fails the corrective action requirement of Clause 10.2 and the NIST AI RMF MANAGE function. The log is evidence of a problem; the resolution record is evidence of a functioning management system.
How to Organise Your AI Audit Evidence Package
A structured evidence repository is not primarily about tidiness. It is about being able to demonstrate, within minutes of an auditor’s request, that a specific control exists, is implemented, and is current.
A workable structure organises evidence at two levels: by framework clause (for certification audits), and by AI system (for scoping and inventory verification). The top-level folders map to frameworks; sub-folders map to clauses or articles; individual files follow a naming convention that includes the system name, the clause reference, the version, and the date.
Practically, this looks like:
/AI Audit Evidence /ISO-42001 /Clause-6-Risk-Assessment Risk-Assessment-System-X-v2.1-2026-02-28-Cl6.1.2.pdf /Clause-9-Performance /Clause-10-Improvement /EU-AI-Act /Article-9-Risk-Management /Article-12-Logging /Article-17-QMS /NIST-AI-RMF /GOVERN /MAP /MEASURE /MANAGE /Evidence-Index.xlsx
The evidence index is a simple master register mapping each required artifact to its file location, the relevant clause/article, the document owner, the last review date, and a status (current / due for review / gap). This index becomes the first document you hand an auditor at Stage 1 and the primary navigation tool throughout the audit.
Organisations managing this in shared drives will find the structure workable for smaller AIMS scopes. At enterprise scale multiple AI systems, multiple regulatory frameworks, multiple audit cycles manual evidence management introduces version control failures and gaps that surface at precisely the wrong moment. Purpose-built AI governance platforms maintain clause-level tagging, version history, and review scheduling automatically, which is why evidence management has become one of the primary use cases driving AI governance platform adoption.
Frequently Asked Questions
What documents are required for an ISO 42001 audit?
ISO 42001 requires the following evidence artifacts at minimum: an AIMS scope statement, AI policy, AI risk assessment records (Clause 6.1.2), AI impact assessment (Clause 6.1.4), competence and training records (Clause 7.2), internal audit report (Clause 9.2), management review minutes (Clause 9.3), and nonconformity and corrective action records (Clause 10.2). Auditors also expect an AI system inventory, though it is not explicitly mandated in the standard text.
What is the difference between AI audit evidence and AI documentation?
Documentation describes what your organisation intends to do policies, procedures, governance frameworks. Audit evidence demonstrates that it actually happened dated risk assessment records, training logs linked to named individuals, monitoring metrics with timestamps, incident records with resolution trails. An AI audit needs both, but records carry more weight in the evidence assessment.
Does the EU AI Act require the same evidence as ISO 42001?
There is substantial overlap. Both frameworks require risk assessment documentation, AI system inventory, data governance records, and corrective action processes. The key differences are that the EU AI Act requires automatic logging capability (Article 12), a formal quality management system (Article 17), and that evidence covers the full system lifecycle continuously. ISO 42001 certification does not certify EU AI Act compliance, but the evidence packages are highly compatible.
How far in advance should I prepare AI audit evidence?
Glocert International’s readiness guidance recommends beginning preparation 6-9 months before the target certification date, with 4-8 weeks for the gap assessment and 3-6 months for remediation depending on the severity of gaps found. Organisations with existing ISO 27001 implementations typically have shorter remediation timelines due to transferable management system infrastructure.
Can internal audit evidence be used in a certification audit?
Yes the internal audit report and its findings are required evidence for ISO 42001 certification. The internal audit must be completed before the Stage 2 certification audit. Auditors use the internal audit report to assess whether the organisation can identify its own conformity gaps and respond to them. An internal audit with no findings in a newly implemented AIMS is typically treated with scepticism.
What happens if audit evidence is incomplete at a certification audit?
Incomplete evidence results in a nonconformity either major (systemic gap that prevents certification) or minor (isolated gap requiring corrective action within an agreed timeframe). Major nonconformities require a complete corrective action cycle before certification can proceed. Minor nonconformities may allow conditional certification with a follow-up verification. In both cases, the auditor will document the specific evidence gap, not just the outcome.
Next Steps
Audit evidence is the operational proof that AI governance is real rather than documented. The frameworks ISO/IEC 42001:2023, the EU AI Act, and the NIST AI RMF agree on the fundamentals: risk assessment that reflects the lifecycle, an AI system inventory that captures scope honestly, training records linked to real responsibilities, and incident processes that close the loop. The cross-framework structure in this checklist shows that most of that evidence is the same artifact, labelled differently.
Start with the evidence index. Map your current documentation to the clause and article requirements above, identify the gaps, and build a remediation schedule that puts the most critical missing records risk assessments, impact assessments, internal audit first in the queue.
Start your 14-day free trial and build your AI governance dashboard on a platform designed by the people who wrote the standard.
