Oct 16 2026

The Evidence Lifecycle: Which Organizational Events to Log for Liability — and How Long to Keep Them

Category: AI Log Retention,AI Logs,Log Management — disc7 @ 10:26 am

The Evidence Lifecycle: Which Organizational Events to Log for Liability — and How Long to Keep Them

Oct 16, 2026 · @disc infosec

Why logs are your liability defense

When an auditor, regulator, or plaintiff’s attorney asks “prove it,” your logs are the only answer that counts. Policies show intent. Logs show what actually happened, who did it, and when.

Most organizations log plenty of data and still lose the argument. They capture firewall noise for 30 days but can’t produce the board minute that approved an AI system, the access review from the quarter a contractor left, or the model version that made a disputed credit decision 18 months ago.

The fix is to stop thinking about logs as an IT setting and start thinking about them as an evidence lifecycle: identify the events that create legal or regulatory exposure, decide what proof each one needs, and keep that proof exactly as long as the exposure lasts — no shorter, and no longer.

This post gives you a method for finding those events, a lifecycle map for both the organization and its AI systems, what ISO/IEC 27001, ISO/IEC 42001, the EU AI Act, and the NIST AI RMF actually require, and a retention matrix you can adapt this week.

How to identify the key events: the four-question test

A “key event” is any moment that someone may later need you to prove. Not every log line qualifies. Run each candidate event through four questions; one “yes” makes it a key event.

  1. Does it grant, change, or remove authority? Board approvals, delegations, access grants, admin elevation, an AI agent receiving a new tool or permission.
  2. Does it change your risk posture? A new vendor, a new AI model in production, a material configuration change, an exception to policy, an accepted risk.
  3. Does it create an obligation to someone outside the company? A customer contract, a regulator notification clock, a consent captured from a data subject, a breach that starts a 72-hour timer.
  4. Could it be disputed later? An automated decision about a person, a termination, a pricing or credit outcome, a model output a customer relied on.

Then find the events where they actually live. You don’t need to invent them. They are already sitting in six places:

  • Legal and regulatory register — every law, contract clause, and standard you’re bound to implies events you must prove.
  • Risk register and AI risk assessments — every treated risk implies a control, and every control implies evidence.
  • AI system inventory — every system has a lifecycle; every lifecycle stage has a decision.
  • HR and identity systems — joiners, movers, leavers, and privileged roles.
  • Contracts and vendor register — onboarding, reassessment, termination, data return.
  • Incident and complaint history — what has already gone wrong tells you what will be asked about next.

The output of this exercise is an event catalog: event, owner, system of record, evidence produced, legal driver, and retention period. Everything else in this post fills in that catalog.

The organizational lifecycle map

Every stage of a company’s life produces events that a buyer, auditor, regulator, or court may later examine. Formation and exit happen once; change and crisis repeat many times, and each repetition creates a fresh evidence obligation.

The stages that bite hardest are the ones teams don’t plan for. During an acquisition, the buyer’s diligence team will ask for three years of access reviews and every AI impact assessment. During a wind-down, you still owe customers proof that their data was returned or destroyed, and that proof must outlive the company’s operating systems.

The AI system lifecycle: events that must leave a trail

Every AI system you build or buy runs a lifecycle inside the organization’s lifecycle, and each stage owes its own evidence. ISO/IEC 42001 A.6.2.8 sets the floor: event logs at least while the system is in use. The EU AI Act asks for logs across the system’s whole lifetime.

The operate stage writes most of the volume and most of the liability. It is where a customer disputes a decision, where an agent takes an action nobody approved, and where a regulator’s reporting clock starts. It is also the stage that loops: each retraining creates new versions, evaluations, and approvals that have to be traceable back to the decisions they produced.

The question to ask at every stage is simple: if this system harmed someone two years from now, could we show what it was, who approved it, what data shaped it, and what it actually did?

What the frameworks actually require

Only one of the four frameworks sets a hard retention clock for logs: the EU AI Act. The two ISO standards require you to define retention and prove you follow it. The NIST AI RMF expects you to be able to trace and reconstruct. Your retention schedule has to satisfy all four at once.

FrameworkWhat it requires you to log or keepRetention it setsStatus
ISO/IEC 27001:2022Cl. 7.5 documented information; A.8.15 logging; A.8.16 monitoring; A.8.17 clock synchronization; A.5.28 collection of evidence; A.5.33 protection of records; A.5.24–5.27 incident recordsNone fixed. A.5.31 and A.5.33 tie it to your legal, regulatory, and contractual requirementsCertifiable; 3-year certification cycle
ISO/IEC 42001:2023Cl. 7.5; A.6.2.8 AI system event logs; A.5.3 documented impact assessments; A.6.2.7 technical documentation; A.7.5 data provenance; Cl. 10.2 nonconformity recordsNone fixed. A.6.2.8 requires logging at least while the AI system is in use, with defined retentionCertifiable; 3-year certification cycle
EU AI Act (high-risk)Art. 12 automatic event logging across the system’s lifetime; Art. 18 documentation; Art. 72 post-market monitoring; Art. 73 serious incident reportingLogs: at least 6 months for providers (Art. 19) and deployers (Art. 26(6)), longer if other law requires. Technical documentation, QMS records, and declaration of conformity: 10 years after placing on the marketMandatory. Annex III systems from 2 Dec 2027; Annex I systems from 2 Aug 2028
NIST AI RMF 1.0GOVERN 1.6 AI system inventory; GOVERN 1.7 decommissioning; MEASURE 3 tracking of risks over time; MANAGE 4.1 post-deployment monitoring; MANAGE 4.3 incident tracking and communicationNone. Expects enough record to reconstruct decisions and outcomesVoluntary; the de facto US benchmark

Three points matter for liability.

The EU AI Act clock moved, but it didn’t stop. The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred the stand-alone high-risk obligations to 2 December 2027. The classification rules didn’t change, and Article 50 transparency duties largely still apply from August 2026. A high-risk system you deploy today will need 2027-grade logs, and logs can’t be created retroactively.

Six months is a floor, not a target. The Act’s six-month minimum yields to any longer period in Union or national law. A credit model’s decision log will usually be governed by the lending record rules and limitation periods around it, not by Article 26.

“Not specified” doesn’t mean “optional.” An ISO auditor will ask for your retention schedule, then sample it. A log you said you keep for 2 years and can’t produce at month 14 is a nonconformity. A log you keep for 10 years with no reason is a GDPR storage-limitation problem. Both standards reward a schedule that is written down, justified, and followed.

The retention matrix: what to keep and for how long

The rule behind every row: keep evidence as long as someone can still hold you to the event, plus a margin, and not a day longer. That means the longest of (a) the regulatory minimum, (b) the contractual commitment, (c) the limitation period for claims, and (d) one full ISO certification cycle so your auditor can sample it.

In our previous post, AI Log Retention: Why Every AI Log Doesn’t Deserve the Same Shelf Life, we tiered AI logs from Tier A (critical) to Tier E (minimal). This matrix places those tiers inside the wider organizational picture.

Event categoryKey eventsEvidence to keepRecommended retentionMain drivers
Corporate governanceFormation, bylaws, board and committee approvals, equity changes, AI policy adoption, risk appetiteSigned minutes, resolutions, cap table history, policy approval recordsPermanent (life of entity, then per dissolution rules)State corporate law; M&A due diligence; ISO 27001/42001 Cl. 5 leadership evidence
Finance and taxTransactions, audits, revenue recognitionLedgers, audit workpapers, approvals7 yearsIRS; SOX §802 for public companies
Contracts and customersSignature, amendments, SLA breaches, termination, data returnExecuted contracts, change history, notices, deletion certificatesContract end + 7 yearsLimitation periods; customer audit clauses
People (joiner, mover, leaver)Hire, screening, role change, privileged role grant, terminationHR records, screening results, acknowledgments, offboarding checklistsTermination + 4–7 years; Form I-9 per federal ruleFLSA; IRS; EEOC; ISO 27001 A.6.1, A.6.5
Identity and accessAccount creation, privilege elevation, access reviews, removalIAM audit logs, review sign-offs, break-glass records3 years (reviews); 1 year minimum for raw logsISO 27001 A.5.18, A.8.2, A.8.15; PCI DSS 10.5.1
Security monitoringAuthentication, admin actions, alerts, data egressSIEM events, alert triage notes12 months hot, archive to 3 yearsISO 27001 A.8.15–8.17; PCI DSS; cyber insurance terms
Change and configurationProduction changes, emergency changes, policy-as-code updatesTickets, approvals, diffs, rollback records3 yearsISO 27001 A.8.32; ISO 42001 A.6.2.5
Risk and complianceRisk assessments, risk acceptances, SoA versions, audit findings, management reviewsVersioned registers, signed acceptances, CAPA recordsSuperseded + 3 yearsISO 27001/42001 Cl. 6, 9, 10
Vendors and AI suppliersOnboarding, due diligence, reassessment, offboardingQuestionnaires, SOC 2/ISO reports, DPAs, exit evidenceRelationship end + 7 yearsISO 27001 A.5.19–5.22; ISO 42001 A.10; GDPR Art. 28
PrivacyConsent, DSARs, DPIAs, transfersConsent records, request logs, DPIA versionsConsent: processing period + limitation period; CCPA request records: 24 monthsGDPR Arts. 5, 7, 30, 35; CCPA regulations
Incidents and breachesDetection, triage, notification, closureTimeline, forensic evidence, notifications, lessons learnedClosure + 7 years; indefinite under legal holdISO 27001 A.5.24–5.28; state breach laws; EU AI Act Art. 73
AI governance recordsAI inventory entries, impact assessments, technical documentation, conformityVersioned AIIAs, model cards, declarations10 years after placing on the market or retirement (high-risk); retirement + 3 years otherwiseEU AI Act Art. 18; ISO 42001 A.5.3, A.6.2.7; NIST GOVERN 1.6
AI decisions (Tier A)Consequential outputs about people: credit, hiring, insurance, accessDecision record: input reference, model version, output, human reviewer, overrideAt least 6 months; in practice the governing record rule, often 3–7 yearsEU AI Act Arts. 12, 19, 26(6); sector lending and employment rules
AI operations (Tiers B–E)Agent tool calls, permission grants, retrieval, guardrail blocks, drift alertsMetadata-only event logs; prompt and response content minimized6 months to 3 years by tierISO 42001 A.6.2.6, A.6.2.8; NIST MANAGE 4.1
AI model and data provenanceTraining data sourcing, evaluation, bias testing, release, retraining, decommissionDataset lineage, eval reports, version registry, retirement recordLife of the model + 10 years (high-risk); + 3 years otherwiseISO 42001 A.6.2.4, A.7.5; NIST GOVERN 1.7

These periods are defensible starting points for a US-based B2B SaaS or financial services firm with EU exposure. They are not legal advice. Sector rules (for example, broker-dealer, HIPAA, or lending record rules) can lengthen any row, so have counsel confirm the final schedule.

Seven liability traps, including the new ones AI creates

A retention schedule fails in court for predictable reasons. Five are classic; two are new with AI.

1. Deleting under legal hold. Once litigation or an investigation is reasonably anticipated, every scheduled deletion of relevant records must stop. Automated lifecycle rules don’t know that. Build a hold flag that overrides deletion jobs, and log who set and released it.

2. Keeping too much. Retention beyond your stated purpose violates GDPR storage limitation and inflates discovery cost. Every extra year of raw prompts is another year of exposure in a breach or subpoena. Defensible deletion — scheduled, documented, and verified — is as much a control as retention.

3. Logs that can be edited aren’t evidence. ISO 27001 A.5.33 and A.8.15 require protection against falsification. Use write-once storage (for example, S3 Object Lock or Azure immutable blobs), hash chaining, and A.8.17 clock synchronization. Restrict log deletion rights to a role nobody uses day to day.

4. Logs held by someone else. If your LLM provider, agent platform, or SaaS vendor holds the logs, you have a retention promise you can’t keep. Put export rights, retention periods, and legal-hold cooperation into the contract, and test the export before you need it.

5. The oversight checkbox. A “reviewed by human” flag records the reviewer’s statement, not what they saw or changed. For Tier A decisions, log the model output, what the reviewer saw, the action they took, and the time spent. That is the difference between claiming oversight under EU AI Act Article 14 and proving it.

6. Log poisoning (new). Attackers now plant prompt-injection payloads in fields that end up in logs: user agents, file names, support tickets, chat messages. When an AI SOC assistant or summarizer later reads those logs, the payload runs. Treat log content as untrusted input to any AI tool, and never give a log-reading agent write or delete rights over the logs it reads.

7. Agents erasing their own trail (new). An over-permissioned agent with infrastructure access can change logging configuration, rotate logs, or delete them, by accident or under injection. Log every agent tool call and permission grant to a store the agent can’t reach. Alert on any change to logging configuration made by a non-human identity.

One more caution: AI logs leak. Prompts carry PII, secrets, and deal terms, which turns your log store into a high-value target. Default to metadata-only AI logs, keep content only where a Tier A decision needs it, and redact before storage, not after.

Your 90-day plan

You can go from scattered logs to an auditable evidence lifecycle in one quarter.

  1. Days 1–30: Find the events. Run the four-question test across your legal register, risk register, AI inventory, HR, vendor list, and incident history. Produce the event catalog with an owner and system of record for each event.
  2. Days 31–60: Set the clocks. Assign every catalog entry a retention period using the matrix above. Tier your AI logs A to E. Have counsel sign off, then publish the schedule as part of your records management standard under ISO 27001 and ISO 42001 Clause 7.5.
  3. Days 61–90: Make it provable. Configure retention in each system, add immutable storage and the legal-hold override, move agent logs out of agents’ reach, and add vendor export clauses. Then test it: pick five events from 14 months ago and try to produce the evidence in under an hour.

That last test is the one that matters. Controls are rarely why organizations fail audits or lose disputes; missing evidence is.

Need a hand?

DISC InfoSec helps B2B SaaS and financial services firms build evidence that holds up under ISO/IEC 27001, ISO/IEC 42001, the EU AI Act, and the NIST AI RMF. We led Virtual Data Room through ISO/IEC 42001 Stage 2 certification on the first attempt, including its AI log retention and records management standard.

Book a free 30-minute call at calendly.com/hd-deurainfosec, or email info@deurainfosec.com. Comment EVIDENCE on the LinkedIn post and we’ll send you the event catalog and retention matrix template.

Sources

Tags: AI logs, Logs for Liability