ISO/IEC 42001: What Evidence an Auditor Expects to See

If you are preparing an institution for ISO/IEC 42001, the question that matters is not what the standard says — you can read that — but what an auditor will ask to see, clause by clause. This post walks through the structure of ISO/IEC 42001:2023 [1] and, for each clause, the kinds of evidence an auditor will expect. It is the practical companion to what AI governance evidence looks like before the audit asks for it and to mapping institutional AI controls to the NIST AI RMF.

What ISO/IEC 42001 actually is

ISO/IEC 42001 is a management system standard for artificial intelligence, published on 18 December 2023 by the ISO/IEC Joint Technical Committee 1, Subcommittee 42 (AI) [1]. Its title is Information technology — Artificial intelligence — Management system. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS) [1].

Two design choices matter for evidence. First, it applies the ISO harmonized structure (identical clause numbers, clause titles, text and common terms and core definitions) developed to align management system standards, so anyone who has faced an audit against another ISO management system standard will recognize the shape of what is coming [1]. Second, the introduction says organizations can elect to apply the requirements using a risk-based approach, and that an organization conforming with the requirements can generate evidence of its responsibility and accountability [1]. That phrase — generate evidence — is the whole game. The standard prescribes what your system must do; the evidence is what you produce to show it actually does.

The standard's only normative reference is ISO/IEC 22989:2022, the AI concepts and terminology standard [1] — a signal that precise definitions of "AI system," "AI model," and related terms are expected in your documentation, not loose usage.

How the standard is organized

ISO/IEC 42001 has ten clauses plus four annexes. Clauses 1–3 are scope, normative references, and terms. The requirements live in Clauses 4–10: Context (4), Leadership (5), Planning (6), Support (7), Operation (8), Performance evaluation (9), and Improvement (10). Annex A (normative) is a reference set of control objectives and controls; Annex B (normative) is the implementation guidance for those controls; Annex C (informative) lists potential AI-related organizational objectives and risk sources; and Annex D (informative) addresses using the AIMS across domains or sectors [1].

Because the clauses mirror the harmonized structure, an auditor's evidence request will track them in order. That makes clause-by-clause preparation a reliable way to get audit-ready.

Clause by clause: what the auditor will ask to see

Within each clause below, the examples are the typical artifacts that satisfy the clause's intent. Your institution's exact documentation will depend on its context, size, and the AI systems in scope — but the categories are consistent.

Clause 4 — Context of the organization

The auditor wants to see that you understand what your organization does with AI, who the interested parties are (regulators, students, patients, faculty, vendors), and what is in and out of scope for the AIMS. Expect to produce:

• A documented context analysis covering internal and external issues relevant to AI use
• A register or analysis of interested parties and their requirements
• The defined scope of the AIMS, documented and communicated — this is the boundary the auditor will test everything against

Clause 5 — Leadership

This clause is where institutions most often under-invest, because it is governance rather than technology. The auditor will look for an approved AI policy aligned with the organization's direction, and for clear roles, responsibilities, and authorities for AI governance. Evidence typically means:

• A signed AI policy, owned by a named executive
• Role assignments for AI governance — who owns risk treatment, who approves deployments, who handles nonconformities
• Meeting minutes showing the accountable people actually engaging with AI governance decisions, not just being named on an org chart

Clause 6 — Planning

Clause 6 is the engine of the standard. It requires actions to address risks and opportunities, and it names three distinct activities: AI risk assessment (6.1.2), AI risk treatment (6.1.3), and AI system impact assessment (6.1.4). It also requires AI objectives and a plan to achieve them (6.2).

The evidence an auditor will request:

• Risk assessment records — the identified AI risks, their likelihood and impact, and the method used to assess them
• Risk treatment plans — what is being done about each accepted risk, who owns it, and how it will be verified
• Impact assessments for the AI systems in scope (more on these below)
• Documented AI objectives that are measurable and tied to the risk picture, plus the plan to achieve them

Note that the standard treats risk assessment and risk treatment as separate activities with separate clauses — auditors will want to see both, not a single combined worksheet.

Clause 7 — Support

Support covers resources, competence, awareness, communication, and documented information. This is where "we have a policy" meets "our people can actually operate it." Expect the auditor to ask for:

• Evidence of competence — training records, role requirements, or demonstrated capability for the people operating or overseeing AI systems
• Awareness evidence — communications showing staff understand the AI policy and their obligations
• Controlled documented information — versioning, access control, and distribution of the documents above. Auditors check that the versions people use are the current ones

Clause 8 — Operation

Operation is where the system runs day to day: operational planning and control (8.1), and the ongoing execution of AI risk assessment (8.2), AI risk treatment (8.3), and AI system impact assessment (8.4). The evidence here is the difference between a policy on a shelf and a working system:

• Operational procedures for how AI systems are developed, deployed, monitored, and retired
• Risk treatment in action — records showing planned treatments were carried out and worked
• Impact assessments tied to specific AI systems, not generic templates

For the impact assessments specifically, ISO has published companion guidance: ISO/IEC 42005:2025 [2], which provides guidance for organizations performing AI system impact assessments and includes an annex with guidance for use with ISO/IEC 42001. If you are building impact assessments from scratch, that is the reference to build from.

Clause 9 — Performance evaluation

This clause tests whether the system actually works. Clause 9 requires monitoring, measurement, analysis, and evaluation (9.1); an internal audit programme (9.2); and management review (9.3), with defined inputs and results. The evidence:

• Monitoring records — how you track whether AI objectives are being met and whether controls are operating
• An internal audit programme: scope, plan, findings, and follow-up on any nonconformities raised
• Management review minutes showing the required inputs were considered and decisions were recorded

One of the strongest signals of a mature system is management review that changes something — a decision, a resource allocation, a corrective action. Expect an auditor to probe the difference between a review that happened and a review that was acted on.

Clause 10 — Improvement

Improvement closes the loop: continual improvement (10.1) and nonconformity and corrective action (10.2). The auditor will want to see the full lifecycle of at least some nonconformities — identified, root-caused, corrected, verified as effective. A record with zero nonconformities across the audit period may invite the question of how thoroughly checks are being run.

Annex A and B: the reference controls

Annex A is normative and provides a reference set of control objectives and controls; Annex B is the implementation guidance for those controls. Treat Annex A as a reference set rather than a checklist to be applied in full: which controls you apply should follow from your own risk assessment and treatment (Clause 6). In practice, expect the evidence an auditor asks for from Annex A to be, for each control you have applied, evidence that it is in place, owned, and operating, plus a rationale for the controls you selected relative to your assessed risks. Annex C's list of potential AI-related risk sources is a useful cross-check that your risk assessment did not miss an obvious category.

How the audit itself works

The audit side of certification is specified by ISO/IEC 42006:2025 [3], which sets requirements for bodies providing audit and certification of AI management systems, as additional requirements to ISO/IEC 17021-1. Its process requirements cover pre-certification activities (including determining audit scope and time), planning audits, the initial certification audit, the certification decision, and then maintaining certification through surveillance activities and re-certification [3].

Two practical consequences for an institution. First, the certification body will define the audit scope against your documented AIMS scope from Clause 4 — so a vague scope means an unfocused (or expanded) audit. Second, because surveillance and re-certification are part of the standard cycle, the evidence is not a one-time artifact. The system has to keep generating it after the certificate is issued.

Getting ready: evidence as a byproduct, not a project

The pattern across all ten clauses is the same: the auditor is not looking for a binder. They are looking for a system that leaves traces — assessments that were done, decisions that were minuted, treatments that were carried out, reviews that changed something. Preparation is easier where each clause maps to a document type that is already produced in the normal course of running the program, and harder where evidence has to be assembled retroactively for the first time.

If you have not started yet, the order of work that matches the standard is: define scope and context (Clause 4), stand up leadership and the policy (5), run the risk and impact assessments (6), then build the supporting and operational documentation (7–8) around what those assessments found — and only then wire up monitoring, internal audit, and management review (9–10) to keep it running. For a broader view of what governance evidence looks like before an audit of any kind asks for it, see our post on evidence habits; and if your institution is also mapping to the NIST AI RMF, the NIST AI RMF evidence checklist covers how the two frameworks' evidence expectations overlap.

MapOutcomes is built for exactly this clause-by-clause view: it connects your evidence to the control it satisfies, so when an auditor asks for Clause 6 risk treatment records, you are pulling a filtered view of what you already maintain — not reconstructing it.

References

1. ISO/IEC, "ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system," IEC Webstore, 2023. [Online]. Available: https://webstore.iec.ch/en/publication/90574
2. ISO/IEC, "ISO/IEC 42005:2025 Information technology - Artificial intelligence (AI) - AI system impact assessment," IEC Webstore, 2025. [Online]. Available: https://webstore.iec.ch/en/publication/107659
3. ISO/IEC, "ISO/IEC 42006:2025 Information technology - Artificial intelligence - Requirements for bodies providing audit and certification of artificial intelligence management systems," IEC Webstore, 2025. [Online]. Available: https://webstore.iec.ch/en/publication/108460