ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap That Policies Can't Close
ISO/IEC 42001:2023 is not a compliance checklist — it is a certification standard. The difference matters. A compliance checklist asks: do your policies say the right things? A certification audit asks: show me the evidence that your controls ran. For organisations deploying agentic AI, the most demanding ISO 42001 controls — Annex A.6.1.6 (operational logging enabling reconstruction of AI system behaviour) and the human oversight controls — both require the same thing: documented proof of what the AI system did, at the moment it did it.
- What ISO/IEC 42001:2023 is and who needs it
- Where agentic AI creates control gaps
- Annex A.6.1.6 — Operational logging and reconstruction
- Clause 9.1 — Monitoring, measurement, analysis and evaluation
- Human oversight controls — evidence, not the control itself
- The receipt chain as ISO 42001 audit evidence
- Cross-framework: one chain, three standards
What ISO/IEC 42001:2023 is — and why certification changes the evidence requirement
ISO/IEC 42001:2023 is the international standard for AI management systems, published in December 2023. It provides a structured framework — modelled on ISO 9001 and ISO 27001 — for organisations to establish, implement, maintain, and continually improve how they develop and deploy AI systems. Organisations already certified to ISO 9001 (quality management) or ISO 27001 (information security) will find the clause structure familiar: policy, risk assessment, operational controls, performance evaluation, and improvement.
The critical distinction between ISO 42001 and advisory frameworks like NIST AI RMF is what certification requires. ISO auditors do not accept policy documents as evidence of control operation. They require documented records — logs, receipts, decision records — that demonstrate controls ran during the period under audit. For agentic AI systems, this creates an acute problem: most AI governance tooling produces policies, dashboards, and reports. Very little produces per-action evidence that a control executed before the agent did.
ISO/IEC 42001 is not legally mandated in most jurisdictions, but it is increasingly referenced in procurement requirements, enterprise partner questionnaires, and as a conformity path for risk management obligations under regulation. Organisations pursuing ISO 42001 certification for AI are typically those already operating under ISO management systems — financial services, healthcare, manufacturing, critical infrastructure.
Where agentic AI creates control gaps
ISO/IEC 42001 Annex A defines the normative controls. Four areas are where agentic AI systems most commonly create evidence gaps during certification audits:
The audit failure pattern is consistent: organisations demonstrate strong policy controls (Clause 5, Clause 6 planning) but cannot produce per-action evidence for operational controls (A.6, A.7) and performance evaluation (Clause 9). The gap is not in governance intent — it is in the mechanism that would produce the evidence.
Annex A.6.1.6 — Operational logging and reconstruction of AI system behaviour
ISO/IEC 42001 Annex A.6.1.6 requires that organisations implement operational logging for AI systems at a level that enables reconstruction of AI system behaviour. The word "reconstruction" is precise. It is not sufficient to log that a sequence ran — the log must enable a complete picture of what the system did, in what order, at what time, and under what conditions.
For agentic AI, the failure mode that this control targets is probabilistic behaviour: a model that skips a step, infers a condition was met, or proceeds without explicit authorisation. If the only log is a model-generated output report, reconstruction is impossible — the model's report of what it did may not reflect what actually ran.
How sequence enforcement addresses it: Every gate decision — ALLOW or DENY — is written to tamper-evident storage before the agent step executes. The receipt records the sequence ID, step, function, action type, the gate decision, a UTC timestamp, a payload hash, the previous receipt's hash, the signing key ID and algorithm, and a cryptographic pack ID. Each receipt carries prev_receipt_hash — a SHA-256 of the previous receipt's full signed content — alongside prev_receipt_id, so altering any earlier receipt breaks the hash chain at the next link and is detectable. To reconstruct exactly what ran, in what order, at what time: read the chain. The chain is the reconstruction. It is not derived from model output — it is written by the enforcement layer at the moment each step is decided.
Audit evidence produced: The verification report generates a full chain proof — per-step enforcement log, Ed25519 signature verification for every receipt, hash-link verification from step 0 → N, a comparison against an independently held archive copy, and a plain-language compliance narrative. This produces the documented, reconstructable record Annex A.6.1.6 calls for. It does not, on its own, discharge the obligation — that stays with the organisation — but it is the evidence an auditor asks to see.
Clause 9.1 — Monitoring, measurement, analysis and evaluation
ISO/IEC 42001 Clause 9.1 requires that organisations determine what needs to be monitored and measured, what methods are appropriate, and when analysis and evaluation should occur. For agentic AI systems making consequential decisions, appropriate intervals means per-action — not per-session, not daily dashboards, not weekly reports.
The common implementation gap is treating Clause 9.1 as a reporting requirement. Aggregate metrics satisfy the letter of the clause for low-risk systems. For agentic AI in regulated contexts — underwriting, hiring, clinical triage, access control — an auditor will ask: how do you know the system behaved correctly on this specific decision, at this specific time? Aggregate metrics cannot answer that question.
How sequence enforcement addresses it: Gate statistics are recorded per-decision: total evaluations, ALLOW/DENY ratios, step distribution, sequence completion rates, and denial reason codes. These are written on every gate call and surfaced in the dashboard in real time. For Clause 9.1, this provides monitoring that is contemporaneous with execution at the granularity the clause asks for — every action, not every session. The receipt chain enables full retrospective analysis: which steps were denied, at what timestamps, for what reason, across how many sequences.
Human oversight controls — the gate is the evidence, not the control
ISO/IEC 42001 Annex A.7 defines human oversight controls — the mechanisms by which humans can review AI system behaviour and intervene when needed. For agentic AI, the critical test is not whether a human could intervene, but whether the process actually routes decisions to human-controlled authorisation before the system proceeds.
The audit failure here is structural: if the AI system can run a complete sequence without any human-controlled checkpoint, then human oversight is an option, not a control. A certification auditor will ask: show me the mechanism, and show me it fired. A policy that says "humans review outputs" is not a mechanism — it is a procedure.
Be precise about what enforcement is and isn't: sequence enforcement does not, by itself, constitute the human review-and-intervention control A.7 describes. A person reading and approving an AI decision is an organisational measure, and it stays yours. What the gate provides is the evidence layer beneath that control. No agent step executes without clearing the gate; the model cannot self-authorise or replay a previously issued ALLOW; and where your process requires a human to authorise a step, that authorisation can be bound into the receipt as a signed attestation — so the record shows the human step happened, at that point, before the sequence continued. The oversight is yours to design and to run. The gate makes it evidenced rather than merely asserted.
Audit evidence produced: Denial logs showing the gate blocked non-compliant steps before execution, with timestamps and reason codes. Bound human-authorisation attestations, where your process requires them. Sequence seal records showing that a completed sequence cannot silently accept new steps. Each DENY is evidence a step was stopped before it ran — a record written at the moment of the decision, not a report assembled afterward.
The receipt chain as ISO 42001 audit evidence
ISO 42001 certification audits require documented evidence. The receipt chain AgenticRail produces is designed to be that documentation — not a report generated after the fact, but a record written at the moment of each enforcement decision.
Each receipt is cryptographically signed using a versioned key — Ed25519 for current receipts, legacy HMAC for anything signed before 2026-06-07. The signature covers a canonical JSON serialisation — alphabetically sorted, deterministic. Every receipt records the sequence ID, step, function, action type, gate decision, timestamp, a payload hash, the signing key ID and algorithm, and a pack ID. Receipts are hash-linked via prev_receipt_hash (a SHA-256 of the previous receipt's full signed content) alongside the prev_receipt_id reference. If every signature and hash link verifies, no receipt has been altered or reordered since it was written; if a link fails to verify, the break is provable. Optional attestation fields — KYC results, risk scores, approval IDs, document hashes — are signed into the receipt at the step they apply to.
One honest limit, stated plainly because an auditor will ask it: the party running the gate holds the signing key, so the signatures and the hash chain alone cannot catch that same party rewriting an entire chain end to end. AgenticRail closes this by also writing a write-once copy of each sealed record to a separately held archive, and the verification report compares the live chain against it. A downstream rewrite shows up as a mismatch against a copy the operator cannot reach. The chain proves nothing was altered in place; the independent archive is what catches a wholesale rewrite.
For an ISO/IEC 42001 certification audit, the receipt chain provides documented evidence against three control areas:
- →A.6.1.6 evidence: Per-step enforcement log with timestamps. Full receipt chain enabling reconstruction of every sequence. Hash-link proof — tamper-evident from step 0 to seal, plus the independent-archive comparison.
- →Clause 9.1 evidence: Per-action decision records. ALLOW/DENY statistics at sequence and step level. Denial reason codes enabling root-cause analysis of blocked steps.
- →A.7 evidence: Denial records showing the gate blocked non-compliant steps before execution. Bound human-authorisation attestations where your process requires them. Sequence seal records — showing a completed sequence cannot silently accept new steps.
You can verify any sequence yourself at the verification tool — paste a sequence ID and it returns the per-step enforcement log, the signature and hash-link checks, the independent-archive comparison, and a plain-language narrative:
The report is the record of what the enforcement layer did, alongside the organisational controls that remain yours. Whether it belongs in your ISO/IEC 42001 management system documentation, certification evidence package, or management review records is your auditor's judgement, not ours.
Cross-framework: one chain, three standards
ISO/IEC 42001, the EU AI Act, and NIST AI RMF all converge on the same operational evidence requirement: proof that oversight mechanisms functioned during deployment. The clause numbering differs; the underlying gap is the same.
- →ISO/IEC 42001 Annex A.6.1.6 — operational logging enabling reconstruction of AI system behaviour. The receipt chain provides the reconstruction record.
- →EU AI Act Article 12 — record-keeping sufficient for post-market monitoring and traceability. The same receipt chain produces the logging evidence the article calls for.
- →NIST AI RMF Measure 2.4 — risk-appropriate performance monitoring with results used to inform risk treatment. The per-action receipt record is the monitoring evidence.
You build the enforcement layer once, and the evidence it produces maps across all three frameworks — because all three are asking the same question: can you show your controls actually ran? The evidence maps. The obligations stay yours.
One enforcement layer. Evidence for ISO 42001, EU AI Act, and NIST AI RMF — the obligations stay yours.
Run a demo sequence and generate a verification report in about a minute — no signup required. The report shows the receipt chain, the hash-link and signature proofs, the independent-archive comparison, and a per-step enforcement log suitable for ISO 42001 audit evidence.