ISO 42001 — turn the standard into operational evidence.

ISO/IEC 42001 is the international standard for AI management systems. Published in 2023, it is structured the way every ISO management system standard is structured: clauses 4 through 10 set requirements for the organisation's management of AI, not for the AI products themselves. The standard does not say “your AI must do X”. It says “your organisation must have a documented system for managing AI, and that system must do X”.

The seven clause groupings map plainly to operational work:

• Clause 4 — Context of the organisation. Who you are, what AI systems you use or build, who has a legitimate interest, what regulatory environment applies. Mostly an organisational scoping exercise.
• Clause 5 — Leadership. Named accountability. The AI policy, role assignments (CISO, AI governance officer, system owners), and the documented commitment from leadership.
• Clause 6 — Planning. AI risk identification, AI risk analysis, AI risk evaluation, and AI risk treatment. This is the substance — most of the work an auditor will inspect lives here.
• Clause 7 — Support. Resources, competences, awareness, communication, and documented information. Mostly the supporting infrastructure for clause 6.
• Clause 8 — Operation. Operational planning and control of the AI system lifecycle. AI risk treatment in practice. AI system impact assessment for each system. This is where per-system records live.
• Clause 9 — Performance evaluation. Monitoring, internal audit, management review.
• Clause 10 — Improvement. Nonconformity, corrective action, continual improvement.

Clause 8 (Operation) and clause 6.1 (Actions to address risks and opportunities) together form the operational core. The standard requires a documented AI risk management process, applied to each AI system, producing per-system risk records. The six requirements an auditor will look for evidence of:

• An established AI risk management process.A documented procedure that names the steps, the inputs, the outputs, and the accountable roles. “We do risk assessment” is not a process. A process has named steps and produces named artefacts.
• AI risk identification. For each AI system, what risks have been identified. This is per-system, not organisation-wide. The risk register for a RAG knowledge assistant is not the risk register for a procurement agent.
• AI risk analysis. For each identified risk, an analysis of likelihood and consequence. The standard does not prescribe a methodology; you choose one and apply it consistently. Qualitative scales (low/medium/high) are acceptable if defined.
• AI risk evaluation.For each analysed risk, a decision about whether further treatment is required. The decision criteria should be documented — “high” risks always require treatment, “low” risks may be accepted with documented rationale, etc.
• AI risk treatment. For each risk requiring treatment, the controls implemented or planned. This is your control plan, mapped to specific risks. Evidence that the control is operating belongs here.
• Monitoring and review. Evidence that the AI risk register is reviewed and updated as the system changes. A risk register dated two years ago and never re-reviewed is a nonconformity.

ISO 42001 explicitly addresses the AI system lifecycle — design, development, deployment, operation, decommissioning. The standard does not prescribe specific lifecycle gates, but clause 6.1.4 (AI system impact assessment) and clause 8 (operation) together imply at least four review points for each AI system:

• Design review. Before substantial development resources are committed, a documented review of the system concept, identified risks, and the proposed risk treatment. Output: design-stage risk record. Decision: proceed to build, redesign, or do not proceed.
• Pre-pilot clearance. Before the system is used with real data, a review of the implemented controls against the design-stage risk treatment. Output: pilot clearance decision with explicit pilot scope and re-assessment triggers.
• Pre-production clearance. Before the system is used by a broader audience or production data flows, a review of the system as deployed. Output: production clearance decision with explicit conditions and re-assessment triggers.
• Ongoing review. Periodic reviews of the operating system, triggered by changes (model update, new tool, new data source) or by scheduled review cycles. Output: updated risk register and updated disposition.

Each gate produces evidence. The evidence at the pre-pilot gate is the pre-pilot clearance document. The evidence at the pre-production gate is the production clearance document. An auditor asking “how did you assure this system before going live?” expects to see these documents, not slide decks.

The standard names the requirements; you choose the artefact format. The following mapping is what most auditors expect to see for the most-examined clauses:

• Clause 5.2 (AI policy) — a documented AI policy approved at the senior leadership level. One to three pages. References the scope of AI use in the organisation and the principles that govern it.
• Clause 6.1.2 (AI risk identification) — for each AI system, a documented risk register. Includes the system context, the identified risks, the source of each risk (system component, data type, intended use, foreseeable misuse), and the date.
• Clause 6.1.4 (AI system impact assessment) — a documented impact assessment for systems where the AI policy requires one. Covers individuals, groups, society, and the organisation. Output: impact statement with mitigations.
• Clause 8.2 (AI system requirements and operation) — the operational record for each AI system. Includes the control plan from risk treatment, the evidence of control operation, the lifecycle gates passed, and the disposition record.
• Clause 9.1 (Monitoring, measurement, analysis and evaluation) — the monitoring record. What KPIs or KRIs are tracked, how they are measured, how often they are reviewed. For AI systems this includes both organisational metrics and per-system metrics.
• Clause 10.2 (Nonconformity and corrective action) — the corrective action register. Captures each identified nonconformity, the root cause analysis, the corrective action, and the verification that the action was effective.

Drel produces structured per-system records. The output of a Drel assessment maps directly to the evidence requirements of clauses 6 and 8 — the clauses an auditor will spend the most time examining.

Each Drel assessment produces: a documented risk register (clause 6.1.2 evidence), a documented control plan tied to the risk register (clause 6.1.3 evidence), a documented impact assessment if applicable (clause 6.1.4 evidence), a documented operational record covering the AI system lifecycle including clearance decisions (clause 8.2 evidence), and named re-assessment triggers (clause 9.1 evidence).

Drel does not produce evidence for clause 4 (Context), clause 5 (Leadership), clause 7 (Support), or the organisational portions of clause 9 and 10. Those require organisational governance work outside the scope of a per-system assessment tool. ISO 42001 is a management system standard; Drel supports the AI system records that the management system produces.

Most organisations approaching ISO 42001 already have ISO 27001 or are pursuing it. The two standards are structurally similar but cover different scopes. ISO 27001 covers information security management. ISO 42001 covers AI management. They overlap at data governance, access control, and incident management. They diverge at AI-specific concerns.

What ISO 42001 adds that ISO 27001 does not require:

• AI system lifecycle governance. Specific lifecycle steps for AI development, deployment, and decommissioning. ISO 27001 has change management; ISO 42001 adds AI-specific lifecycle requirements.
• AI impact assessment. A documented impact assessment for AI systems where the AI policy requires it. ISO 27001 does not require an analogous artefact for information systems generally.
• Model governance. Where models come from, how they are evaluated, how changes are managed. This is AI-specific and not addressed in ISO 27001.
• Transparency obligations. Where AI systems interact with affected persons, documented transparency about that interaction. Not an ISO 27001 concern.
• AI-specific risk taxonomy.The risk identification process must explicitly consider AI-specific risks (foreseeable misuse, bias, performance drift, adversarial input) that ISO 27001's information security risk taxonomy does not cover.

Where ISO 27001 controls are already in place — access controls on training data, secure software development for AI infrastructure, incident response — they form part of the ISO 42001 evidence base. The standards are designed to compose, not duplicate.