Evidence Preservation Deadline Calculator
Digital evidence does not wait for a discovery schedule. Enter the incident date, select the systems that might hold relevant material, and see when each source's default retention window closes — with the licence tier every figure depends on stated beside it, and no date at all for the sources that do not expire on a clock.
- SOURCES
- 12 across 6 groups
- BASIS
- Published vendor defaults
- OUTPUT
- Triage order, not a diary date
- COST
- Free · no sign-up
- STATE
- Nothing leaves your browser
- UPDATED
- Verify against current vendor docs
Retention windows on the systems that matter most in a digital evidence case are measured in weeks, not years — and the two or three most probative sources on a workstation do not expire on a clock at all, but are overwritten as the machine keeps being used. This calculator maps an incident date against the published default for each source, states the licence tier that default applies to, and refuses to print a date where no honest one exists.
Work out the windows
The date the conduct occurred, or the date the duty to preserve was triggered — whichever is earlier. Retention runs from the event, not from the day you found out about it.
Enter a date and select at least one source to see the windows.
How to read the output
A default is a claim about one product, at one licence tier, at one moment in time — and all three of those move.
The dates this tool produces are a triage order. They tell you which source to chase on Monday and which can wait until Thursday. They are not deadlines you can diary, and treating them as such is the error the tool is designed to prevent, because three things routinely make a published default wrong in a live environment:
- An administrator has already changed it. Almost every retention period on this page is a setting. In a real tenant it has usually been touched — sometimes shortened for cost, sometimes lengthened for compliance, occasionally changed after the incident and before the letter arrived. That last case is itself a finding.
- The vendor has changed it. Microsoft raised the Audit (Standard) window from 90 days to 180 in late 2023. Slack replaced the free plan’s 10,000-message cap with a 90-day visibility window in 2022 and has since moved to deleting older free-plan data outright. A figure that was right when it was written is not thereby right now, which is why every row below carries the tier it applies to and an instruction to confirm it.
- It was never switched on in the first place. Object-access auditing on Windows file servers is off by default. Unified audit logging was off by default for tenants created before 2019. Where the logging never ran, nothing was retained and nothing was destroyed — and the difference between “the record was deleted” and “the record was never kept” is usually testable and is frequently the entire dispute.
The sources with no computable deadline
Volume Shadow Copies and the Windows event logs are the two entries here that will never produce a date, and that is the most important output the tool has. Neither is retained for a period. A shadow copy survives until write activity on the volume forces the oldest one out of a fixed storage allocation; an event log channel overwrites when a fixed byte cap fills. Coverage is therefore inversely proportional to how busy the machine is — months on an idle workstation, hours on a domain controller — and continuing to use the machine is itself what destroys the evidence. There is no date to put in a calendar. There is only the decision to take the device out of service, which is why it ranks above every calculated deadline on the page. What a defensible acquisition actually involves is set out on the computer forensics page.
When the duty to preserve starts
The obligation attaches when litigation is reasonably anticipated, which is generally earlier than the filing of a complaint and often earlier than the sending of a demand letter. That is the date to enter above, not the date the matter opened, because retention runs from the event rather than from the day anyone found out about it.
If electronically stored information that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery, the court: (1) upon finding prejudice to another party from loss of the information, may order measures no greater than necessary to cure the prejudice; or (2) only upon finding that the party acted with the intent to deprive another party of the information’s use in the litigation may presume that the lost information was unfavorable to the party, order the jury to presume it, or dismiss the action or enter a default judgment.
The rule is quoted here because it is what the arithmetic on this page is in aid of, not because this page can tell you how it applies to your matter — it cannot, and the analysis is fact-specific and venue-specific. Two features of it are worth noting against the output above. It turns on whether reasonable steps were taken, which is a question about what was done and when, and a contemporaneous record of the systems identified and the dates the letters went out is the evidence of it. And the severe measures in subsection (2) require a finding of intent, which is a considerably higher bar than a source having aged out on its own schedule while nobody was looking. The enterprise log analysis page covers what each server-side source records and how the timeline is reconstructed once preservation has happened.
The retention reference table
Every source the calculator knows about, with its default, the licence tier that default applies to, and the reason the real answer may differ. This table is the tool’s source data — the calculator does nothing to it but add an incident date.
| SOURCE | DEFAULT RETENTION | APPLIES TO WHICH TIER | WHY THE REAL ANSWER MAY DIFFER |
|---|---|---|---|
| Microsoft 365 unified audit log — Audit (Standard) | 180 days | Audit (Standard), which is what E1/E3, Business Basic/Standard/Premium and equivalent education SKUs carry | Microsoft raised the Standard default from 90 days to 180 in late 2023, and the change applied to supported record types going forward rather than resurrecting data that had already aged out. Some record types remained at 90 days through the transition, and an audit retention policy configured in the tenant overrides the default in either direction. Audit logging is on by default for tenants created since 2019 — for older tenants it may never have been enabled at all, in which case there is nothing to preserve and the right finding is that the record was never kept. |
| Microsoft 365 unified audit log — Audit (Premium) | 365 days | Audit (Premium), which requires E5, an E5 Compliance add-on, or a per-user Audit add-on licence — and the licence must be assigned to the custodian, not merely owned by the tenant | A ten-year retention add-on can extend this further where it has been purchased and a retention policy created for the record type. Retention is driven by the licence on the individual user at the time the event was generated: an unlicensed custodian's events fall back to the Standard window even in an E5 tenant. |
| Exchange Online deleted items and Recoverable Items | 14–30 days | Exchange Online mailboxes on any current plan. The deleted-item retention period is a mailbox setting with a 14-day default and a 30-day maximum | A litigation hold, an eDiscovery hold, or a Purview retention policy suspends the purge and holds Recoverable Items indefinitely, which is why applying the hold is the first step rather than a later one. Without a hold this is one of the shortest windows on the list, and it starts running from the deletion, not from the incident. |
| Google Workspace admin and investigation logs | ~180 days | Most Workspace editions, for the principal log types — admin, login, Drive, Groups, Calendar, token and device audit logs are commonly retained around six months | Google publishes a per-log-type retention table and the periods are NOT uniform: email log search is materially shorter than the audit logs, some log types differ by edition, and the security investigation tool is limited to specific editions. Treat six months as the planning figure for the main audit logs and check the specific log type you need against Google's current table before relying on it. |
| Google Workspace deleted files, mail and accounts | 20–30 days | Current Workspace editions. Drive trash empties automatically on a 30-day cycle; a deleted user account can be restored by an administrator only within a short window measured in weeks, commonly stated as 20 days | Google Vault retention rules, where the edition includes Vault and a rule was created BEFORE the deletion, preserve data past these windows. Vault is not retroactive: a rule created after the purge recovers nothing. An administrator emptying trash, or a user purging it, closes the window immediately regardless of the default. |
| Slack messages and files — paid workspace | No time-based default | Pro, Business+ and Enterprise Grid. The out-of-the-box setting keeps messages and files for the life of the workspace | There is no clock here by default, which makes this the source most often destroyed by a CHANGE rather than by expiry: a workspace owner can set a custom retention period of any length, and doing so deletes everything older than that period on the next run. Whether edits and deletions are recoverable at all depends on plan and on retention settings that must have been enabled beforehand. Discovery API access, which is how a defensible export is usually taken, requires Business+ or Enterprise Grid. |
| Slack messages and files — free workspace | 90 days | Free plan. Since Slack's 2022 change, a free workspace displays roughly the most recent 90 days of message history | Older material was initially hidden rather than deleted and could be restored by upgrading the workspace — but Slack has since moved to deleting free-plan data past a stated age, so the practical assumption should be that anything outside the visible window may be gone rather than merely hidden. Upgrading the workspace is the step that preserves it, and it has to happen before, not after. Confirm Slack's current free-plan policy directly; this is the figure on the list most likely to have moved. |
| EDR / endpoint telemetry | 7–180 days | Entirely vendor- and tier-dependent. Raw process, file and network telemetry is commonly retained for days to weeks at base tiers; alert records and device timelines usually persist longer than the raw events behind them; extended retention is generally a paid add-on | The band above is wide because it has to be. Some platforms retain raw hunting data for as little as a week at entry tiers; others retain a device timeline for months while the underlying events used to build it have already aged out — which produces the trap of an alert you can see and evidence you can no longer export. Retention may also differ between the vendor's cloud and any on-premises collector. Do not plan against a single number; ask the vendor or the security team for the figure that applies to your tenant and tier, in writing. |
| Firewall, VPN, proxy and NetFlow logs | 7–90 days | No cross-vendor default exists. Where these are shipped to a SIEM the window is whatever the SIEM licence and storage tier allow; where they are kept on the appliance, the window is a function of log volume against a fixed buffer | These are commonly the shortest-retention sources in an enterprise and are frequently the ones that would show whether data actually left. On-appliance logging in particular rotates by SIZE rather than by age, so a single noisy day can consume the buffer that would otherwise have held a month. An address in these logs identifies a network endpoint and not a person, and NAT, VPN pooling and DHCP reassignment all sit between the two. |
| Volume Shadow Copies | No time-based default | Windows client and server. Shadow copies are pruned when the volume's shadow-storage allocation fills — on client Windows the default maximum is a percentage of the volume, commonly cited as 10% | There is NO time-based expiry here and this tool will not print a date for one. The oldest shadow copy survives until write activity on the volume forces the oldest out, so the real window can be months on an idle workstation and hours on a machine being actively used — including a machine being used by someone deleting things. Continuing to use the machine is itself what destroys this evidence, which is why taking the device out of service ranks above every calendar deadline on this page. |
| Windows event logs (Security, System, Application) | No time-based default | Windows client and server. The default channel size is a fixed byte cap with 'overwrite events as needed' — not a retention period | Because the cap is a size and not a date, coverage is inversely proportional to how busy the machine is: a domain controller may hold hours, a workstation months, and neither figure is knowable without looking. Two further limits matter more than the window. Most object-access auditing is OFF by default, so the absence of a record often means the system was never keeping it rather than that the event did not occur. And a logon event names an ACCOUNT and a session, not a person. |
| CCTV and video surveillance | 14–30 days | No general default exists in law or in product. Two to four weeks is a common commercial configuration, set by the recorder's storage capacity against camera count, resolution and frame rate — some regulated settings and some jurisdictions impose their own minimum or maximum periods | Recording is a fixed-size loop: the window shortens whenever a camera is added or a resolution raised, and it is not unusual for a system nominally set to 30 days to hold 11. Retention of surveillance footage of identifiable people is also regulated in some jurisdictions and by some employment agreements, which can cut the window shorter still. Export the specific clips; do not rely on the recorder. |
What each source actually records
Preserving the right systems is only half of it. The other half is knowing what the preserved data can support once you have it — a distinction the artifact and claim explorer is built around.
Microsoft 365 unified audit log — Audit (Standard)
Tenant-wide activity events: sign-ins, mailbox operations, SharePoint and OneDrive file access and sharing, Teams events, admin changes.
CONFIRM → Purview compliance portal → Audit → Audit retention policies, plus the licence assigned to the specific custodians. Run a search for the custodian at the oldest date you need and see whether results return.
Microsoft 365 unified audit log — Audit (Premium)
The Standard event set plus additional high-value events, with longer retention and higher API bandwidth.
CONFIRM → Check the per-user licence assignment for each custodian and the audit retention policies configured in Purview, then test a search at the boundary date.
Exchange Online deleted items and Recoverable Items
Messages the user deleted, including items purged from Deleted Items, held in the Recoverable Items folder until the retention period expires.
CONFIRM → Get-Mailbox <identity> | Format-List RetainDeletedItemsFor, LitigationHoldEnabled, InPlaceHolds — and confirm the hold actually applied rather than merely being configured.
Google Workspace admin and investigation logs
Administrative changes, sign-in events, Drive file activity and sharing changes, Groups membership and posting activity, device and token grants.
CONFIRM → Google's published 'Data retention and lag times' table for audit and investigation logs, checked for the specific log type and your edition — then run the query at the boundary date in the Admin console.
Google Workspace deleted files, mail and accounts
User-deleted Drive files still in trash, and the mailbox and Drive contents of a deleted user account.
CONFIRM → Admin console → Users → Deleted users for the account window, and Vault → Retention for whether a rule was in force on the relevant dates.
Slack messages and files — paid workspace
Channel and direct messages, file uploads, and — on Enterprise Grid with the setting enabled — edit and deletion history.
CONFIRM → Workspace settings → Message retention & deletion, checked for the setting AND for when it was last changed. Ask the administrator directly whether retention has been altered since the incident.
Slack messages and files — free workspace
Channel and direct messages and file uploads within the window.
CONFIRM → Slack's current published free-plan limits, plus a test scroll to the oldest reachable message in a busy channel.
EDR / endpoint telemetry
Process execution, parent–child process relationships, file writes, registry changes, network connections and script activity on the endpoint.
CONFIRM → Ask the security team for the retention period of RAW telemetry, not of alerts, for the specific console and licence tier — and export the relevant window now rather than relying on the console remaining queryable.
Firewall, VPN, proxy and NetFlow logs
External destinations reached, session start and end, bytes transferred, source and destination addresses, and VPN authentication events.
CONFIRM → Ask for the oldest available log line, not the configured retention period — the two frequently disagree — and preserve an export rather than a screenshot.
Volume Shadow Copies
Point-in-time copies of files as they existed when the snapshot was taken, including files subsequently deleted or modified.
CONFIRM → vssadmin list shadows on the live machine shows what currently exists — and running it does not preserve anything. Image the device.
Windows event logs (Security, System, Application)
Logon and logoff events, account changes, service installs, scheduled task creation, and — only where the audit policy was configured for it — object access.
CONFIRM → Check the oldest event actually present in each channel on the specific machine, and check the audit policy in force at the time of the incident — not the policy in force today.
CCTV and video surveillance
Who was physically present, and when — frequently the only corroboration available for the step from an account to a person.
CONFIRM → Ask the facilities or security vendor for the oldest recoverable timestamp on the specific cameras, and get the clips exported to file with their metadata now.
What this tool does not tell you
- It does not tell you what is actually in your environment. Every figure is a published default. The only number that matters in a dispute is the oldest record that actually survives in the specific system, and that is established by asking the administrator for it in writing — not by reading it off this page.
- It cannot tell you whether logging was ever enabled. Where it was not, nothing was retained and nothing was destroyed. A calculated expiry date for a log that never existed is worse than no output at all, and this tool has no way to distinguish the two cases.
- It does not print a date for sources that have no clock. Shadow copies and Windows event logs are overwritten by activity, not by time. If the tool showed you a date for those it would be inventing one.
- It is not a legal analysis of your preservation obligations. When the duty attached, how far it reaches, what proportionality permits, and what Rule 37(e) or your state’s equivalent would require on these facts are questions for counsel in the forum, and nothing here is advice about any of them.
- It does not account for holds, backups or archives. A litigation hold, a Vault retention rule, a journaling archive or a backup that predates the incident can preserve material long past the windows above — and equally, a hold applied after the purge preserves nothing. Both cases change the answer and neither is visible to a calculator.
Questions counsel ask
How long does Microsoft 365 keep the unified audit log?
Which evidence source expires first?
Does a litigation hold stop the clock on cloud retention?
Can I rely on the dates this calculator produces?
What should a preservation letter actually ask for?
If a window on this page has already closed, or is about to, the next step is usually a scoped preservation plan rather than a broader engagement — which systems, in which order, by what method, and what gets documented at the time so the sequence can be defended later.
Bring the output above and it becomes the agenda for the call.
A conflicts check and scoping call follow, normally within one business day. Please do not send privileged or case-sensitive material until conflicts have cleared.
Other tools
- TOOL 02 / ARTIFACTSCan This Artifact Prove That?
Pick the claim you need to support. See which artifacts bear on it, what each one actually records, and — the half that matters on cross — what none of them establishes.
- TOOL 03 / RETENTION DILIGENCEExpert Vetting Checklist
The nine-step vetting procedure and the eight documents to request, as a checklist you can work through, save in your browser, and print for the file.
- TOOL 04 / RULE 702Daubert Exposure Check
Twelve questions about an expert's methodology, mapped to the six failure modes that account for most digital-forensics exclusions, with the remediation for each gap.
- TOOL 05 / DISCLOSURERule 26 Report Check
The six things Fed. R. Civ. P. 26(a)(2)(B) requires a retained expert's report to contain, quoted in full, as a checklist against the report on your desk.
- TOOL 06 / JURISDICTIONDaubert or Frye Lookup
Which admissibility standard each state applies to expert evidence, including the states whose posture is mixed, state-specific, or has recently changed — and the amended federal Rule 702.
- TOOL 07 / SCOPEEngagement Scope Estimator
Build a scope schedule from device count, device type, question complexity, deadline and deliverable — the drivers that move a forensic estimate, itemised.
Attorney advertising / expert services. This tool describes forensic practice and the procedural rules that govern expert evidence in general terms. It is not legal advice, it does not create an attorney–client or expert-engagement relationship, and it is not a substitute for checking the rules, standing orders, and case law of your own forum. Retention figures are vendor-published defaults understood at the time of writing and are not warranted to be current. Prior results do not guarantee a similar outcome.