The ISO 42001 evidence checklist for security reviews
Every evidence artifact an ISO 42001 audit will request, mapped by control domain and aligned to what AI security reviews already produce.
ISO 42001 auditors arrive with a predictable set of evidence requests. The requests map to specific clauses and Annex A controls, and the evidence types required are well-defined once you understand how management system audits work. This checklist maps each clause to the evidence required for conformance, and identifies where an AI security review of assessed systems contributes to that evidence.
How to use this checklist
This checklist is structured by clause. For each clause, it lists the specific evidence artifacts an auditor expects to see, and identifies whether an AI security review contributes evidence for that clause. The checklist covers all management clauses (4–10) and the Annex A control domains.
An auditor can read your policy in five minutes. They will spend the remaining audit time looking for the records that prove the policy operated. If the records are absent, the policy is a statement of intent — not a management system.
Clause 4 — context
Clause 4 requires the organization to establish the context of the AIMS: the internal and external factors relevant to AI governance, the interested parties and their requirements, and the scope of the AIMS.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 4.1 | Documented analysis of internal and external factors — regulatory environment, organizational context, AI use cases, stakeholder expectations. | Provides regulatory context mapping (EU AI Act, GDPR, sector regulators) for assessed systems. |
| 4.2 | Stakeholder needs analysis — who has a legitimate interest in the AIMS, and what they require. | None directly — organizational analysis required. |
| 4.3 | AIMS scope document — AI systems in scope, exclusions with justification, organizational boundary. | System scope confirmation for assessed systems. |
Clause 6 — planning
Clause 6 contains the risk assessment requirement and the AIMS objectives. This clause produces the most evidence-heavy artifacts in the management system.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 6.1.1 | Documented risk and opportunity identification for the AIMS — contextual factors that affect the management system itself. | None directly. |
| 6.1.2 | AI risk assessment records — risk register entries for each in-scope system covering all AI-specific risk categories, with ratings and analysis. | Threat model and attack path analysis populate the security risk category fields for assessed systems. |
| 6.1.3 | Risk treatment plans — option selected, controls applied, named acceptor, residual rating, review trigger. | Control gap report identifies treatment requirements for assessed systems. |
| 6.2 | AIMS objectives document — measurable objectives with owners, timelines, and measurement methods. | None directly. |
Clause 7 — support
Clause 7 covers the resources, competence, awareness, communication, and documented information that the AIMS requires.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 7.2 | Competency records for people performing AI governance roles — role definitions, training records, qualifications. | None directly. |
| 7.3 | Awareness program records — evidence that relevant personnel received awareness training on the AIMS and AI policy. | None directly. |
| 7.4 | Communication plans and records — internal and external communications about the AIMS. | None directly. |
| 7.5 | Document control records — evidence that documented information is maintained, versioned, and accessible. | Review report constitutes controlled documented information for assessed systems. |
Clause 8 — operation
Clause 8 is operationally the most demanding: operational planning and control (8.1), AI risk assessment and treatment (8.2, 8.3) and impact assessment (8.4) for each AI system in scope. Most of the operating evidence comes from the Annex A life-cycle and supplier controls listed below.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 8.1 | Operational planning records — evidence that processes were planned, implemented, and controlled. | None directly. |
| A.6.2.5 | AI system deployment gate records — security review, risk acceptance sign-off, pre-deployment check record. | Security review report is the deployment gate record for assessed systems. |
| A.6 | AI system life cycle records — design review, validation record, change log, decommission record. | Design-time security analysis and change review evidence for assessed systems. |
| A.10.3 | Third-party AI system assessment records — supplier due diligence for AI providers. | Vendor model security review evidence for assessed third-party systems. |
Clause 9 — performance evaluation
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 9.1 | Monitoring and measurement records — outputs from the monitoring plan (metrics collected, dates, results). | Periodic re-assessment records for assessed systems contribute to monitoring evidence. |
| 9.2 | Internal audit records — audit program, individual audit reports, findings, and follow-up evidence. | None directly — internal audit is a management system function. |
| 9.3 | Management review minutes — evidence that top management reviewed AIMS performance and made decisions. | Review findings can be presented as an input to management review for assessed systems. |
Clause 10 — improvement
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 10.1 | Non-conformance records — identified gaps, root cause analysis, corrective actions, closure evidence. | Control gaps identified in security reviews can be raised as non-conformances for assessed systems. |
| 10.2 | Continual improvement records — decisions to improve the AIMS, evidence of implementation. | None directly. |
Annex A — control evidence
Annex A controls require specific evidence for each control objective. The most technically intensive objectives for an AI security function are A.6 (AI system life cycle), A.7 (data for AI systems), and A.9 (use of AI systems, including human oversight). Risk assessment and treatment sit in clauses 6.1 and 8.2–8.3, not in Annex A.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| A.2 | AI policy documents — approved, communicated, version-controlled. | None directly. |
| 6.1.2 · 8.2 | Risk assessment process documentation and risk register entries per system. | Threat model and control gap analysis for assessed systems. |
| A.5 | AI impact assessment records for systems making consequential decisions. | None directly — impact assessment is an organizational analysis. |
| A.6.2.4 | Verification and validation records — pre-deployment assessment for each system in scope. | Security review report serves as an A.6.2.4 verification and validation record for assessed systems. |
| A.7 | Data provenance, quality and preparation records for training, fine-tuning and retrieval data. | Data-flow and retrieval findings for assessed systems. |
| A.8 | Information for users and interested parties — system documentation, external reporting, incident communication records. | None directly. |
| A.9 | Responsible-use processes — human oversight, override procedures, escalation paths, intervention records. | None directly — operational design requirement. |
| A.10 | Supplier and customer responsibilities — allocation records and supplier due diligence. | Vendor AI security review for third-party systems. |
The ISO 42001 AI governance toolkit includes a downloadable version of this checklist with status tracking fields for each evidence item.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Produce the security evidence layer for your ISO 42001 audit
Drel generates the threat model, control gap record, and deployment review evidence that satisfy the Clause 6 and Clause 8 evidence requirements for assessed systems.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.