Log Retention Shorter Than Dwell Time
- Category
- Visibility & Logging
- Published
- Jul 3, 2026
- Updated
- Aug 28, 2026
The Failure
The effective log retention period is shorter than a typical attacker dwell time. Dwell time is measured in weeks, often months; the actual retention of many sources is measured in days.
This is structural because no one decides retention: it results from each tool’s default settings, the fixed size of local logs that overwrite themselves as they rotate, and storage-cost trade-offs made with no connection to investigative needs. No function owns the question “how far back must we be able to go?” Each source therefore has its own window, usually short, sometimes just a few days on the busiest machines — precisely the ones an investigation cares about.
The result: by the time anyone looks for the initial access, that period has already fallen outside the window.
Why It Matters
The central question of any investigation is “how did they get in, and since when?” Without logs covering the initial access period, the chain of consequences is mechanical:
- impossible to date the start of the compromise;
- therefore impossible to certify that a given backup predates the compromise;
- therefore restoring onto a potentially backdoored baseline, or a full rebuild out of caution — the difference is measured in weeks;
- notification obligations require characterizing what was accessed: without logs, you characterize for the worst case, and notify more broadly than necessary.
On top of this comes the direct investigation cost: every question that lacks a log gets answered through slower, less conclusive methods, and the final report ends up filled with “could not be determined” — the most expensive phrase in the IR vocabulary.
How to Identify It
The check is simple and takes a few hours:
- inventory the sources that can date an initial access: central authentication, remote access, email, directory server logs, firewalls, backup platform;
- for each one, measure the actual retention, not what the documentation says: look for a specific event dated three months back, then six months back. The test settles the matter where configuration merely reassures;
- pay particular attention to fixed-size local logs that overwrite themselves: on a heavily used machine, the window can be just a few days;
- compare the shortest window among critical sources to the dwell times reported in public incident response reports.
Summary question: “if the intrusion had started four months ago, what could we still prove?” If the answer is “almost nothing,” the pattern is present.
Fix Before the Incident
Set a retention target driven by investigative need, not by storage constraints:
- twelve months is a reasonable target for sources that can date an initial access (authentication, remote access, email); at minimum 90 days in directly searchable storage, the rest in cold archive;
- separate the two economic needs: ingestion and hot search are expensive, compressed archive is cheap. Most organizations can afford twelve months of archive even when they cannot afford twelve months of an analysis platform;
- prioritize sources by how well they can date an intrusion, rather than aiming for completeness;
- verify retention through a periodic test (retrieve an old event), built into operational review — retention degrades silently, through volume growth or tooling changes.
If You’re Already in an Incident
Two things are urgent at once: stop the bleeding, then widen the window through other means.
- Freeze what still exists: suspend rotation and purging, immediately copy the local logs of machines of interest — they keep overwriting themselves during the incident, and every day of delay destroys evidence.
- Look for indirect copies: backups of machines that contain their logs as of the backup time, historical exports, data retained by third parties (identity provider, email operator, service providers) whose retention often exceeds your own.
- Date events through non-log artifacts: file timestamps, scheduled tasks, account creation dates and persistence mechanism dates — less precise than a log, but often enough to bound the timeline.
A short window reduces investigative precision; it does not prevent the investigation if everything remaining is put to use.
Related Controls
- CIS Controls v8 — 8.1
- CIS Controls v8 — 8.3
- CIS Controls v8 — 8.10
- NIST CSF 2.0 — PR.PS-04
- ISO 27001:2022 — A.8.15