Forensic Proof of Spoliation Under Rule 37(e)

A Rule 37(e) motion can be technically sound and still fail, because the rule asks a sequence of separate questions and a forensic finding that answers one of them may say nothing about the next. Counsel arrives with a report showing that a disk-cleaning utility ran, or that thousands of files disappeared over a weekend, and treats that as the whole case. The useful contribution of an examiner on a 37(e) record is mapping each finding to the element it can carry, and saying out loud where it stops.

The elements the rule actually puts in play

Rule 37(e) applies only to electronically stored information that should have been preserved in the anticipation or conduct of litigation, that is lost because a party failed to take reasonable steps to preserve it, and that cannot be restored or replaced through additional discovery. All three thresholds must be met before the court reaches any remedy. Only then does the rule split: subsection (e)(1) permits measures no greater than necessary to cure prejudice, while subsection (e)(2) — adverse-inference instructions, adverse findings, dismissal — requires a finding that the party acted with the intent to deprive another party of the information's use.

Forensics speaks to some of these questions and is nearly silent on others. Whether a duty to preserve had attached is a legal question informed by dated facts an examiner can help fix: when a hold notice landed in a mailbox, when it was opened, when a custodian's device last synchronized with a mail server. Whether reasonable steps were taken is partly an evidentiary question about configuration — whether journaling was enabled, whether the mailbox was on hold, whether the laptop was reimaged on the standard offboarding schedule.

Restorability is where examinations often earn their keep and where they are most frequently overstated. An examiner can report that a file was recovered intact from a volume shadow copy, or that a deleted message survives in a server-side recovery store. An examiner cannot report that nothing else exists anywhere; absence in the sources examined is a statement about those sources and no more.

Intent is inferred from patterns: sequence, selectivity, and the presence of steps that are difficult to attribute to automated or routine processes. Even those steps require corroboration. Utilities run on schedules, ship preinstalled on vendor images, execute because a browser was configured to clear data on exit, or are launched by a technician following a runbook. A pattern that looks deliberate on the artifact timeline still has to survive the alternative explanations that live in the environment's own configuration.

Lost, destroyed, and never retained are three different findings

The rule is addressed to loss, and a great deal of ESI goes missing through mechanisms that involve no human decision at the relevant moment. A mailbox retention policy purges items on a schedule set years earlier. A chat platform's default expiry runs on its own schedule, which varies by product, license tier, and tenant configuration. A device is reimaged under an offboarding runbook by an IT technician who never heard of the case. Logs roll over. Conflating any of that with destruction invites a response that reframes the motion as an attack on ordinary system behavior.

An examiner should separate three categories in the report itself. First, data destroyed by an affirmative act traceable to an account associated with a custodian, or to a scheduled task configured from such an account — and the same attribution caveat applies here as anywhere else, because shared credentials, remote administration, and delegated access remain live competing explanations for any act traced to an account. Second, data lost through automated processes that predate any duty. Third, data that was never retained at all, because the system was not configured to keep it.

The third category is the one litigators underweight. A messaging application configured not to store history locally has no history to spoliate. A registry key that holds three timestamps per attached device is not a device-connection log. The USN change journal on a busy volume may cover days rather than months. Asking a court to infer destruction from a gap in a source that never covered the period in question is the fastest way to lose credibility on the rest of the motion.

What running a wiping tool leaves behind

Privacy and disk-cleaning utilities defeat file recovery by overwriting content, but they generally do not erase the operating system's own record that they executed. On Windows systems the useful sources include:

• Prefetch files, which record that an executable ran, the last several run times on modern versions, a run count, and a partial list of files and directories the process touched during startup. The store is capped, so a heavily used machine can age out an entry entirely.
• AmCache, which records program file paths, SHA-1 hashes, and first-observed times — evidence that a binary was present and cataloged, which is not the same as evidence it was launched.
• The application compatibility cache, which records path and file-modified time for binaries the loader has seen. On current Windows versions an entry is not proof of execution, and treating it as such is a standard cross-examination trap.
• UserAssist registry values, which record a run count and a single last-execution time per program under the interactive user's profile. One timestamp, not a history.
• Installer and download traces: browser download records, installer logs, the presence of an uninstall key, a portable executable on removable media.
• Security event ID 1102, which records that the security log was cleared, by which account, and when. It does not record what the log contained.

Together these can support a finding that a named tool was installed and executed on a specific machine at specific times by an account associated with a custodian. What they usually cannot establish is scope. Prefetch does not enumerate every file a wiper overwrote, and a tool run in free-space mode leaves no per-file record at all. If the motion needs to say what was destroyed, that has to come from the other side of the ledger: file system metadata for objects that no longer have content, backups, server-side copies, or the counterparty's own production.

Reading deletion patterns without overreading them

Mass deletion and selective deletion look different in the file system, and the difference matters to intent. The Master File Table retains entries for deleted files until they are reused, preserving name, size, parent directory, and the standard timestamp set. Recycle Bin $I records preserve the original path, size, and deletion time for items routed there. The USN change journal records per-file change reasons — file delete, data overwrite, rename — with sequence numbers that let an examiner reconstruct ordering even when clocks are unreliable.

From those sources an examiner can often show that several thousand objects under a single directory tree were deleted within a compressed window, that the deletions proceeded in a directory-walk order consistent with a scripted or bulk operation, or conversely that a handful of specific documents were removed while their neighbors survived. Selectivity is the more probative pattern for (e)(2) because it is harder to attribute to a general cleanup impulse. Personal photos and tax returns left in place while a project folder is emptied is a fact a court can weigh.

Two limits belong in the same paragraph as the finding. Timestamps are modifiable by both attackers and ordinary applications; discrepancies between the standard-information and filename attribute sets can flag manipulation, but their absence proves nothing. And the journal is circular. It is sized as a fraction of the volume and rolls over; on an active workstation it may not reach back past a few weeks. A claim about deletions from last spring cannot rest on a journal that covers only last month.

Factory resets: loud events, quiet aftermath

Modern phone erasure is cryptographic. Erase All Content and Settings on iOS and a factory reset on a current encrypted Android device discard the key material that makes stored data readable, which is why post-reset carving of user content is generally futile regardless of the tool used. The event itself is frequently recorded somewhere other than the device: in mobile device management console history, in carrier or account-level activity records, in the device's own subsequent setup and restore logs, and in the sudden absence of a device from backup schedules.

That gives an examiner a defensible pair of statements. A reset occurred on this device, initiated at this time, sometimes by an identifiable account or from a specific management console. And, separately, the reset makes the pre-reset contents unrecoverable from the handset, which speaks directly to the rule's restore-or-replace threshold.

What a reset does not tell you is what was on the device. Content of that kind has to be replaced from elsewhere: a cloud backup taken before the reset, a paired computer backup, the counterparty's copies of the same conversations, or server-side message stores. Establishing when the last surviving backup was taken is often the most consequential finding in a phone spoliation dispute, because it converts an unbounded claim of loss into a bounded one. Note also that an ordinary device upgrade produces a reset. The forensic fact stays neutral until it is placed next to the hold date.

Retention settings are conduct, and conduct is logged

Changing a retention policy is an administrative act performed through a console, which makes it among the best documented spoliation mechanisms. In major cloud collaboration suites, altering a mailbox retention tag, removing a litigation hold, shortening a workspace's message-retention window, or disabling an audit setting is an action attributable to an account and captured in a tenant audit log with a timestamp and, often, the prior and new values.

The mechanism worth explaining to a court is that these changes destroy nothing at the moment they are made. They alter what a scheduled process will delete on its next pass. That decoupling is why the timeline matters: the change may precede the actual loss by days, and the account that made the change may belong to someone other than the custodian whose data went away.

Two limits shape what the audit log can carry. Its retention is finite and depends on tenant configuration and licensing, so a record built before the available window is confirmed risks resting on a period the log no longer covers. And server-side recovery structures — recoverable-items stores, purge folders, versioning containers — often hold items for a defined interval after a hard delete, which means a prompt forensic request can sometimes retrieve what a policy change was about to eliminate. That possibility is not only a route to a remedy; it also bears on whether the information genuinely cannot be restored or replaced.

How far recovery from unallocated space really goes

Carving from unallocated space recovers content whose clusters have not yet been reused, identified by file signatures rather than by directory entries. It works well for contiguous files with strong headers and footers. It works poorly for fragmented files, for database and container formats, and for anything the file system has already handed to a new allocation.

The limitation that surprises litigators involves solid-state storage, and it is worth stating precisely because an opposing expert will correct a loose version of it. TRIM does not erase anything by itself. It is a hint from the operating system telling the drive controller that certain logical block addresses no longer hold live data. Depending on the drive's behavior, subsequent reads of those addresses may return zeros, and the controller's background garbage collection may erase the underlying NAND at some later point of its own choosing. TRIM also does not operate everywhere: some USB bridges and RAID paths do not pass the command, some virtualized or encrypted volume stacks do not propagate it, and it can be disabled at the filesystem or operating-system level.

The practical consequence still holds. On SSD-backed hardware with TRIM active, carving may return nothing for reasons that have nothing to do with anyone's conduct, and an examiner presenting an empty recovery result as evidence of intent should expect to be challenged on exactly that mechanism. Journal and log records fill part of the gap, because they can establish that a file with a given name and size existed and was deleted even when the content is gone. Metadata survives content routinely.

That is the practical shape of most well-built 37(e) records. Execution and configuration artifacts show the act. File system and journal metadata show the scope and sequence. Content recovery, when it succeeds, shows prejudice by demonstrating what the lost material actually was. Each of those three layers has its own expiry: the journal rolls over in weeks, the audit window closes on a schedule the tenant may not control, and an unimaged workstation keeps overwriting its own unallocated space every day it stays in service. How much of the record survives to be examined is largely settled by preservation steps taken long before anyone drafts the motion that will rely on it.

Attorney advertising / expert services. General information, not legal advice. Case examples are anonymized except where publicly identified.