CISA ties log retention to the purpose

You must now design log retention periods by the specific incident questions each log type must answer, rather than applying a single fixed duration across all logs. Federal requirements already mandate at least six months of actively searchable and one year of retrievable logs; treating ninety days as a universal standard creates compliance risk and leaves investigation trails overwritten before incidents surface.

An analysis of 5 November 2026 of incident log retention standards and the ninety-day misconception argues that federal frameworks tie retention periods to investigative purpose and risk rather than to a fixed duration. The CISA Logging Reference Architecture, published in August 2026, distinguishes between actively searchable storage for operational monitoring, retrievable retention for later investigation, and separately protected evidentiary data for forensic or legal purposes. In our assessment, the practical consequence is that a single retention dial no longer suffices: you must now map each log type to the incident questions it must answer and the regulatory minimum that applies to your systems.

What does CISA actually require for log retention?

The Logging Reference Architecture establishes three storage functions rather than a single retention period. Actively searchable logs support operational monitoring and real-time alerting. Retrievable logs remain available for investigation after the actively searchable window closes. Separately protected evidentiary storage preserves data for forensic analysis or legal proceedings, with controls on access and integrity.

The federal baseline from OMB memo M-26-14 requires logs to remain at least six months actively searchable and one year retrievable. For AI systems specifically, CISA identifies context such as prompts, model outputs, model versions, agent decisions, tool calls and runtime parameters as information you should consider logging. The ninety-day period may appear as an internal operational setting within some organisations or products, but it does not appear in the official frameworks and does not override the federal minimums.

Which logs carry an investigation, and for how long?

To reconstruct unexpected agent behaviour you must trace the full trajectory and demonstrate that the data was not altered. Triage logs—the alerts that something went wrong—differ fundamentally from agent and tool-call traces, which carry the investigation itself. In practice, the greatest risk is not that organisations log too little, but that they keep the wrong logs for too short a time: the triage logs remain live whilst the traces that carry an investigation have already been rotated out.

You should consider capturing at least the following for a practical reconstruction record:

1. Prompt and input data — what the user or system provided to the model at each step.
2. Model output and reasoning — what the model generated and the parameters or weights that shaped it.
3. Agent decisions and tool calls — which actions the agent selected and which external systems it invoked.
4. Timestamps and sequence — reliable, tamper-resistant records of when each event occurred and in what order.
5. Access and modification records — who viewed or altered the logs and when, to establish integrity.
6. Model version and configuration — which model version was in use and its relevant settings at the time.

What compliance minimums apply to your systems?

The federal baseline in M-26-14 requires six months actively searchable and one year retrievable for U.S. federal agencies. High-risk AI systems under the EU AI Act require at least six months for automatically generated logs under the control of the provider or deployer; you must check the precise applicable provision and any longer statutory periods before adoption. The NIST-NSA-CISA practices for incident readiness emphasise that logs must be tamper-resistant and carry reliable timestamps, and that after a control incident an organisation first collects, preserves and analyses evidence before resuming operation after verified recovery.

Three different things are in practice conflated: the internal operational setting that some products use, the federal baseline that applies to specific organisations and systems, and the investigative requirement that depends on when an incident comes to light. Because AI incidents often surface months after they occur, a ninety-day window will have already closed by the time investigation begins.

How should you implement retention by purpose?

Before implementation, record per log type which incident question it must be able to answer and for how long. The CISO should map each log category to the investigative purpose it serves: operational alerting, incident reconstruction, forensic analysis or legal compliance. Where the EU AI Act or M-26-14 apply to your systems, retaining less than the stated minimums may create a compliance issue; the applicable scope and any longer requirements must be checked before adoption, so legal review should test the retention policy against applicable minimums.

Establish an incident hold that suspends normal deletion when a relevant investigation starts, particularly where delayed discovery is reasonably possible. Because the NIST-NSA-CISA practices call for tamper-resistant logs with reliable timestamps, an export without a documented integrity check should not be treated as a complete evidentiary record. Test whether integrity, access, privacy and recovery work in practice rather than merely exist on paper.

Tooling can enforce retention schedules and flag when logs approach deletion thresholds, but the mapping of log type to investigative purpose and the decision about which regulatory minimum applies to your systems remains your own professional judgement. Whoever links these steps to the distinction between a technical event record and a linked decision record, and to controlling tool calls and authorisation of AI agents, builds retention that genuinely carries an investigation.