The ISO 42001 evidence checklist for security reviews
An ISO 42001 audit will ask for specific evidence across each control domain. This checklist maps the evidence required for conformance and aligns it with the artefacts an AI security review already produces.
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 artefacts 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 organisation 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, organisational 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 — organisational analysis required. |
| 4.3 | AIMS scope document — AI systems in scope, exclusions with justification, organisational 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 artefacts 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 programme 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. It requires lifecycle records for each AI system in scope — evidence that governance processes operated at each lifecycle stage.
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| 8.1 | Operational planning records — evidence that processes were planned, implemented, and controlled. | None directly. |
| 8.4 | 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. |
| 8.5 | AI system lifecycle records — design review, validation record, change log, decommission record. | Design-time security analysis and change review evidence for assessed systems. |
| 8.7 | 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 programme, 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 domain. The most technically intensive domains for an AI security function are A.6 (risk management), A.8 (system lifecycle), and A.9 (human oversight).
| Clause | Evidence required | AI security review contribution |
|---|---|---|
| A.2 | AI policy documents — approved, communicated, version-controlled. | None directly. |
| A.6.1 | Risk management process documentation and risk register entries per system. | Threat model and control gap analysis for assessed systems. |
| A.6.2 | AI impact assessment records for systems making consequential decisions. | None directly — impact assessment is an organisational analysis. |
| A.7 | Transparency disclosure records — notice to AI subjects, communication logs. | None directly. |
| A.8.4 | Validation records — pre-deployment assessment for each system in scope. | Security review report serves as A.8.4 validation record for assessed systems. |
| A.9 | Human oversight mechanism documentation — override procedures, escalation paths, intervention records. | None directly — operational design requirement. |
| A.10 | Disclosure process documentation and records of disclosures made. | None directly. |
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.