ISO/IEC 42001

ISO/IEC 42001 Internal Audit: Building the Evidence Request List Before Fieldwork

An internal audit of an AI management system succeeds or fails before fieldwork starts, in the evidence request list. A vague list ("please provide your AI governance documentation") produces a folder of policies and a week of follow-up emails. A precise list, where every item names an owner, a period, a source system and the reason it is being asked for, produces evidence that can actually be examined and tested.

This article provides an original evidence request list for an ISO/IEC 42001:2023 internal audit, explains the four fields every request should carry, and shows how to tell self-reported evidence from inspected and tested evidence when the responses come back.

By: AuditPartners
Added: 2 October 2026
Reading time: 10 min
Status: Educational guide

What ISO/IEC 42001 asks of an internal audit

ISO/IEC 42001:2023 follows the harmonised structure used by other ISO management-system standards such as ISO/IEC 27001:2022: clauses 4 to 10 cover context, leadership, planning, support, operation, performance evaluation and improvement, and Annex A lists control objectives and controls that the organisation selects and justifies in a Statement of Applicability. The internal audit requirement sits in the performance-evaluation clause and expects audits at planned intervals that determine whether the AI management system conforms to the organisation's own requirements and to the standard, and is effectively implemented and maintained.

The standard's text is licensed and is paraphrased here rather than reproduced. Audit programme design and auditor competence are the subject of ISO 19011; if the audit is performed by an internal audit function, the IIA's Global Internal Audit Standards also apply. Those two sources are not interchangeable, and the audit plan should say which governs.

The four fields every request needs

Owner. The named role that holds the evidence. Not 'the AI team'; the person who can export the record.
Period. The date range or point in time the evidence must cover. An audit of a management system that has run for nine months asks for nine months of records, not the latest example.
Source. The system of record the evidence comes from: a ticketing tool, a model registry, an IAM console, a board minute book. Naming the source lets the auditor ask for a system export rather than a slide.
Purpose. The requirement or control objective the evidence will be compared against, in the organisation's own words. Stating the purpose lets the owner provide the right thing and lets the auditor spot when something else has been substituted.

A request that lacks any of these will come back as self-report: a description of the process instead of the records that show it ran.

The evidence request list

The list below is an original worked example written for a fictional organisation; it is not a reproduction of the standard's clauses or Annex A. The period is the twelve months to 30 September 2026. Sample sizes and periods are illustrative, selected by risk and scope rather than universal requirements. Independent impact-review examples reflect Kestrel's own illustrative organisation criteria, not blanket ISO/IEC 42001 requirements. Adapt owners, sources and purposes to your own management system and Statement of Applicability.

Evidence request list for the Kestrel Health Analytics ISO/IEC 42001 internal audit (twelve months to 30 September 2026)
#	Request	Owner	Period	Source	Purpose
1	Current AI management system scope statement and the list of AI systems in scope, with the criteria used to decide inclusion.	Head of AI Governance	As at 30 Sep 2026	Governance repository	Confirm scope is defined and the three systems are in it; test whether any AI use outside the list should be inside it.
2	AI policy and the record of its approval by top management, including the version history.	Head of AI Governance	Oct 2025 – Sep 2026	Document management system	Leadership commitment and policy currency; check the approved version is the one staff can access.
3	Roles and responsibilities matrix for AI systems, including named system owners and the person accountable for the AI management system.	Chief Risk Officer	As at 30 Sep 2026	Governance repository / HR system	Accountability is assigned to real, current people; cross-check names against the HR leavers list.
4	AI risk assessment methodology and the completed risk assessment for each of the three systems, with risk owner sign-off.	AI Risk Lead	Latest assessment per system, plus any re-assessment in period	Risk register (GRC tool export)	Risk assessment performed per the methodology; impact assessment covers affected individuals and groups, not only the organisation.
5	AI system impact assessments for the clinical summariser and claims classifier, with dates and reviewers.	System owners	Latest version in period	Governance repository	Impact on individuals and society considered for the higher-risk systems; reviewers independent of the development team under Kestrel's own illustrative criteria, not a blanket requirement of the standard.
6	Statement of Applicability with justification for included and excluded Annex A controls, and its approval record.	Head of AI Governance	Current version, with change log	Governance repository	Control selection is justified and approved; excluded controls have a stated reason.
7	Risk treatment plan with actions, owners, due dates and status, and evidence of closure for any action marked complete.	AI Risk Lead	Oct 2025 – Sep 2026	GRC tool export; ticketing system	Treatment is planned and tracked; completed actions have evidence, not just a status change.
8	AI objectives for the year and the measurements reported against them.	Head of AI Governance	FY to 30 Sep 2026	Management reporting pack	Objectives are measurable and were measured; trace one metric to its source data.
9	Competence records for people who develop, deploy and oversee the three systems, including training completion and any competence gaps identified.	HR Business Partner	Oct 2025 – Sep 2026	Learning management system	Competence is determined and addressed; sample five people across roles.
10	Inventory of data used to train, fine-tune or ground each system, with provenance, consent or lawful basis, and quality checks performed.	Data Governance Lead	Per system, current	Data catalogue	Data provenance and quality are managed; the free AI System Inventory Template shows the fields we expect.
11	Model and system lifecycle records for the claims classifier: requirements, design decisions, verification and validation results, release approvals.	Claims ML Lead	All releases in period	Model registry; CI/CD system	Development follows the defined process; select two releases and trace each from requirement to approval.
12	Change records for every production change to the three systems, including model updates and prompt or configuration changes.	Platform Engineering Lead	Oct 2025 – Sep 2026	Change management tool; deployment logs	Changes are controlled; reconcile the change list to the deployment log population and sample ten.
13	Operational monitoring outputs: performance, drift and incident indicators for each system, and the review records showing someone looked at them.	System owners	Monthly, Oct 2025 – Sep 2026	Monitoring platform; review meeting minutes	Monitoring is performed and acted on; absence of review records is a finding even if dashboards exist.
14	AI incident and near-miss log, with root-cause analysis and corrective actions for each closed item.	AI Risk Lead	Oct 2025 – Sep 2026	Incident management system	Incidents are captured, investigated and lead to corrective action; cross-check against support tickets mentioning model errors.
15	Third-party and supplier records for externally sourced models and AI services, including contracts, due-diligence results and monitoring.	Procurement Lead	Current suppliers plus any onboarded in period	Contract repository; vendor risk tool	Supplier AI risk is assessed and monitored; see AI Vendor Risk Assessment: Questions to Ask Before You Buy for what due diligence should contain.
16	Communications to affected users and customers about AI use, including any transparency notices and the record of what was published when.	Head of Product	Oct 2025 – Sep 2026	Website change log; customer communications archive	Transparency obligations the organisation set itself are met; compare notices to actual system behaviour.
17	Previous internal audit report, nonconformities raised and evidence of corrective action for each.	Head of AI Governance	Prior audit cycle	Audit tracker	Prior findings are closed with evidence; re-test one closed item.
18	Management review inputs, minutes and resulting decisions and actions.	Executive Assistant to the COO	All reviews in period	Board and executive minute book	Top management reviewed the management system and decided on actions; confirm the inputs the standard expects were actually tabled.

Item numbering is for the worked example only. Where a request refers to a clause area of ISO/IEC 42001:2023, it does so by subject, not by quoting the clause. The AI Audit Evidence Request Checklist is a downloadable version of this structure with blank result columns.

When the evidence comes back: self-reported, inspected, tested

The request list produces inputs. What the auditor does with them determines what the audit can conclude. Using the methods described in NIST SP 800-53A as a vocabulary: interview produces self-reported evidence, examine produces inspected evidence, and test produces tested evidence.

Three responses to request 13 (operational monitoring) and what each supports
Response received	Classification	What it supports	What it does not support
The system owner describes the monthly review process in a meeting and says it has happened every month.	Self-reported	Where to look next; the owner's understanding of the process.	That any review occurred.
Twelve monthly review-meeting minutes with attendees, metrics discussed and actions, exported from the minutes tool with creation timestamps.	Inspected	Reliable operating records can support that monthly reviews operated, who attended and what was decided.	That the metrics shown were accurate or that actions were completed.
Auditor re-performs the drift calculation for two months from the monitoring platform's raw data, matches it to the minutes, and traces two resulting actions to closed tickets.	Tested	That the reviewed figures were correct for the sample and that actions were taken.	Anything about the ten months not re-performed; conclusions are limited to the sample.

Gaps this list tends to surface

Named owners who have left the organisation (request 3 against the leavers list).
Impact assessments with no independent reviewer where the organisation's own criteria require one (request 5 in this fictional example, not a blanket ISO/IEC 42001 requirement).
Risk treatment actions marked complete with no closure evidence (request 7).
Prompt and configuration changes that bypass change management because they are not 'code' (request 12).
Dashboards that exist but were never reviewed, with no minutes or actions (request 13).
Supplier models in production with no due-diligence record because they were onboarded by a product team through a credit card (request 15).

If you are not yet at the point of an internal audit, the free AI Governance QuickScan covers basic inventory, ownership and policy themes at a preliminary, self-reported level in under ten minutes; it does not cover the evidence request list. When you are ready to plan an audit or a pre-certification gap assessment, our Framework Assessments & Internal Audits page describes how we scope the work.

Key takeaways

Every evidence request needs an owner, a period, a source system and a purpose; without them you receive descriptions, not records.
Ask for populations over the audit period, then sample; the latest example proves only that one example exists.
Classify what comes back as self-reported, inspected or tested, and write conclusions that name their basis.
ISO/IEC 42001:2023 is licensed; request by subject and your own Statement of Applicability, not by copying clause text.
An internal audit is an input to certification, never a certificate.

References

Primary sources cited above. Standards are referenced by number and year; their text is licensed and is paraphrased, not reproduced.

ISO/IEC 42001:2023, Artificial intelligence management system — Requirements (opens in a new tab) — Licensed text; structure and requirements paraphrased.
ISO/IEC 27001:2022, Information security management systems — Requirements (opens in a new tab) — Harmonised structure shared with ISO/IEC 42001.
ISO 19011, Guidelines for auditing management systems (opens in a new tab) — Audit programme and auditor competence guidance.
The IIA, Global Internal Audit Standards (effective 9 January 2025) (opens in a new tab)
NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls, January 2022 (opens in a new tab) — Examine, interview and test methods.
NIST AI 100-1, AI Risk Management Framework (AI RMF 1.0), January 2023 (opens in a new tab) — Risk and impact assessment practices that many AI management systems adopt as their methodology.