An auditor reviewing AI risk management is testing whether your organization has a working program, not whether every AI system produced the right result. The focus is on whether risks are identified, assessed, and managed through repeatable processes, and whether records show that those processes operate beyond the policy documents.
Those questions require different evidence. Organizations that prepare polished policy documents but lack records of recurring activities often discover the difference during the audit. This article explains the evidence auditors seek, based on ISO 42001 certification audit structure and the program maturity indicators described in the NIST AI RMF implementation guidance.
Documentation Completeness Comes First
Before testing operation, an auditor verifies that the program is documented. This is a threshold check. A documented program that does not operate creates a finding, while an undocumented program is a major nonconformity that usually stops the audit for that scope area.
A complete AI risk program includes a management-approved AI policy with defined scope, a risk assessment for the AI systems in scope, documented governance roles and responsibilities, lifecycle procedures for each in-scope system, and a supplier assessment record for every externally procured AI system. An ISO 42001 AIMS scope statement must identify the covered AI systems. If it names six systems but audit evidence shows 14 in active use, the mismatch between stated scope and the actual AI landscape becomes a finding that affects the rest of the audit.
The AI inventory is therefore part of the compliance evidence base, not a separate governance artifact. Every other audit document depends on its scope. An incomplete inventory produces an incomplete evidence package, regardless of how well the individual documents are written.
Proof That Controls Operate
Auditors repeatedly distinguish between a control described in policy and proof that it ran. "AI systems will undergo risk assessment before deployment" describes a control. A dated assessment naming the assessor, recording the method, and documenting the treatment decision shows that the control operated.
For each in-scope control, auditors typically seek three evidence categories: a record showing application at a specific time, such as an assessment for a named system; records showing ongoing operation where required, such as monitoring logs, incident records, or access reviews; and records showing that exceptions were documented and resolved, such as approved waivers for tools deployed before the governance program existed.
Missing exception records also provide a signal. If an AI governance program has run for 18 months with zero documented nonconformities, exceptions, or incidents, an auditor may conclude that monitoring is not sensitive enough to reveal problems. Real AI environments produce issues. Recording and addressing them supports the claim that the program functions.
Review Cadence
AI risk programs must change with the tool landscape, revised risk decisions, and regulatory developments. Auditors look for evidence that the management review process in ISO 42001 Clause 9, or the NIST AI RMF Manage function's improvement loop, occurs in practice.
The requested evidence is straightforward, though it can be difficult to assemble: management review minutes that record the topics examined, what outcome data showed, and which decisions followed. The minutes need not be lengthy. They should show that an authorized decision-maker reviewed the AI risk position, received useful current information, and made or confirmed governance decisions.
The records must match the cadence set by policy. An annual policy calls for one completed review each year; a quarterly policy calls for four. Treating one meeting as fulfillment of a quarterly schedule leaves a gap. Auditors often focus on the difference between the stated cadence and the available records.
The Incident Log Test
An AI risk audit includes a request for the incident log. The aim is not to prove that problems occurred. It is to confirm a working method for detecting unexpected behavior, recording the event, and applying corrective action.
An incident log that remains empty across a multi-year program is a finding. The issue is not that an incident must have occurred, but that the organization has not shown its detection process can identify one. The key question is, "how would your organization know if an AI system produced a harmful or incorrect output?" Learning only from affected parties describes reactive complaint handling, not monitoring.
Incident records need not concern catastrophic failure. They should capture outputs flagged as unexpected, potentially harmful, or outside documented operating limits. A generative AI tool producing an incorrect summary in a high-stakes setting qualifies. So does a model falling outside the accuracy thresholds set in its risk assessment. Minor records show that monitoring is active and sensitive.
Supplier Assessment Records
Organizations using procured AI systems should expect questions about supplier evaluation and ongoing performance monitoring. ISO 42001 Clause 8.6 calls for documented supplier assessment covering data handling, model training transparency, security posture, audit rights, and incident notification terms.
A frequent weakness is a supplier review completed at procurement and never refreshed. AI suppliers change their practices. A vendor acceptable in 2024 may revise model training policies in a later product update. Annual reassessment of high-risk AI providers, with current records, is sound practice and expected in a mature program.
Auditor Nonrequirements
Auditors applying ISO 42001 or NIST AI RMF do not require perfection. They do not expect every risk to have been identified and mitigated before appearing, or every nonconformity to be absent. They assess whether the organization has structures, documented procedures, and operating records for identifying and responding to emerging AI risks.
A program with three documented nonconformities, two corrective actions completed, and an open remediation plan for the third is in a stronger audit position than a program showing zero issues and no visible monitoring. The auditor is testing whether the program is real. Real programs encounter problems, and records showing that problems were found and handled demonstrate operation.