SekitCrosswalk
ISO/IEC 42001:2023 — Annex A · derived mapping target

A.6.2.8AI system recording of event logs

Record security, operational and decision-relevant AI events with adequate content, time integrity, protection and retention.

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

ISO/IEC 27001:2022 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

NIST CSF 2.0 counterparts

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

AI system monitoring and event logs
How AI systems are watched once in use, and what gets recorded: monitoring of performance, drift, misuse, harmful outputs and control failures against set thresholds and defined responses, and what the event log captures about inputs, outputs, decisions and human overrides.
From the Sekit evidence catalog

In practice

This means the AI system's inputs, outputs, decisions and human overrides get logged with enough detail and a trustworthy timestamp to reconstruct what happened, not only that something ran. For a support chatbot that means keeping sample transcripts, confidence scores, and every case where a human overrode the answer. An auditor asks for the AI system monitoring and event logs and checks three things: are drift and misuse thresholds set, do the logs feed the same central platform as everything else, and is retention long enough to investigate an incident after the fact. The usual gap is a vendor tool with no logging access at all.

Common gaps

A team adopts a vendor AI tool that offers no export of its own logs, so overrides and errors leave no trace anywhere.
Drift and misuse thresholds are never defined, so nobody would notice a chatbot quietly degrading or being misused for weeks.
AI event logs sit in the vendor's own dashboard instead of the central logging platform, so retention and access controls diverge from the rest of the estate.

Questions your auditor will ask

How do you know if this AI system starts producing harmful or wrong outputs?
Monitoring against defined thresholds for drift, misuse and harmful outputs, recorded in the AI system monitoring and event logs, with a defined response when a threshold is crossed.
Where are this AI system's logs stored, and for how long?
Logs feed the same central logging platform as other systems, with retention set and applied consistently rather than left to the vendor's default.
Can you show me a case where a human overrode the AI's output?
Sample logs of inputs, outputs and human overrides are kept in the event log record, so a specific override can be pulled and reviewed.
Who reviews these logs, and how often?
A named security or IT owner reviews the AI system monitoring and event logs on a fixed cadence, for example monthly, checking thresholds, drift signals and any override that was never followed up.

Where regulation demands it

GDPR's security-of-processing duty (32.1.b) covers AI systems that handle personal data: without event logs you cannot show integrity or investigate a failure.
NIS2 art. 3.2 (Monitoring and logging) does not carve out an exception for AI; a chatbot or model needs the same log discipline as any other system.
Ask Sekura: “What evidence proves A.6.2.8?”
Also via MCP, free with account