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

Sep 25 2026

AI Log Retention: Why Every AI Log Doesn’t Deserve the Same Shelf Life

Category: AI Log Retention,AI Logs — disc7 @ 2:29 pm

DISC INFOSEC  |  AI GOVERNANCE

AI Log Retention: Why Every AI Log Doesn’t Deserve the Same Shelf Life

Your AI logs are either your best evidence or your biggest liability. The retention period decides which.

Most teams I assess have exactly one AI log retention setting: whatever the vendor or the SIEM shipped with. Thirty days here. Forever there. Nobody chose it, and nobody can defend it to an auditor.

That worked when AI was a pilot. It does not work when AI redacts personal data in a deal room, answers customer questions from confidential files, or takes actions through agents. Controls are rarely why organizations fail an AI audit. Evidence is. And a log you deleted too early, or kept too long, is evidence working against you.

This post explains why AI logs need to be categorized by risk, what the EU AI Act, GDPR and ISO/IEC 42001 actually require, and gives you a generic five-tier retention schedule (Tier A = critical) you can adapt this week.

Why one retention period fails in both directions

A single retention period for all AI logs is wrong for almost every AI feature you run. It is either too short for the risky ones or too long for the harmless ones.

Keep everything too briefly, and you lose the ability to prove anything.

  • A customer finds a missed redaction eight months after the data room closed. Your redaction logs expired at 90 days. You cannot show what the model flagged, who approved it, or which model version ran.
  • A regulator asks you to reconstruct how an AI answer was produced. The retrieval and permission-check logs are gone.
  • For high-risk AI systems, the EU AI Act sets a floor of at least six months. Many vendor defaults sit below it.

Keep everything forever, and you create liability you did not need.

  • GDPR’s storage limitation principle says personal data is kept no longer than necessary. “We might need it someday” is not a purpose.
  • AI logs often carry prompts, pseudonymous user IDs, IP addresses and document references. Every extra year enlarges your breach blast radius.
  • Everything you keep is discoverable in litigation, and it costs money to store, search and secure.

The fix is not a better single number. It is a small set of numbers, each tied to how much harm a specific AI function can cause.

What the frameworks actually require

No framework hands you a retention table. Each one pushes from a different side, and your schedule has to satisfy all of them at once.

FrameworkWhat it requires for AI logsWhat it means for retention
EU AI Act (Reg. 2024/1689)Art. 12: high-risk systems must log events automatically so their operation can be traced. Art. 19 (providers) and Art. 26(6) (deployers): keep those logs at least six months, or longer if other law requires.Six months is the floor, not the target. Under the AI Omnibus timeline, Annex III high-risk obligations are set to apply from December 2027.
EU AI Act, Art. 18 and 73Technical documentation kept 10 years for high-risk systems; serious incidents reported to authorities.Incident-linked logs need a legal hold, not a timer.
GDPR (Reg. 2016/679)Art. 5(1)(c) data minimization; Art. 5(1)(e) storage limitation; Art. 5(2) accountability; Art. 17(3)(e) retention to defend legal claims; Art. 30 retention periods in records of processing.A ceiling as well as a floor. Every period needs a written purpose.
ISO/IEC 42001:2023Annex A control A.6.2.8 (recording of event logs); Clause 7.5 documented information; Clause 9.2 internal audit.An auditor will ask for your defined retention and evidence that deletion actually happens.
NIST AI RMF 1.0MEASURE and MANAGE functions expect traceability and incident response across the AI lifecycle.Retention must outlast your monitoring and incident review cycles.

Read together, the rule is simple: keep AI logs long enough to reconstruct and defend what the AI did, and no longer than that purpose requires. That is exactly why one number cannot work.

How to tier any AI log: four questions

Classify the AI function, not the log file. Every log that function produces inherits its tier. Score each function on four questions:

  1. Harm if wrong. If the output is incorrect, who gets hurt, and how badly? A mis-tagged folder is an annoyance. A missed redaction or a wrong credit decision is a breach or a rights violation.
  2. Reliance without review. Is the output used as-is, or does a human check it first? The less review, the higher the tier.
  3. Exposure. Can the function disclose personal data or confidential content, or change permissions, systems or money?
  4. Evidentiary value. Would you need this log to answer a regulator, defend a legal claim, or pass a customer’s due diligence?

Two or more “high” answers put a function in Tier A or B. Mostly “low” answers put it in Tier D or E. When in doubt, tier up; you can always justify shortening later with data.

The generic AI Log Categorization and Retention Schedule

Five tiers, from seven years down to six months. Periods run from the date of the log event and act as both the minimum and the default maximum.

TierTypical AI functionsWhy this tierKey log events (metadata only)RetentionPrimary basis
Tier A CriticalAI in decisions about people (credit, hiring, insurance, eligibility); privacy-protective AI (redaction, PII masking, DLP); agents that change systems, move money or send external messagesDirect harm to rights or data if wrong; outputs often relied on; primary evidence in breaches and legal claimsDecision or action taken; inputs referenced by ID; confidence scores; human approval, override or reversal; model, prompt and rule-set version; tool calls and their authorization7 yearsGDPR Art. 5(2), 17(3)(e), 22, 32–34, 82; EU AI Act Art. 12, 14, 19, 26(6); ISO 42001 A.6.2.8; claim limitation periods
Tier B HighCustomer-facing chatbots, RAG search and Q&A over confidential content, AI access-control decisionsCan surface content outside a user’s permissions; answers relied on; prompt-injection target; users interact with AI directlyQuery metadata; documents retrieved and permission-check result; cited sources; guardrail and injection detections; AI disclosure shown; feedback flags3 yearsEU AI Act Art. 12, 15, 50(1); GDPR Art. 5(1)(c), 25, 32; ISO 42001 A.6.2.6, A.6.2.8
Tier C ModerateGenerative content people rely on after review: translation, summarization, drafting of contracts or reportsErrors can mislead, but a human reviews and the source stays authoritativeJob ID; source and output hashes; languages or template; quality score; human edit or approval; model version2 yearsGDPR Art. 5(1)(e), 28, 32; EU AI Act Art. 50 transparency; ISO 42001 A.6.2.8
Tier D LowExtraction and enrichment feeding other systems: OCR, transcription, classification, entity taggingErrors mostly reduce quality downstream; no direct disclosureJob ID; document or file ID; page count; confidence; failures; engine version1 yearGDPR Art. 5(1)(c) and (e); EU AI Act six-month floor exceeded; ISO 42001 A.6.2.8
Tier E MinimalInternal productivity suggestions: auto-organize, tagging suggestions, autocomplete, performance telemetryHuman decides; no permission changes; lowest harm potentialSuggestion made; accepted or rejected; items affected; model version6 monthsEU AI Act Art. 19 / 26(6) baseline; GDPR storage limitation

Two things sit outside the tiers on purpose. AI configuration and model changes (enabling a feature, swapping a model, editing a system prompt or guardrail) are change records; keep them with your release records, typically five years. Raw prompt and output payloads captured for debugging are off by default, enabled per change request, and deleted within 30 days.

Six rules that make the schedule hold up in an audit

A table on its own is a policy. These rules turn it into evidence.

  1. Log metadata, not content. Record what happened, when, for whom and under which model. Do not store document text, OCR output, translations or full prompts in logs. Long retention is only defensible when the log is lean.
  2. Legal hold beats the timer. Any log tied to an AI incident, a personal data breach, litigation, a regulatory inquiry or a data subject request is frozen until released, then kept for the longer of its tier or the incident record.
  3. Dependencies inherit the higher tier. When OCR feeds redaction, the OCR job reference lives in the Tier A redaction log. Otherwise your Tier D deletion quietly breaks your Tier A evidence.
  4. Reclassify on change. A new model, a new provider or a new purpose triggers a re-tier before release. If a Tier E tool gains the power to change permissions, it is no longer Tier E.
  5. Put your vendors in scope. Your model provider may keep prompts and outputs on its own clock. Contract for no retention beyond processing and no training on customer content, and verify the settings at onboarding and every annual review.
  6. Prove deletion. Automate expiry, log the deletion job itself, and sample it in your internal audit. “We have a retention policy” fails; “here is last quarter’s deletion evidence” passes.

From the field: what a virtual data room taught us

Financial data rooms are the hard mode of compliance. When we took a Virtual Data Room organization through ISO/IEC 42001 certification and later rebuilt its Records Management Standard for AI, the same pattern showed up that I now see everywhere:

  • The existing retention table covered contracts, audits and training records. It said nothing about AI.
  • Five AI features (redaction, OCR, search, organize and translate) all shared one default log setting.
  • Redaction was clearly the highest-risk function, yet its logs had the same life as auto-organize suggestions.

The fix was the tiered approach above: redaction at seven years, AI search at three, translation at two, OCR at one, auto-organize at six months, with a metadata-only logging rule that fits a content-blind platform. The policy change took days. Configuring the SIEM to honor five retention periods is the real work, so start that conversation with engineering early.

Five steps to implement this quarter

  1. Inventory every AI function in production, including vendor features you switched on.
  2. Tier each one with the four questions and record the rationale.
  3. Write the schedule and the six rules into your records management standard, with an owner for AI logs.
  4. Configure log retention and automated deletion per tier in your SIEM and at each model provider.
  5. Audit it: sample one log per tier, confirm content minimization, and show deletion evidence in your next management review.

Get the AI Log Retention Kit

I’ve packaged everything in this post into a ready-to-edit AI Log Retention Kit:

  • The Tier A–E retention schedule as an editable Word table
  • Drop-in policy language for a records management standard (scope, roles, the six rules, legal hold)
  • The four-question tiering worksheet for your AI inventory
  • An auditor-ready evidence checklist mapped to the EU AI Act, GDPR and ISO/IEC 42001

Comment “RETENTION” below and I’ll send it to you. Prefer a second pair of eyes on your own AI features? Book a free 30-minute AI log retention review at calendly.com/hd-deurainfosec and we’ll tier your AI functions together.

Hugh “Disc” Deura is Principal Consultant at DISC InfoSec, an ISO/IEC 42001 Lead Implementer, CISSP and CISM, and led a Virtual Data Room organization to ISO 42001 certification on its first Stage 2 audit.

This post is general guidance, not legal advice. Sector rules (for example, financial services recordkeeping) and national law may require longer periods.

#AIGovernance #ISO42001 #EUAIAct #GDPR #AISecurity #RecordsManagement #Compliance

Tags: AI Logs retention