What does ISO 42001 A.6.2.8 require?

ISO/IEC 42001:2023 Annex A control A.6.2.8 requires organisations to record events relevant to the operation of AI systems to support auditability, incident investigation, and performance evaluation. The control does not specify when events must be recorded (before or after execution), what format the records must take, what integrity or tamper-evidence requirements apply, or how records for a multi-step sequence must be linked to each other. This leaves significant implementation discretion — and significant audit ambiguity — for organisations deploying agentic AI.

Why is ISO 42001 A.6.2.8 difficult to satisfy for agentic AI?

Agentic AI systems execute multi-step workflows autonomously — each step is a discrete action that may involve tool calls, data access, or external system interactions. Standard application-layer logging records what the agent reported happening, after execution. A.6.2.8's purpose — supporting auditability and incident investigation — requires more than a description of what ran. It requires records that can prove what policy governed each step, whether any steps were blocked, and whether the record itself is complete and unmodified. Post-hoc logs written by or through the agent cannot satisfy these requirements because the agent itself cannot produce tamper-evident records of its own enforcement.

What are the four gaps in ISO 42001 A.6.2.8?

The four requirements A.6.2.8 does not specify are: (1) Timing — the standard requires events to be recorded but does not require that the record be written before the action executes. Pre-execution recording is what makes a log an enforcement receipt rather than a description. (2) Format — no required fields, schema, or minimum content are defined. Two organisations can produce completely different records and both claim A.6.2.8 compliance. (3) Integrity — no signing, hashing, or tamper-evidence mechanism is required. Records that can be modified after the fact cannot support incident investigation or legal proceedings. (4) Chain linkage — no requirement that records for a multi-step sequence be linked, preventing detection of gaps or deletions in the audit trail.

What evidence should an ISO 42001 auditor demand for agentic AI under A.6.2.8?

A technically rigorous A.6.2.8 audit for agentic AI should demand: (1) Evidence that records were written before each action executed, not derived from outputs after the fact; (2) A defined record schema showing which fields are captured and what each represents; (3) Cryptographic integrity protection — HMAC or similar — over all fields, verifiable with a documented key; (4) Chain linkage between sequential records enabling detection of gaps; (5) DENY records for blocked actions, not just ALLOW records for permitted ones — a complete audit trail includes what was stopped. Most organisations presenting standard application logs cannot satisfy requirements 1, 3, 4, or 5.

Does AgenticRail satisfy ISO 42001 A.6.2.8?

AgenticRail's pre-execution enforcement gate directly addresses all four gaps in A.6.2.8: receipts are written before the gate returns a decision (timing); the slp8_receipt_v2 schema defines all required fields (format); receipts are HMAC-SHA256 signed over canonical JSON before storage (integrity); each receipt includes a prev_receipt_id SHA-256 chain link (chain linkage). DENY receipts — for SEQUENCE_VIOLATION, REPLAY_NONCE, and ACTION_NOT_ALLOWED — are recorded regardless of whether execution was attempted, satisfying the completeness requirement. The published schema at agenticrail.nz/spec/receipt-schema.json gives auditors the formal specification to assess against.

Published 23 May 2026 · AgenticRail

ISO 42001 A.6.2.8: The Event Log Control Auditors Can't Enforce Yet

ISO/IEC 42001:2023 Annex A control A.6.2.8 requires organisations to record events relevant to the operation of their AI systems. It does not specify when those records must be written, what they must contain, how they must be protected against modification, or how records for a multi-step sequence must be linked. Auditors are currently accepting whatever organisations present. For agentic AI, that ambiguity is a structural risk — not because organisations are ignoring the control, but because the control doesn't define what good looks like.

AgenticRail's pre-execution enforcement gate satisfies all four gaps in A.6.2.8. Published receipt schema, HMAC-signed records, chain-linked entries, DENY receipts included.

View receipt schema Try the demo →

What A.6.2.8 actually says

ISO/IEC 42001:2023 is structured like ISO 27001 — a management system standard with a normative body (Clauses 4–10) and a normative Annex A of controls. Clause 6 of Annex A covers AI System Lifecycle. Control A.6.2.8 sits within the operational deployment section:

ISO/IEC 42001:2023 — Annex A — Control A.6.2.8

The organisation should ensure that appropriate event logs relating to the operation of the AI system are recorded to support auditability, incident investigation, and performance monitoring of the AI system.

Paraphrase of normative text. Source: ISO/IEC 42001:2023 Annex A, Section A.6 AI System Life Cycle, A.6.2 Operation.

The control is clear on purpose: support auditability, incident investigation, and performance monitoring. It is silent on everything required to actually achieve that purpose for agentic AI systems.

The four things A.6.2.8 doesn't specify

Four technical requirements are absent from A.6.2.8. Each one is straightforward to satisfy in a well-designed system — and each one is routinely absent from the application-layer logs organisations present as A.6.2.8 compliance evidence.

Gap 1

Timing — pre-execution vs post-execution

A.6.2.8 says records must support auditability. It does not say when the record must be written relative to the action it records. Post-hoc logs describe what happened. Pre-execution receipts prove what was enforced before it happened. For incident investigation, only pre-execution records can prove that enforcement ran — because post-hoc logs are produced by or after the system under investigation. An AI agent that has been compromised, jailbroken, or misconfigured can produce post-hoc logs that describe compliant behaviour while the underlying actions were not compliant.

Gap 2

Format — no required fields, no schema

A.6.2.8 requires that "appropriate" events are recorded. It defines no minimum fields, no schema, no required identifiers. Two organisations can implement completely different logging systems and both claim A.6.2.8 compliance. Auditors have no standard to measure against. Without a defined schema, there is no way to verify completeness — no way to confirm that all required fields are present, that action types are recorded, that policy basis is captured, or that denial events are included alongside permit events.

Gap 3

Integrity — no tamper-evidence requirement

A.6.2.8 requires records that support incident investigation. It does not require that those records be cryptographically protected against modification. Logs that can be modified after the fact cannot support legal proceedings, regulatory inquiries, or adversarial incident investigations. An unprotected log file is not audit evidence — it is a document that describes what someone recorded. A tamper-evident record with a cryptographic signature over all fields is evidence that cannot be denied or selectively edited without detection.

Gap 4

Chain linkage — no sequence integrity requirement

Agentic AI systems execute multi-step sequences — each step a discrete action, each action recorded as a separate event. A.6.2.8 requires that events are recorded. It does not require that records for a sequence are linked to each other. Without chain linkage, there is no way to detect gaps in the record — a deleted step, an inserted fabricated step, or a truncated sequence all appear identical to a genuine record. Chain linkage via prev_receipt_id SHA-256 makes any gap or insertion detectable by anyone with the receipt chain.

Why this creates compliance theatre for agentic AI

Because A.6.2.8 doesn't define what good looks like, auditors are currently in an impossible position. They cannot demand pre-execution timing from organisations whose standard specifies none. They cannot reject un-signed logs when the standard imposes no integrity requirement. They cannot require chain-linked records when the standard has no chain concept.

What ISO 42001 auditors are currently accepting as A.6.2.8 evidence

Application-layer log files describing what the AI agent reported doing. Tool call outputs. LLM reasoning traces. Observability platform dashboards. Post-deployment monitoring reports. These records were written after actions executed, often by the agent itself, may omit failed or blocked actions, carry no cryptographic integrity protection, and are not linked to each other across a sequence.

An auditor reviewing these records can confirm that logging is in place. They cannot confirm that enforcement ran before execution, that the logs are complete, that they have not been modified, or that any out-of-order or disallowed actions were detected and blocked.

Two organisations can present radically different implementations to the same auditor — one with post-hoc application logs written by the model, one with pre-execution HMAC-signed receipt chains written by an enforcement gate before each action — and both currently pass A.6.2.8. That is compliance theatre: the audit passes, but the evidence standard is undefined.

The Cloud Security Alliance confirmed this directly in their April 2026 research note on AI agent governance: ISO 42001 "lacks real-time policy enforcement mechanisms for autonomous multi-step task execution" — the standard documents the intent but not the mechanism required to satisfy it for agentic systems.

What a technically rigorous A.6.2.8 implementation requires

Satisfying the purpose of A.6.2.8 — genuine auditability, incident investigation capability, and performance monitoring — for agentic AI requires addressing all four gaps:

Requirement 1

Pre-execution timing

The record must be written before the gate returns a decision to the caller — not after the action executes, and not derived from outputs. Only a gate that sits between the agent's reasoning and the action's execution can write this record. The gate writes and signs the receipt, then returns ALLOW or DENY to the caller. The agent cannot modify the receipt after the fact because the receipt was written before the agent received permission to act.

Requirement 2

Defined schema with required fields

A published schema defining minimum required fields: sequence identifier, step identifier, function, action type, decision (ALLOW/DENY/HALT), denial reason code if applicable, policy basis, timestamp, nonce, and signing key identifier. The schema gives auditors a specification to assess against — not a subjective judgement about whether "appropriate" events were recorded. AgenticRail's slp8_receipt_v2 schema is published at /spec/receipt-schema.json.

Requirement 3

Cryptographic integrity protection

HMAC-SHA256 computed over a canonical serialisation of all receipt fields before the receipt is stored. The signing key identifier is included in the receipt so auditors can verify the signature without needing to reconstruct which key was used. Verification is offline — an auditor with the public key and the receipt chain can confirm integrity without access to the live system. Receipts that fail HMAC verification indicate post-storage modification.

Requirement 4

Chain linkage via prev_receipt_id

Each receipt includes a SHA-256 hash of the previous receipt in the sequence, included in the HMAC computation. Any gap, deletion, or insertion in the receipt chain breaks the hash chain and is immediately detectable. An auditor reconstructing a sequence from the receipt chain can verify that it is complete and unmodified — not just that records exist, but that no records are missing.

DENY receipts are as important as ALLOW receipts

A complete A.6.2.8 implementation records both permitted and blocked actions. Most application-layer logs only record what ran — they have no mechanism to record what was stopped before it ran, because the logging system is invoked after the action starts.

For agentic AI, blocked actions are often the most important records. A SEQUENCE_VIOLATION receipt proves that an out-of-order step was detected and blocked before execution — not discovered after the fact from downstream anomalies. A REPLAY_NONCE receipt proves that a replay attempt was caught. An ACTION_NOT_ALLOWED receipt proves that a disallowed action type was blocked at the gate.

What auditors should ask about denial records

Can you show me a record of actions your AI system attempted that were blocked? If the answer is "our logs only show what ran successfully," the enforcement evidence for A.6.2.8 is incomplete. A system that only records permitted actions cannot demonstrate that its enforcement layer caught violations — only that violations didn't happen to occur during the audit period.

How AgenticRail satisfies A.6.2.8

A.6.2.8 requirement	Standard application logs	AgenticRail receipts
Pre-execution timing	Written after execution — describes what ran, cannot prove enforcement ran before it	Receipt written and signed before gate returns ALLOW — pre-execution by architecture
Defined schema	Varies by implementation — no published specification for auditors to assess against	slp8_receipt_v2 JSON Schema published at /spec/receipt-schema.json — auditable specification
Cryptographic integrity	No signing — records can be modified after the fact without detection	HMAC-SHA256 over canonical JSON — verifiable offline with signing key ID included in receipt
Chain linkage	No linking between records — gaps and deletions undetectable	prev_receipt_id SHA-256 — any gap or insertion breaks the chain and is immediately detectable
Denial records	Blocked actions typically absent — logging invoked after execution starts	Every DENY recorded regardless of whether execution was attempted — SEQUENCE_VIOLATION, REPLAY_NONCE, ACTION_NOT_ALLOWED all captured

What a compliant A.6.2.8 receipt looks like

The receipt below is a real AgenticRail enforcement decision record. It contains everything required for A.6.2.8 auditability — policy basis, pre-execution timestamp, HMAC signature, and chain link to the preceding receipt in the sequence.

A.6.2.8 receipt — sequence: risk-eval-4471a / step: credit_check ALLOW

decision ALLOW — all pre-execution conditions passed

policy basis credit_check · VALIDATE_INPUT · step 2 of 5 in declared sequence

timing written before gate returned ALLOW — credit_check had not yet executed

hmac sha256:c3f9… over canonical JSON — verifiable offline, key_id: k1_2026-02-22_01

prev_receipt_id sha256:a17b… — links to step 1 receipt, chain intact

A.6.2.8 receipt — sequence: risk-eval-4471a / step attempted: approve_credit DENY

decision DENY — SEQUENCE_VIOLATION

violation approve_credit attempted at step 3. Expected: fraud_check. Steps 3–4 not completed.

timing written before approve_credit executed — credit approval did not proceed

A.6.2.8 value Proves enforcement caught the violation — incident investigation evidence, not post-hoc description

The DENY receipt is the A.6.2.8 evidence most auditors will never see with standard logging — because standard logging has no mechanism to record an action that was blocked before it ran.

Evidence checklist for your A.6.2.8 audit

What to bring to your ISO 42001 certification audit — A.6.2.8 agentic AI

✓

Published receipt schema

Link your auditor to your record schema specification. The schema must define all fields, types, and the fields included in the HMAC computation. AgenticRail: /spec/receipt-schema.json.

✓

Pre-execution timing evidence

Document that the enforcement gate writes the receipt before returning a decision — and that the decision is required before the action can proceed. Architecture diagram showing gate placement between agent reasoning and action execution.

✓

HMAC verification walkthrough

Demonstrate that a receipt can be verified offline using the key ID embedded in the receipt. Show a live verification against a receipt from a production sequence. AgenticRail: compliance report at report.agenticrail.nz.

✓

Chain integrity demonstration

Show that prev_receipt_id links are present across a complete sequence and that any break in the chain is detectable. The compliance report renders the full receipt chain with chain verification status for each step.

✓

DENY receipt examples

Produce at least one SEQUENCE_VIOLATION, REPLAY_NONCE, or ACTION_NOT_ALLOWED receipt demonstrating that the enforcement layer records blocked actions. These are the records that prove enforcement ran — not just that permitted actions were logged.

✓

Retention documentation

Document that receipts are stored in immutable, append-only storage and the retention period. R2 with object-level versioning, S3 with object lock, or equivalent. Show that the storage layer cannot modify or delete individual receipts.

What happens when DIS 24970 is finalised

ISO/IEC DIS 24970 — AI system logging and transparency — is currently in Draft International Standard stage, targeting Q4 2026 finalisation. DIS 24970 will define specific requirements for AI system logging that go significantly further than A.6.2.8's current language. When it is published, ISO 42001 A.6.2.8 implementations will be assessed against a concrete technical specification rather than the current "appropriate events" language.

What DIS 24970 will change for A.6.2.8 audits

DIS 24970 is expected to address the four gaps directly — timing (pre vs post execution), format (receipt schema requirements), integrity (cryptographic requirements), and chain linkage. Organisations building pre-execution enforcement receipt infrastructure now will be ahead of the tightened standard. Organisations relying on post-hoc application logs will face a compliance gap when DIS 24970 is adopted — and will be rebuilding infrastructure under deadline pressure that early movers built without it.

AgenticRail's slp8_receipt_v2 schema was published in May 2026 — predating the finalised standard. When DIS 24970 is adopted, the schema represents documented prior art for the pre-execution receipt architecture the standard will describe.

Pre-execution receipts for A.6.2.8 — HMAC-signed, chain-linked, schema-published, 1M+ decisions in production. See the full compliance report with receipt chain verification.

View compliance report Try the demo →