The Logs That Would Have Told You Everything Are Already Gone
The forensic team arrives after a confirmed breach. They start pulling logs. The SIEM has 30 days of data. The attacker was first seen in external threat intelligence reports six weeks ago. The initial compromise is somewhere before the log window starts.
This is not unusual. It is close to the default outcome for organizations that have not deliberately built their logging program around the question "what would we need if we had to investigate an incident right now?" Most have built it around "what do we need to run the SIEM day-to-day without generating too much storage cost?" Those are different questions with different answers, and the gap between them is the investigation window you will not have when you need it.
How Dwell Time and Retention Interact
The average attacker dwell time - the period between initial compromise and detection - has historically run between 60 and 100 days in enterprise environments. It varies by industry, incident type, and how mature the victim's detection program is. But for planning purposes, 60 days is a reasonable minimum expectation for how far back your logs need to reach before you can be confident of seeing the start of a typical intrusion.
Most organizations retain logs for 30 days by default. Many retain less. A common configuration is hot storage at 14 days, cold storage at 30 if the team got around to setting it up, and nothing beyond that. The cold storage is often an aspiration that was never fully implemented.
The practical consequence: when your incident begins 90 days into the attacker's presence and you pull logs, you are looking at one-third of the intrusion timeline. You can see what the attacker was doing recently. You cannot see how they got in, what they did during the reconnaissance phase, which accounts they touched before settling on a target, or what they may have moved out before your detection window begins.
The Sources That Were Never Enabled
Retention period is the visible problem. The less visible one is the sources that were never configured to log at all.
In cloud environments, data event logging is not on by default. AWS CloudTrail logs management events - who created and deleted resources, who modified IAM policies - without additional configuration. But GetObject and PutObject calls on S3, DynamoDB reads, Lambda invocations: these are data events, and they are off unless you turn them on. The volume is real and the cost is real, and so teams don't turn them on. During an investigation into an S3 data exfiltration, the question "what objects were accessed and by whom" has no answer, because that logging does not exist.
On-premises environments have parallel gaps. Windows Security event logs on domain controllers may be configured to capture logon events but not detailed process creation or network connection logs. PowerShell script block logging, which records the decoded content of obfuscated PowerShell commands, is off by default. Command line auditing, which captures what arguments were passed to executed processes, is off by default. An attacker who operated primarily through native Windows tooling in an environment without these sources enabled leaves almost no trace in the SIEM.
The DNS resolution log, the proxy log for HTTPS traffic, the VPN authentication log: each of these represents an investigative thread. Each one that does not exist is a question that stays unanswered.
What Forensics Can Reconstruct and What It Cannot
Not everything is lost when logs are absent. Disk forensics can reconstruct evidence that log-based investigation cannot, and for incidents that are caught early enough, significant evidence may still exist on systems that have not been wiped.
Filesystem artifacts - prefetch files, shellbags, jump lists, LNK files - record program execution and file access in ways that survive beyond what logs capture and can be pulled from a forensic image. Browser history and download records can establish which tools an attacker retrieved. Event log entries that were never forwarded to the SIEM may still exist on the local system. Registry hive artifacts record persistence mechanisms and can establish a rough timeline of activity.
The limitation is obvious: this evidence exists only on systems that were not wiped, reimaged, or terminated before forensic acquisition. Cloud infrastructure that auto-terminates instances, endpoints that were reimaged as part of a hasty remediation, servers that were spun down months into the attacker's presence - the forensic artifacts go with the system.
Log evidence and forensic artifact evidence are complementary. Good investigators use both. But they are not substitutes for each other. A missing log source cannot be backfilled from a disk image. Evidence that requires forensic acquisition cannot be reconstructed from logs that were never written. When both sources have gaps, the gaps compound.
Why Retention Decisions Get Made Wrong
Log retention is treated as an infrastructure cost question. The conversation is about storage pricing, SIEM licensing fees, and whether the security budget can absorb an additional tier. Nobody in that conversation is representing the hypothetical future investigation.
The person who decided on 30-day retention made a rational decision given what they were optimizing for. They were not optimizing for a breach scenario where the attacker has been present for nine weeks. They were optimizing for operational cost on a non-incident day, which is what most days are.
The right framing is insurance. The additional cost of 90-day hot retention for your most critical log sources - endpoint telemetry, authentication events, network flows, cloud API logs - is knowable in advance. The cost of investigating a breach without that data is not knowable in advance but is consistently higher than the storage it would have taken to keep it.
What Good Retention Actually Looks Like
For high-value log sources, 90 days of hot searchable retention is a reasonable baseline. Authentication events, privileged access activity, endpoint process and network telemetry, cloud API logs for critical services: these are the sources that drive most breach investigations, and losing them at 30 days makes investigations substantially harder.
Cold retention for a longer period - 12 to 18 months - provides a backstop for incidents with very long dwell times and for regulatory investigations that may look back further than the initial incident window. Cold storage is cheaper and the query access is slower, but it exists, which is what matters when a regulator asks what data existed at a specific date.
Enable the sources that are off by default, deliberately and with documentation of the cost. Data events in cloud environments, script block logging on Windows endpoints, DNS query logs, proxy logs for encrypted traffic. Run a tabletop that asks what sources you would need to answer the key questions from a realistic breach scenario. If the answer is "a source we are not collecting," that is a gap worth closing before the scenario is real.
The logs that would have told you everything are being deleted on a schedule right now. Changing that schedule is one of the cheaper investments in your incident response program, and it is the only one that works retroactively.