Retention Against Dwell

## What a retention setting actually promises Retention is a promise about how far back a search can reach. When it is set to 90 days because a control framework or a contract requires audit records to be retained for 90 days, the number has been sized to prove that records exist — not to cover the length of time an intruder can be present before anyone notices. Those are unrelated quantities, and they only look related because both are expressed in days. ## Dwell time is the quantity that should have set it Dwell time is the elapsed time between the earliest evidence of adversary activity in the estate and the moment the intrusion is detected. It matters here because the searchable horizon has to reach back past the start of the intrusion for any reconstruction to be possible at all. Two facts about dwell make a 90-day horizon fragile: - The distribution has a long right tail. Even where typical dwell is short, a meaningful share of cases run for many months. - Dwell is systematically longer when the intrusion is discovered by somebody else — a partner, a payment processor, a law-enforcement or sector-ISAC notification — than when it is found by the organisation's own detections. Externally-notified cases are exactly the cases where you most need deep history, and they are the cases most likely to be older than the window. This scenario is the second kind. A partner told you, and they dated it at seven months. ## The concrete gap Seven months is roughly 210 days. A 90-day window covers the most recent 90 of them. Roughly four months of the intrusion — including its beginning — is outside anything the SIEM can return. The specific questions that go unanswered: - When did the access start, and therefore what was the initial foothold. - What else did the account or host touch during those four months. - Was activity continuous, or did it pause and resume. - Were other identities or systems involved earlier and quiet since. - Did any of the data the partner is describing move during that period. What you can still answer is bounded and worth stating plainly: what happened inside the last 90 days, whether the activity is ongoing right now, and what the current state of the affected accounts and hosts is. ## The direction of the claim — the mistake to avoid The most damaging error at this point is to run a search over month five, get zero results, and write `no malicious activity in month five`. The data for month five does not exist. An empty result over a period you do not retain carries no information about that period whatsoever. Case notes should distinguish three states explicitly: searched and clean, searched and positive, and not searchable. Executives, auditors and lawyers all read the first and third as the same sentence unless you separate them. ## The SIEM is not always the only copy Before concluding a period is gone, enumerate what else holds records of it, because retention is per-source and rarely uniform: - The identity provider's own sign-in and audit trail, which has a platform-defined retention independent of whatever your SIEM ingested. - SaaS platforms' native audit trails and mail message-trace data, again with their own horizons. - Network flow or DNS resolver logs, often kept on a different schedule and much cheaper to keep long because the records are small. - Host-local artefacts that persist independently of any log pipeline, and backups or snapshots of the systems themselves. Each of these has a different horizon, so the honest answer to `how far back can we look` is a list, not a single number. ## What you take from the case Two outputs. First, the report says which periods were searchable and which were not, so nobody later mistakes an unsearchable month for a clean one. Second, the horizon itself becomes a finding: the window was set against a compliance minimum, the estate has now demonstrated an intrusion that outran it, and the next retention decision should be argued from how long intrusions actually go unnoticed rather than from the audit clause.