Retention Windows and What Rolls Off Before You Arrive

The first question about a log is never what it shows. It is what period it covers and how you know — because most logs are fixed-size circular buffers, most high-value telemetry is switched off by default, and the window closes while people are still deciding whether to investigate. An examiner who can state each source's retention window, and the configuration that produced it, can say something useful about a gap. One who cannot is guessing.

What determines how long a log lasts?

Four mechanisms, and every source uses one of them:

Size-bounded rotation. The log has a maximum size; when it fills, the oldest records are overwritten or the file is rotated and an old generation deleted. Coverage is therefore a function of volume of activity, not of time. A busy server's security log may cover two days; an idle workstation's may cover two years. You cannot infer one from the other.

Time-bounded retention. Records older than a threshold are discarded regardless of volume. Common in cloud and SaaS platforms.

Licence-bounded retention. The same as time-bounded, except the threshold is a commercial term. This is now the single most common reason evidence does not exist.

No retention at all. The source was never configured to log, or logs to memory only. DNS query logging on an internal resolver is frequently in this category, as is systemd's journal when no persistent directory exists on disk.

For anything that matters, read the configuration off the subject system and put the numbers in the report. On Windows that means the configured maximum size and retention policy of each channel; on Linux, the journald size and retention settings and the logrotate configuration for each file; in cloud, the tenant's actual configuration and licence tier rather than a vendor's published default.

Which Windows sources are worth having, and which exist by default?

Windows event logs live as .evtx files under %SystemRoot%\System32\winevt\Logs. Beyond the three classic logs — Security, System, Application — the operational channels are usually where the answer is:

• Security — authentication and, if enabled, object and process auditing. Event 4624 records a successful logon with a logon type that tells you the kind: 2 for interactive at the console, 3 for network, 10 for RemoteInteractive (RDP), 7 for unlock, 5 for service, 4 for batch, 11 for logon with cached credentials. 4625 is a failed logon with a reason code. 4634 and 4647 cover logoff. 1102 records the Security log being cleared.
• System — service starts and stops, driver loads, unexpected shutdowns. Event 104 records another log being cleared.
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational and the related Terminal Services channels — remote session activity in more detail than Security gives you.
• Microsoft-Windows-TaskScheduler/Operational — scheduled task registration and execution, a standard persistence and execution route.
• Microsoft-Windows-PowerShell/Operational — event 4104 carries deobfuscated script blocks, and 4103 module logging carries pipeline detail. Both require being turned on.
• Microsoft-Windows-WinRM/Operational — remote management activity.

The hard fact underneath all of it: the telemetry that answers the most valuable questions is off by default. Process creation auditing (4688) requires an audit policy; capturing the process command line in those events requires a second, separate policy setting. PowerShell script block logging requires a policy. Sysmon is not installed unless someone installed it. Object access auditing on file shares is off. So when an examiner reports that there is no evidence a particular program ran, the overwhelmingly likely explanation is that nothing was ever configured to record it — and the report must say which.

EvtxECmd parses the channels with maintained event maps; Hayabusa and Chainsaw run detection logic across them at speed, using Sigma rules, which is the right way to triage a few hundred million events. Harlan Carvey's Investigating Windows Systems and Windows Forensic Analysis Toolkit both work through log-plus-artifact reasoning on real data, which is the skill rather than the parsing.

What about non-Windows and network sources?

Linux. systemd's journal is binary, and stored under /var/log/journal only if that directory exists — otherwise it is volatile and lost at reboot, which is a common and consequential surprise. Where it is persistent, it is bounded by configured size and retention settings. Alongside it, text logs rotate under logrotate configuration, which is per-file and must be read rather than assumed. wtmp, btmp and lastlog hold login records in a separate binary format and rotate on their own schedule. auditd, where deployed, is the closest Linux equivalent to detailed Windows auditing, and like it, is configuration-dependent. Practical Linux Forensics covers all of these in the detail the format documentation does not.

macOS. The unified log writes .tracev3 files under /var/db/diagnostics, read with log show. It is verbose, it rolls quickly, and its retention is short — days, typically — so on macOS the preservation clock is the tightest of the three platforms.

Network and infrastructure. Firewall, proxy, VPN concentrator and web server logs; flow records; DHCP leases; DNS queries. DHCP is the one people forget and then need: without a lease record you often cannot bind an IP address to a host at a given moment, and DHCP retention is frequently days. Zeek and Suricata produce network records designed for exactly this kind of reconstruction, and Wireshark is for the capture you already have. Richard Bejtlich's The Practice of Network Security Monitoring is the argument for collecting that data before you need it, and remains the clearest statement of it.

Cloud and SaaS. Retention here is a contract question. AWS CloudTrail's console event history covers a rolling 90 days; longer retention requires a configured trail delivering to storage, which is either there or is not. Microsoft 365 unified audit log retention is tier-dependent — commonly 90 days at base licensing, longer with higher tiers — and Entra ID and Google Workspace retention vary by log type and plan. Do not cite a published default in a report. Ask the tenant administrator for the configuration and the licence, get the answer in writing, and put that in the methodology section.

How do you preserve before the window closes?

This is the highest-value action available and it is available only early. A documented preservation request naming specific sources with specific retention windows is worth more than a general hold notice, because it shifts the argument from "we didn't think of it" to "you were told".

The consequences of getting it wrong are well mapped. Zubulake v. UBS Warburg and Pension Committee v. Banc of America Securities established the framework for preservation duties and their breach; VOOM HD Holdings v. EchoStar Satellite applied it to a party that failed to suspend routine deletion after litigation was reasonably anticipated. Federal Rule of Civil Procedure 37(e) now governs the federal remedy and its structure matters: curative measures where information is lost and cannot be restored, and the serious sanctions only on a finding of intent to deprive. Brookshire Brothers v. Aldridge is a useful statement of the two-step structure — the court decides spoliation as a question of law and then assesses a proportionate remedy, outside the jury's presence. And The Sedona Principles is where most of the practical proportionality reasoning about scope lives.

Where the source is a messaging platform with deliberately short or zero retention, the Sedona Conference commentary on ephemeral messaging is the document to read before forming a view.

How do you reconstruct activity from what remains?

Establish the window per source, in writing, with the configuration. Do this first. It determines which questions are answerable and stops you from spending a week on a question the data cannot reach.

Normalise to UTC and record each source's clock offset. Every log carries a clock and every clock is wrong by some amount. Sequencing events across two systems without establishing both offsets to a common reference produces a chronology whose foundation does not exist.

Corroborate across independent custodians. An authentication event at the identity provider, a DHCP lease, a VPN session record and a filesystem artifact on the endpoint are four sources with four clocks held by four parties. Agreement between them is a strong finding. Disagreement is a different and often more interesting one.

Read the negative space carefully. A gap in a rotating log is expected and means nothing. A gap in an otherwise contiguous log is different, and Windows gives you a way to detect it: each .evtx channel assigns a monotonically increasing record identifier, so a missing range, or a reset to a low number, is visible. Combine that with event 1102 in Security and 104 in System and you can distinguish "the log rolled" from "the log was cleared". That distinction is frequently the finding.

Go to raw where the conclusion depends on it. A SIEM's normalised view may have dropped records at ingestion, sampled, truncated long fields, or mapped two different source fields onto one. For triage that is fine. For a finding that will be tested, retrieve the original record.

Read the events against the artifacts. Logs answer "what did the system record". Filesystem and registry artifacts answer "what state did the system end in". Plaso will ingest event logs alongside filesystem and application artifacts into one normalised timeline, and Timesketch is where that becomes reviewable by a team rather than one analyst's spreadsheet.

What can logs not establish?

This is the section that makes a log analysis credible.

• Account, not person. A 4624 with logon type 10 establishes that a session was authenticated with a credential from a source address. It does not establish who typed the password, whether the credential was stolen, or whether a person was involved at all.
• Access, not exfiltration. A proxy record of a request establishes a request. Bytes transferred is a number about a flow, not a description of what was taken. If the claim is that data left, the log that supports the claim must be named and the inference stated as an inference.
• Absence is not absence of the act. This is the load-bearing limit. "No evidence of X in the logs" licenses only: no record of X exists in these sources, over this window, given this configuration. To get from there to "X did not happen" you would need to show that the artifact X necessarily produces was enabled, retained through the relevant period, and intact. On a real system you can almost never show all three.
• A log is only as trustworthy as the system that wrote it. An adversary with administrative rights can clear, edit or forge local records. This is the whole argument for off-host collection: records forwarded in near-real time to a system the subject does not control are evidence of a different quality, and the difference should be stated.
• Correlation across sources is an inference you constructed. The sources did not agree with each other; you decided they referred to the same event. Say so, say on what basis, and say what would falsify it.
• Volume is not significance. Ten thousand denied firewall events are a background condition on any internet-facing host.

Write the window, the configuration, the clock offsets and the limits into the methodology section before anyone asks. The ENFSI guideline on evaluative reporting, ISO 21043-4 on interpretation and ISO/IEC 27042 all converge on the same point: the strength and the boundaries of the inference are part of the finding. NIST's scientific foundation review of digital forensics reaches a similar place from the other direction, concluding the techniques are reliable when properly applied and naming the limits where they are not.

For formal training on the network half of this, GNFA is the established certification, and GCFA covers the host side. For free practice with known answers, CyberDefenders and the DFRWS forensic challenges both publish log-heavy scenarios, and DFIR Diva catalogues the no-cost training that is actually worth the time.