ISO 42001 Annex A.6.2.8: Record AI Events That Support Traceability

What control A.6.2.8 requires in practice

Control A.6.2.8 asks the organisation to decide, for each AI system, at which stages of its life cycle event logs are kept. There is one fixed floor: whatever else is decided, record keeping has to be active at least while the system is in use. Anything beyond that is a reasoned choice the organisation can explain. The outputs are a stated decision on the stages covered and the logs themselves, produced as the system runs. Annex B guidance describes logs as a way to trace whether the system behaves as intended and to notice operation outside the conditions it was meant for. Typical content includes when the system was used, what live data it handled and which outputs looked abnormal. The same guidance links retention to what the intended use needs, to the organisation's own retention rules and to any legal duties. It also warns that some systems, such as biometric identification, can carry extra logging duties in certain jurisdictions.

Choose events from the question you need to answer

Annex B.6.2.8 discusses automatic collection of relevant operating events, including evidence of intended functionality and departures from expected conditions. It connects retention with intended use, organisational policy and applicable obligations. The guidance must be considered, while B.1 allows implementation suited to the system and treatment needs.

As a practical method, start with an investigation question: which system and use were involved, what happened and what decision followed? Determine the event information needed to answer it. Do not assume that collecting every input and output indefinitely is always necessary or appropriate.

Why control A.6.2.8 matters to the business

When a customer disputes an AI-assisted result, the first question is what actually happened. Without usable event records, the answer becomes guesswork, and guesswork is expensive in complaints, contract disputes and regulator conversations. Logs also let a business notice drift early, before many customers are affected. An auditor reading this control wants to see that logging was a deliberate decision matched to risk, not an accident of the platform's default settings. Done well, the control shortens investigations, supports open communication with clients and gives management something factual to review. Done badly, it produces large volumes of data that nobody can read or that expose sensitive content to too many people.

How to implement control A.6.2.8

The aim is a logging design that answers real investigation questions without collecting everything forever. Keep the effort proportionate: a modest, well-chosen log that someone reads beats an exhaustive one that sits unread, and the design should be revisited whenever a platform migration threatens to strand older records.

1. List the AI systems in use and name an owner for each, so someone is accountable for the logging decision.
2. For each system, write down the questions an investigator would need answered, such as which version ran, on what input and who reviewed the output.
3. Decide which life cycle stages need logging, treating the in-use stage as the minimum, and record the reasoning.
4. Choose the event details that answer those questions, and check with the technical team what the platform can record reliably.
5. Set retention from the intended use, internal policy and legal duties, and restrict who can read sensitive entries.
6. Run a mock investigation on a past output and note what cannot be reconstructed; feed the gaps into risk treatment.
7. Re-check the design whenever the system, supplier or use changes.

Illustrative BPO example: a complaint cannot be reconstructed

Illustrative manufacturing example: identical timestamps hide different conditions

A manufacturer investigates inconsistent AI inspection results across two lines. Logs identify when the service ran but not which operating configuration or product variant was involved. The team cannot distinguish a model issue from a change in conditions.

The organisation considers appropriate contextual information and how it relates to other controlled records. The aim is a usable evidence trail, not an unlimited technical data dump. Relevant specialists decide what the actual system can record reliably and what limitations remain.

Connect logging with monitoring and investigation

Logs can support operation and monitoring, but collecting them does not establish that anyone reviews meaningful signals. Determine how evidence reaches the people responsible for performance, concerns or incidents.

A record that a review step was opened may not prove that a competent person completed it effectively. Interpret events according to what they actually show. Avoid translating technical activity into an unsupported assurance claim.

Set retention and protection deliberately

The control does not prescribe one universal retention period. Determine the period using intended use, organisational policy and applicable requirements. Specific systems or jurisdictions may introduce additional obligations that need appropriate assessment.

Protect log integrity, confidentiality and access through relevant information-control arrangements. Sensitive inputs or identifiers may require particular care. Keep enough context for the purpose without assuming that broader collection is automatically better governance.

Evidence and common failures