A.6.2.8 AI system event logs: requirements and evidence

What A.6.2.8 AI system recording of event logs asks you to decide

A.6.2.8 asks your organization to make a documented decision about the phases of the AI system life cycle in which event logs are recorded, and it sets a floor: recording must be enabled at minimum while the AI system is in use. An auditor or customer questionnaire asking for AI logging evidence is really asking two things: did you decide deliberately which phases generate logs, and can you show the logs exist, are kept and can be read when something goes wrong. The control addresses undetected misbehavior, such as a model drifting into unsafe outputs or an agent calling a tool it should not, and weak incident investigation, where teams cannot reconstruct what the system received, decided and returned. The control sits in the same A.6.2 life cycle area as A.6.2.6 AI system operation and monitoring, and the A.6.2 group holds seven controls in total, A.6.2.2 to A.6.2.8.

It is harder than it looks because logs are usually produced by default but not scoped for AI. Infrastructure and application logs may capture a login or an HTTP request, yet not the prompt version, model version, retrieval sources, tool calls, human overrides or output decisions that matter for an AI system. Retention is often set by a generic platform policy, and the logs may sit on the same host with the same administrators they are meant to check. Your first decisions should be a phase matrix covering development, testing, deployment and operation, the event categories required in each phase, a retention period tied to your incident and audit obligations, and an integrity approach such as restricted write access, separate storage and tamper-evident records. Confirm the exact retention and integrity expectations with your certification body and any sector regulator before you fix them.

Document each decision in a way an assessor can trace from the control to a configured system. Self-hosted tools can supply part of the evidence: Nextcloud's admin_audit app can write extra event information to a dedicated audit log, OpenBao audit devices record detailed API request logs with sensitive values hashed, and tracing tools such as Langfuse capture inputs, outputs, tool executions and token usage for LLM workflows. Confirm each platform's current capabilities and log formats against its documentation before you rely on them, because the logs you need for AI events may still require custom instrumentation. The international logging standard ISO/IEC FDIS 24970 on AI system logging is at ballot stage, so treat its information model as a direction to watch rather than a current requirement.

Which AI systems, phases and data sources the log decision covers

A.6.2.8 only works if the organization first settles which AI systems, life cycle phases and data sources fall inside the logging decision. Each card below is a scoping choice that changes the logging work, and each one should be recorded in the statement of applicability with its justification.

In-house versus third-party models

Logging duties differ depending on whether the organization trains or hosts its own model or calls a model through a vendor API. With an in-house model, the organization controls inference servers and their logs directly. With a third-party model, it can usually log only its own calls, prompts, outputs and errors, and must confirm what the provider retains. Record which model sources are in scope and what the vendor contract says about log access and retention.

AI features inside SaaS products

When an existing SaaS tool adds AI features, the organization may be a user rather than the builder of the AI system. Its logging decision still applies to the AI behavior it deploys or configures, such as enabled features, data sent to the feature and admin settings that change model behavior. Ask the vendor which AI events it logs, whether those logs can be exported, and how long they are kept.

Development, test and production environments

A.6.2.8 requires logging at a minimum while the system is in use, but the organization decides whether development and test environments also record events. Test runs often reveal the failures that matter later, so logging test evaluations can serve as verification evidence under A.6.2.4. Decide and document each environment separately, and keep test logs from containing production personal data unless that use is justified.

Application and model gateway logs

The application layer records user requests, responses and errors, while a model gateway records which model served each call, with what parameters and at what cost. Together they show who triggered an AI action and which model produced it. Confirm that both sources share a request identifier, so an investigator can follow one interaction across components.

Retrieval and tool call logs

Retrieval-augmented systems and agents act through data lookups and tool executions that can change outcomes without appearing in the final answer. Log which documents were retrieved, which tools were invoked, with what arguments and what each returned. Without these records, an incident such as a wrong action taken by an agent cannot be traced to its cause.

Administrative and configuration actions

Changes to prompts, model versions, guardrails, access rights and data connections alter AI behavior as much as code releases do. Admin actions should therefore be in scope, and the organization should confirm that its platform writes them to a protected log. Include who made each change, when it took effect and which system it affected.

What to log at each life cycle phase while the system is in use

Start with the minimum that A.6.2.8 sets: event logging must be enabled at least while the AI system is in use. The organization still has to decide, and document, whether logging also runs during design, verification and validation, deployment and decommissioning. A practical approach is to record the phases where the system's behavior can change or where a fault would be hard to reconstruct later, such as test runs against release candidates and each deployment or rollback. Each phase decision should appear in the operating record so an assessor can see the reasoning, not just the setting. Confirm the exact phase list with your own certification body or advisor before you finalize it, because the standard leaves the choice to the organization.

For the in-use phase, the event categories that usually matter most are: inputs and outputs where you have a lawful basis to keep them, the model and version identifiers that produced each output, configuration and prompt or policy changes, access and administrative events, errors and timeouts, human override or rejection actions, and tool executions the system triggered. Model and version identifiers are often the most overlooked, because without them you cannot tie an incident to the model that produced it. Open-source tooling can capture several of these categories. For example, Langfuse traces record LLM calls, retrieval steps and tool executions with timing and metadata, and OpenBao audit devices log API requests and responses. Check each vendor's documentation for what it records by default and what it omits.

Logs are also personal data in many cases, so the design has to resolve a tension between traceability and privacy. Capture the fields you need to investigate an event and avoid storing full prompts or outputs when a summary, hash or reference will do. Set a retention period for each category, restrict who can read raw content, and treat prompts with personal data as a DPIA question under GDPR where the system processes it. Integrity matters as much as content: decide how logs are protected from alteration, where they are stored, and who can export them. Ask your logging vendor or integrator to show how each event type is written, filtered and retained in your environment, and record those answers as evidence.

How to implement event logging for an AI system, step by step

This sequence turns A.6.2.8 into working evidence: it fixes which life cycle phases are logged, defines what each entry contains, moves logs into protected storage, and proves the trail supports monitoring and incident investigation.

Inventory AI systems and their life cycle phases
The system owner, with the AI governance lead, lists every AI system in scope, including systems built in-house, embedded in SaaS products and used through third-party APIs. For each one, the team records the life cycle phases it passes through, from design and development through verification, deployment, operation and retirement. The output is an AI system register that names an accountable owner and the phases where the system is active. Done means every system in scope appears with its phases and owner, and the register has been reviewed against the list of AI systems in the AI management system scope.
Decide logging phases and write the logging decision record
The governance lead and the system owner decide, for each system, the phases where event logging is enabled. A.6.2.8 requires logging to be enabled at a minimum while the system is in use, and the decision record explains why any earlier phases such as development or testing are logged or excluded. The record also states the justification for each choice, so an assessor can follow the reasoning. Output: a logging decision record per system, signed off by the owner. Done means every phase has a recorded decision and the rationale is traceable to the risk assessment.
Define the log schema for each system
The engineering team defines the fields each event record must carry, such as timestamp, system and model version, requester or service identity, input and output references, tool or retrieval calls, human override actions, errors and policy decisions. Sensitive content such as personal data or prompts should be stored as references, hashes or redacted values where full content is not needed for investigation. The output is a versioned log schema with field definitions and an example record. Done means the schema covers what the monitoring and incident response procedures in A.6.2.6 need, and privacy reviewers have signed off on any personal data fields.
Configure collection and central storage
The platform team enables logging in each component of the AI system and routes records to a central, access-controlled store inside the organization's own environment. Each platform has its own mechanism: for example, Nextcloud's admin_audit app writes additional event information to audit.log or to a path set with logfile_audit, OpenBao audit devices keep a detailed JSON log of every API request and response with most sensitive values hashed with HMAC-SHA256, and Langfuse traces capture operations such as LLM calls, retrieval steps and tool executions. Done means a test event from each phase arrives in the central store with every schema field populated, and the team has confirmed the configuration for each platform against its current documentation.
Set retention and integrity controls
The security and compliance leads set a retention schedule for each log category, based on the decision record, legal obligations and the organization's own policy, and document who may read, export or delete logs. They also set integrity controls, such as write-once or append-only storage, restricted administrator rights, time synchronization and periodic checks that records have not been altered. Output: a retention schedule and an integrity control description. Done means the schedule is approved, deletion requires a recorded approval, and a test attempt to alter a stored record is detected or blocked. Confirm specific retention periods with legal counsel, since none are set by the standard.
Connect logs to monitoring and incident response
The operations team builds alerts and dashboards on the logged events, covering errors, policy violations, unusual tool use, output anomalies and access by unexpected identities. The incident response runbook is updated so responders know which logs to pull, how to preserve them and who decides whether an event is an AI incident. Where AI security testing tools such as garak are used, their JSONL reports and hit logs are stored alongside production logs as evidence of testing. Output: alert rules, a dashboard list and an updated runbook section. Done means a simulated incident can be traced from alert to the originating log entries within the team's own procedure.
Document and test the logging control
The compliance lead writes the control procedure, links it to the statement of applicability entry for A.6.2.8, and records each test of the chain from event to storage to alert to investigation. The test log extract, with dates, the tester and results, becomes the audit evidence. Independent reviewers or an external assessor test the control later; an implementation partner can prepare the evidence but does not issue assessment conclusions. Done means the procedure is approved, at least one end-to-end test is recorded for each in-scope system, and gaps are logged in the improvement process.

How an assessor tests A.6.2.8 and which findings are common

This table sets out how an assessor typically tests A.6.2.8, the evidence requested for each test and the findings that recur in audits. Read each row as a question the assessor will ask, then check whether your records answer it before the audit starts.

Test step	Evidence requested	Common finding
Review the documented decision on logging phases	Written decision stating which life cycle phases record event logs, the rationale and the approval record	No documented phase decision, or a decision that covers only development and omits production use
Sample systems in use to confirm logs exist	Log extracts from production for a sample of AI systems, with timestamps covering the review period	Logs missing for production model calls, or logging switched off after a release
Check log content against the defined schema	Log schema or field list and sample entries showing inputs, outputs, versions, user or service identity and timing	Fields defined in the schema are absent or empty in real entries, and no owner for the schema
Verify retention and access restrictions	Retention rule, storage location, access list and evidence that retention is applied	No retention period set, logs readable by all engineers, or logs kept only on the application host
Verify integrity protection	Description of how logs are protected from alteration, such as write-once storage or hashing, and how tampering is detected	Logs with no integrity or access control, so entries can be edited without trace
Trace a sample event to an incident or monitoring review	Selected event, the monitoring alert or incident ticket it fed, and the follow-up record	Logs exist but no monitoring or investigation uses them, so the event cannot be traced to a review

Evidence that shows event logging is decided, running and reviewed

An assessor testing A.6.2.8 will look for three things: a recorded decision about which life cycle phases produce logs, logs that exist in production, and proof that someone reads them. The cards below cover the artifacts for each, and the routine that keeps them current between audits.

Logging phase decision record

A dated record that names each life cycle phase where event logging is enabled, the reason for each choice, and the phases where logging is excluded and why. A.6.2.8 expects logging to be on at a minimum while the system is in use, so the record must show that operation is covered. Tie each phase to the design and deployment decisions made under A.6.2.3 and A.6.2.5, and have the approver sign it.

Event log schema

A versioned document listing every field the system writes per event, such as timestamp, actor, model or component version, input and output references, tool calls, and error states. Note which fields are personal data and how they are masked. Assessors compare the schema against the decision record: a phase marked as logged should have fields that let an investigator reconstruct what happened.

Production log extracts

Redacted samples pulled from the live system, showing real entries for normal operation, a configuration change, and an error or refused request. Samples prove that logging runs in production rather than only in a test environment. Keep the sample set dated, record where each extract came from, and confirm that no secrets or unmasked personal data appear in the copy you store.

Retention and access configuration

Exported settings showing where logs are written, how long they are kept, who can read them, and who can delete or change them. Confirm the retention period with your legal and risk owners, since it often depends on sector rules and on the EU AI Act record-keeping duties where they apply. Access should be limited to monitoring and security roles, with each grant traceable to an approved request.

Log integrity checks

Evidence that logs cannot be silently altered, such as write-once storage, hash chains or signed batches, and the results of periodic verification runs. Record what the check covers, how often it runs, and what happens when a check fails. A failed integrity check should generate an alert and an incident record, not just a log line.

Log review and investigation records

Tickets, dashboard snapshots and incident reports that show logs were used: a monitoring alert triggered by a log pattern, a drift or misuse review, or a post-incident reconstruction. An unused log stream is hard to defend, so assessors ask for at least a few examples. Record who reviewed, what they found and what changed as a result.

Keeping evidence current between audits

Schedule configuration exports, such as a monthly export of retention and access settings, and quarterly sample pulls of production logs with a checklist showing each review. Store the outputs in the same evidence repository as the decision record and tag each item with the system version it describes. Ask your implementation partner and auditor to agree on this cadence before work starts so the evidence is not rebuilt at audit time.

What meeting A.6.2.8 costs in money and effort

This table lists the cost components of recording AI system event logs, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote and to see which costs stay with your own teams. No figures are given because none are supplied for this control, so ask each provider to price these lines separately.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Logging tooling or licenses	Recurring if commercial; open-source components carry no license fee but still need hosting and support	Number of AI systems in scope, whether a commercial observability or SIEM product is used, and whether self-hosted open-source tools cover the need
Engineering time to instrument systems	One-time per system, paid to internal engineers or an implementation partner	Number of AI systems, number of life cycle phases where logging is enabled, and how many components already emit structured logs
Log storage and retention	Recurring, paid to your cloud provider or data center operator	Log volume per system, retention period set in your policy, and whether logs are tiered to cheaper storage
Integrity and access controls on logs	One-time design, then recurring operation, paid to internal security or platform teams	Whether logs are signed or written to append-only storage, and how many people hold administrative access to log stores
Monitoring and incident investigation use	Recurring, paid to the security operations or AI operations team	Alert volume, number of log sources correlated, and how often investigations use the records
Evidence upkeep	Recurring, paid to internal compliance staff or an advisor preparing samples	Frequency of control reviews, number of logging configurations that change, and whether evidence is collected automatically
External review and auditor sampling	Recurring at each audit cycle, paid to the independent certification body or auditor	Sample sizes the auditor selects, number of AI systems covered, and how readily logs can be retrieved for a chosen period

Which self-hosted open-source tools produce logging evidence

Langfuse, an MIT-licensed observability platform, records traces of LLM-based applications. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, along with timing, inputs, outputs, token usage and metadata. For A.6.2.8, this is the most direct source of operational event records for AI applications that call models at run time.

Operation-level records: Traces show the sequence of model calls, retrieval steps and tool executions that produced an output, which supports reconstruction of a specific interaction.
Timing and usage data: Latency and token counts give monitoring teams a basis for spotting anomalies and cost drift.
Input and output capture: Recorded inputs and outputs are useful for investigation, but they may contain personal data, so confirm redaction and retention settings before enabling them.
Metadata for attribution: Tagging traces with model version, user or tenant identifiers helps link events to the system version in use.
Self-hosted deployment: Confirm where trace data is stored, who can query it, how long it is kept and whether it is included in your backup and access review scope.

Before relying on traces, confirm which life cycle phases you have chosen for logging and that the trace schema covers the events your organization has defined.

Where event logging programs usually fall short

Event logging for AI systems often fails in predictable ways: logs cover the servers but not the model, phase decisions are never written down, and records can be altered or ignored. Each card below names one gap and the closing action that addresses it under A.6.2.8.

Logging infrastructure but not model behavior

Teams often capture host, container and API gateway logs while the prompts, model versions, retrieved context, tool calls and outputs go unrecorded. An incident involving a harmful or incorrect output then cannot be reconstructed. Close the gap by logging model inputs, outputs, versions and tool executions alongside infrastructure events, and check that a sample request can be traced end to end.

No documented phase decision

A.6.2.8 asks the organization to determine the life cycle phases in which event logging is enabled, with use as the minimum. Many programs turn logging on by default in production and never record why other phases, such as testing or retraining, are included or excluded. Close the gap by writing a phase decision record for each AI system that names every phase, the logging setting and the owner who approved it.

Undefined or unbounded retention

Logs are often kept indefinitely on a shared volume, or deleted by a default that nobody chose. Either way the organization cannot show what it keeps, why, or for how long, and personal data inside prompts may be stored longer than justified. Close the gap by setting a retention period per log category that reflects investigation needs and privacy obligations, then confirm that deletion actually runs.

Logs writable by the team they monitor

When developers or model operators can edit or delete entries in the same store they are monitored through, the record loses its value in an investigation. Integrity depends on separating who runs the system from who holds the audit trail. Close the gap by sending logs to append-only or write-restricted storage controlled by a separate function, and verify that changes to the log configuration are themselves logged.

Audit logs without access controls

Administrative audit trails for the platforms that host AI workloads are sometimes enabled but kept on the default path with broad read access. Sensitive values can then leak into the logs themselves. Close the gap by restricting read access to logs and masking secrets at the point of capture. Confirm the setting for each platform in use, for example the audit log path that the Nextcloud admin_audit app writes to, and whether the audit device in OpenBao hashes sensitive values.

Logs collected but never reviewed

Retention without review produces records that nobody reads until an incident has already caused harm. Alerts on drift, unusual output patterns or failed safety probes often go to a mailbox with no owner. Close the gap by assigning a named reviewer, defining alert thresholds and reviewing a set schedule of findings, with results feeding the monitoring and incident process.

What buyers ask about A.6.2.8 event logging

How much effort does A.6.2.8 event logging take to implement?

Effort depends mainly on how many AI systems are in scope, how many logging sources each one has, and whether logs already exist. A single system with an existing application log may need a defined logging scope, retention settings and an integrity check. Several systems spread across cloud accounts, model providers and third-party tools take much longer, because each source needs its own mapping to the events you decided to record. The standard does not set a number of hours, so ask any partner to break the work into systems, log sources and review cycles before agreeing a fixed scope in writing.

How long does it take to implement A.6.2.8 logging?

The timeline is driven by the number of life cycle phases you choose to log, the state of your current logging, and how quickly owners can approve retention and access rules. Organizations that already capture audit trails for infrastructure usually need less time than those starting with AI-specific events such as prompts, model versions, tool calls and output decisions. No duration is set by the standard itself, so confirm the expected stages, dependencies and review points with your implementation partner and your certification body before committing to a date.

Can we implement A.6.2.8 event logging in-house?

Yes, an in-house team can implement A.6.2.8 if it has engineers who can configure logging, define retention and protect log integrity. The organization always owns the control, the decision about which phases are logged, and the evidence. What teams often underestimate is the design work: deciding what counts as a meaningful event, who reviews it, and how logs link to incident response and monitoring. Those decisions must be documented and approved, whoever builds the pipeline.

When do we need an outside partner for A.6.2.8?

You need outside help when internal teams lack logging engineering capacity, when several platforms must produce consistent event records, or when a deadline requires faster preparation. A partner such as DeployOpen can plan, configure and document self-hosted logging inside your own infrastructure, and prepare the evidence an assessment will examine. A partner does not own the control, write your policy decisions or issue any report. An independent auditor or certification body performs the assessment, so keep the partner and the assessor separate.

Do AI event logs have to contain personal data?

No, the control asks you to record enough event information to monitor the system and investigate incidents, not to capture personal data by default. Where prompts, outputs or user identifiers appear in logs, they fall under privacy obligations such as the GDPR, so you should minimize fields, mask or hash sensitive values, and set retention limits that match your legal basis. Test whether an investigator can still reconstruct an incident with the reduced fields. Confirm the privacy treatment with your data protection lead.

How does A.6.2.8 relate to A.6.2.6 monitoring?

A.6.2.6 covers how the system is operated and monitored in production, while A.6.2.8 defines the event records that make that monitoring and later investigation possible. In practice, the logs you define under A.6.2.8 feed the monitoring signals, drift checks and incident reviews described under A.6.2.6. Treat the two as linked: if monitoring alerts cannot be traced to logged events, the logging design is incomplete. The NIST AI RMF crosswalk maps production monitoring activities to the B.6.2.8 implementation guidance, which is useful when you document the link.

What should we confirm with the certification body about A.6.2.8?

Ask the certification body how it expects you to justify the phases you log, the minimum event fields, retention periods and integrity controls, and how it will sample evidence. Confirm whether it applies ISO/IEC 42006:2025 requirements to its AI management system audits, since those requirements apply to bodies certifying AI management systems. Also ask which records it wants to see for incident investigations. Certification bodies are independent, so their answers set the evidence standard you must meet.

How DeployOpen prepares event logging evidence for A.6.2.8

The logging decision comes first: before any log pipeline is built, DeployOpen works with the client to record, in a written scope, which AI systems are covered, which life cycle phases must enable event recording, and which owner signs off each decision. A.6.2.8 requires the organization to determine those phases itself, with use as the minimum, so the scope document is the organization's record of that determination. DeployOpen drafts it from the client's inventory of AI systems and the phases defined under A.6.1.3, then the client's accountable owner approves it. Scope, deliverables and timelines are agreed in writing before work starts, and the client keeps ownership of the decision.

Implementation then happens inside the client's own cloud accounts, data centers or air-gapped networks. For each in-scope component, the team configures the logging the decision calls for and checks where records go. For example, a self-hosted Nextcloud deployment can route its admin_audit output to a defined path with the logfile_audit setting, and an OpenBao deployment can enable an audit device whose JSON records hash most sensitive values. Where a language model is involved, traces from a tool such as Langfuse can capture inputs, outputs, tool calls and timing. Retention periods, access controls on log stores and integrity checks, such as restricting write access or forwarding copies to a separate store, are set from the approved scope. The client should confirm that each platform's logging options match the chosen design, since capabilities differ by version.

The evidence pack is the output the client takes to its auditor. It typically contains the approved logging scope, configuration exports, a log source inventory, retention and access settings, samples showing records from each phase, and a short runbook describing how monitoring and incident investigation use those logs. DeployOpen prepares these artifacts and the systems behind them, but it does not issue reports or certificates. Only an independent auditor or certification body can assess conformity and issue a certificate, so the client should agree with its certification body early which sample of logs it will expect. Ask any implementation partner to state in writing which parts of the pack they prepare and which the client must maintain.

A.6.2.8 AI system recording of event logs