Most teams preparing for an ISO/IEC 42001:2023 audit ask the same question: what will they actually want to see? I think the better question is what the auditor needs to be able to conclude by the end of the week. An auditor is trying to decide whether your AI management system (AIMS) exists, whether it matches what the standard requires, and whether it is operating in practice. Every document request traces back to one of those three conclusions.
This article walks through the evidence an auditor typically asks for, organized by the clauses and Annex A controls where the requests originate. It also covers how the request pattern changes between Stage 1 and Stage 2, and the evidence gaps that most often produce findings.
What Does an ISO 42001 Auditor Actually Look For?
An ISO 42001 auditor looks for objective evidence that each applicable requirement of clauses 4 through 10 is met and that the Annex A controls you selected are implemented and working. The standard itself sets the baseline: clause 7.5 requires documented information that the standard requires plus documented information your organization determines is necessary for the effectiveness of the AIMS.
Two things follow from that wording. First, the standard does not hand you a fixed list of procedures to write. It lists specific items that must exist as documented information, and the rest is your call based on your size, complexity, and the AI systems you run. Second, the auditor will test your call. If you say a process is too simple to need a written procedure, expect them to ask how a new employee would know what to do.
Certification audits for AI management systems follow the general certification body rules in ISO/IEC 17021-1, and ISO/IEC 42006:2025 (Requirements for bodies providing audit and certification of AI management systems) adds requirements specific to those bodies. Under the ISO/IEC 17021-1 model, that typically means a two-stage initial audit, annual surveillance audits, and recertification at the end of a three-year certification cycle. Confirm the exact schedule with your certification body.
Stage 1 vs. Stage 2: How the Requests Differ
The two stages ask different questions, so they generate different document requests.
| Aspect | Stage 1 (Readiness Review) | Stage 2 (Implementation Audit) |
|---|---|---|
| Main question | Is the AIMS designed to meet the standard? | Is the AIMS implemented and effective? |
| Typical evidence | Scope, AI policy, risk and impact assessment methodology, Statement of Applicability, internal audit and management review plans | Completed risk assessments, impact assessments, records of operation, training records, incident logs, internal audit report, management review minutes |
| Evidence type | Mostly documents describing the system | Mostly records showing the system running |
| Interviews | Limited, mostly with the AIMS owner | Broad: leadership, engineers, data owners, procurement, HR |
| Typical outcome | Readiness findings and areas of concern (points the auditor warns could become nonconformities at Stage 2) | Audit conclusions the certification body uses to decide whether to certify, plus nonconformities if gaps exist |
A useful way to think about it: Stage 1 asks to see the blueprint, and Stage 2 asks to see the house being lived in. In my experience, a polished policy set with no operating records is one of the most common reasons a Stage 2 produces major nonconformities.
Foundation Documents: Clauses 4 and 5
These are the first things requested because everything else hangs off them.
Context and interested parties (clauses 4.1 and 4.2). The auditor will ask how you determined the external and internal issues relevant to your AIMS and which interested parties matter, including their requirements. Clause 4.1 expects you to consider your role, such as AI provider, producer, or user. Evidence is usually a context analysis, a register of interested parties, and a list of applicable legal and contractual requirements. If you sell into the EU, expect the auditor to ask how Regulation (EU) 2024/1689 (the EU AI Act) was considered, even if you conclude parts of it do not apply.
Scope (clause 4.3). The scope must be available as documented information. Auditors read it closely because it defines what they are allowed to sample. They will ask which AI systems, business units, and locations are in or out, and why. Vague scope statements such as "all AI activities" invite a request for a full inventory, so have the inventory ready.
Leadership and AI policy (clauses 5.1 to 5.3). Clause 5.2 requires an AI policy that is documented, communicated within the organization, and available to interested parties as appropriate. The auditor will ask for:
- The signed or approved policy.
- Evidence it was communicated, such as an intranet post, training slide, or onboarding acknowledgment.
- Proof that top management engaged, such as meeting minutes, resource approvals, and budget decisions.
- The documented assignment of roles and authorities under clause 5.3.
Interviews with top management are standard at Stage 2.
Planning Evidence: Clause 6
This is where much of the AI-specific scrutiny lands, and where ISO 42001 differs most from other management system standards.
AI risk assessment process (clause 6.1.2). The standard requires you to define and establish a process for assessing AI risks, with criteria for acceptance and for performing assessments that produce consistent, valid, and comparable results. Auditors ask for the written methodology, the risk criteria, and the risk register or equivalent output.
AI risk treatment (clause 6.1.3). Here the auditor wants the risk treatment plan and the Statement of Applicability. Clause 6.1.3 requires you to determine all controls necessary to implement the treatment options, compare them against Annex A, and produce a Statement of Applicability that records the controls you included, the justification for inclusion, whether each is implemented, and the justification for any Annex A control you excluded. An exclusion with no reasoning is a reliable way to earn a finding.
AI system impact assessment (clause 6.1.4). The process for assessing the potential consequences of AI systems for individuals, groups, and society must be established, and the results must be retained as documented information. Auditors request the impact assessment procedure and completed assessments for the AI systems within scope. This is a separate activity from the risk assessment, and treating the two as one document is a frequent mistake.
AI objectives (clause 6.2) and planning of changes (clause 6.3). Expect requests for measurable AI objectives, who owns them, and how they are monitored. The standard does not require a particular record under clause 6.3, but auditors commonly expect to see how a change to the AIMS was planned and controlled, so have an example ready if one has occurred.
Support Evidence: Clause 7
Clause 7 produces the records auditors find easiest to sample, so it is often where they start pulling threads.
- Resources (7.1): budget, staffing, and tooling decisions tied to the AIMS.
- Competence (7.2): role descriptions for people working on AI systems, training records, and a way to show competence was evaluated, not just that training was delivered.
- Awareness (7.3): evidence that staff know the AI policy and how they contribute to the AIMS.
- Communication (7.4): what is communicated internally and externally about the AIMS, when, to whom, and by whom.
- Documented information (7.5): your document control procedure, with evidence of approval, versioning, and access control. Auditors will check that the version of the AI policy on the intranet matches the approved one.
One practical note on competence. If your data scientists were hired for technical skill and never trained on bias, transparency, or your impact assessment process, the auditor will find it in the first two interviews. A short, recorded, role-specific training session fixes this faster than a rewritten procedure.
Operational Evidence: Clause 8
Clause 8 is where the standard moves from design to proof. Clause 8.1 requires you to plan, implement, and control the processes needed to meet requirements and keep documented information to the extent necessary to have confidence the processes were carried out as planned.
The methods behind these items are covered under clause 6 above. Here the auditor wants the operating records:
- Completed AI risk assessments (clause 8.2), performed at planned intervals or when significant changes occur, with dates and reviewers.
- Risk treatment results (clause 8.3), showing the plan was carried out and residual risk was reviewed.
- Completed AI system impact assessments (clause 8.4), including outcomes and actions taken.
- Control of outsourced processes, since clause 8.1 expects externally provided processes, products, or services relevant to the AIMS to be controlled (check the exact wording against your copy of the standard). That means supplier evaluations, contracts, and the due diligence you performed on third-party models or datasets.
A question I hear often: does the auditor want to see every AI system's file? No. They sample. But they choose the sample, not you, so every in-scope system needs a file that would survive being picked.
Performance Evaluation and Improvement: Clauses 9 and 10
These clauses are the most predictable requests in the entire audit, which makes failures here especially avoidable.
Monitoring and measurement (9.1). Evidence of what you decided to monitor, the methods, when results are analyzed, and the results themselves. For AI systems this often includes performance metrics, drift indicators, and complaint or incident trends.
Internal audit (9.2). The audit programme, audit criteria and scope, auditor independence and impartiality, the reports, and follow-up on findings. Certification bodies generally expect at least one internal audit cycle to have been completed, with findings followed up, before Stage 2, and an internal audit rushed the week before shows. Clause 9.2 also expects results to be reported to relevant management.
Management review (9.3). Minutes showing that top management reviewed the specified inputs at planned intervals, including the status of actions from earlier reviews, changes in external and internal issues, performance information, audit results, and opportunities for improvement. Minutes that read like a generic agenda with no decisions are a weak spot. Show decisions, owners, and dates.
Nonconformity and corrective action (10.2). A log of nonconformities (including internal audit findings), root cause analysis, corrective actions, and a check of their effectiveness. Clause 10.1 adds continual improvement, which the auditor will look for in the pattern of your records over time.
Annex A Control Evidence
The Statement of Applicability tells the auditor which Annex A controls to examine. Annex A of ISO/IEC 42001:2023 lists 38 controls grouped under nine control objectives (A.2 through A.10), and Annex B gives the implementation guidance. The table below shows what evidence typically supports each group.
| Annex A Objective | Focus | Typical Evidence Requested |
|---|---|---|
| A.2 Policies related to AI | Direction and review | AI policy, alignment with other organizational policies, review records |
| A.3 Internal organization | Roles and reporting | Role assignments, process for reporting concerns about AI systems |
| A.4 Resources for AI systems | Inventory of what you rely on | Documentation of data, tooling, computing, and human resources per system |
| A.5 Assessing impacts of AI systems | Impact on individuals and society | Impact assessment process and completed assessments |
| A.6 AI system life cycle | Design through operation | Requirements specifications, design documentation, verification and validation results, deployment plans, monitoring and event logs, technical documentation |
| A.7 Data for AI systems | Data management | Data acquisition records, data quality criteria, provenance records, data preparation steps |
| A.8 Information for interested parties | Transparency and reporting | User documentation, incident communication procedure, external reporting processes |
| A.9 Use of AI systems | Responsible use | Responsible use procedures, defined objectives, intended-use documentation |
| A.10 Third-party and customer relationships | Supply chain | Allocation of responsibilities, supplier assessments, customer expectations and contracts |
The A.6 and A.7 groups tend to draw the most technical questions. For a given AI system, an auditor may ask you to trace one decision from the requirement through design, testing, deployment, and monitoring. If the verification and validation record exists but cannot be linked back to a stated requirement, you have a traceability gap. Similarly, the data controls at A.7 are where "where did this training data come from, and how do you know it is fit for purpose" gets answered or doesn't.
How to Organize Your Evidence So Audits Go Smoothly
In my experience, the organizations that handle audits well do not necessarily have more documentation. They can find it quickly. A few habits help.
Build a clause-to-evidence map. A single spreadsheet listing each clause and Annex A control, the document or record that satisfies it, the owner, and the location. When the auditor asks "show me how you meet 6.1.4," the answer takes seconds instead of an hour of searching.
Keep an AI system inventory that ties everything together. Each system should link to its risk assessment, impact assessment, data sources, validation results, supplier records, and monitoring data. I think this is the single most useful artifact in an AIMS, because auditors sample by system.
Separate procedures from records. Procedures describe what you do, and records prove you did it. Stage 1 leans on the former and Stage 2 leans on the latter, so check that you have both for every process.
Date everything and show review. Undated risk registers and impact assessments are hard to trust. The auditor is trying to establish a timeline of operation.
Prepare your people, not just your files. Documented information is half the audit. The other half is whether the person running a model in production can explain, in their own words, what the AI policy requires of them and how they apply the impact assessment process.
Common Evidence Gaps That Produce Findings
These are the patterns that most often turn into nonconformities:
- A Statement of Applicability with no justifications. Clause 6.1.3 asks for justification of inclusions and exclusions, not just a checklist of yes and no.
- Impact assessments done once and never revisited. The AIMS must account for change, so a model retrained or repurposed should trigger a review.
- Internal audit performed by the person who built the system. Clause 9.2 requires objectivity and impartiality of the audit process.
- Management review with no AI-specific inputs. If the minutes could belong to an ISO 9001 meeting, the auditor will notice.
- Third-party AI treated as someone else's problem. Using an external model or API does not remove it from your scope. Clause 8.1 and the A.10 controls expect you to control what you rely on.
- No evidence that the policy reached the people building AI. An approved policy sitting in a folder satisfies the document requirement but not the communication requirement.
None of these require sophisticated fixes. They require someone to read the clause, ask what proof it implies, and collect it before the auditor arrives.
Where to Start
If you are early in the process, start with the Statement of Applicability, because it forces decisions about which controls apply and what evidence each one will need. Then work outward to the risk and impact assessments, and keep the operating records as you go rather than reconstructing them later. Reconstructed records are easy for an auditor to spot and hard to defend.
As a test, pick one in-scope AI system at random and try to show the whole chain from policy to monitoring. Whatever you cannot produce is your preparation list. If you want an outside read on that list, you can book an ISO 42001 gap assessment, which reviews your documents against the clauses and Annex A controls covered above.
Last updated: 2026-10-24. This article is based on ISO/IEC 42001:2023 and ISO/IEC 42006:2025; no amendments to either were reflected at the time of writing. Check the ISO catalogue for current versions before relying on clause references.
Frequently Asked Questions
What documents are mandatory for ISO 42001 certification?
The standard requires documented information for items such as the AIMS scope (clause 4.3), AI policy (5.2), AI objectives (6.2), the AI risk assessment and treatment processes and results (6.1.2, 6.1.3, 8.2, 8.3), the Statement of Applicability (6.1.3), AI system impact assessment results (6.1.4, 8.4), evidence of competence (7.2), internal audit results (9.2), management review results (9.3), and nonconformity and corrective action records (10.2). Beyond that, clause 7.5 lets you add documents your organization determines are necessary.
What is the difference between Stage 1 and Stage 2 evidence in an ISO 42001 audit?
Stage 1 focuses on whether the AIMS is designed to meet the standard, so auditors review documents like the scope, AI policy, methodologies, and Statement of Applicability. Stage 2 focuses on whether it is implemented and effective, so auditors examine operating records such as completed risk and impact assessments, training records, internal audit reports, and management review minutes.
Do auditors review every AI system in scope?
Generally no. Auditors sample, and they choose the sample. That means every in-scope AI system should have a complete file covering its risk assessment, impact assessment, data sources, validation results, supplier records, and monitoring data, because any of them could be selected.
How many Annex A controls does ISO 42001 have, and do I have to implement all of them?
Annex A of ISO/IEC 42001:2023 has 38 controls grouped under nine control objectives. You do not have to implement all of them, but clause 6.1.3 requires you to compare your necessary controls against Annex A and justify in the Statement of Applicability any control you exclude.
Is an AI impact assessment the same as an AI risk assessment under ISO 42001?
No. The AI risk assessment (clauses 6.1.2 and 8.2) addresses risks to the organization and its objectives, while the AI system impact assessment (clauses 6.1.4 and 8.4) addresses potential consequences for individuals, groups, and society. Auditors expect separate processes and separate records, although the two can inform each other.
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.