Chain of Custody

The claim a custody record can actually support

This is written for counsel weighing how much weight a web collection will carry before an opponent starts pulling on it. Traditional chain of custody assumes a physical object that is seized, sealed, logged and stored. Web evidence has none of those properties: the original sits on a server the examiner does not control, it may be different for different requesters, it may change or vanish without notice, and there is no moment of seizure at all.

So the claim has to be stated as narrowly as the facts allow — and stated that way it is provable:

On this date, at this time, from this network, using this software, a request to this URL returned these bytes, and those bytes have not changed since, as shown by these hashes.

That sentence is the whole product of a custody record. "This is what was on the internet" is a larger claim, it is not provable by any collection method, and no product makes it so. Everything below exists to make the first sentence checkable by somebody else.

Why the physical evidence model does not transfer

The physical model works because each step has a boundary: an item is picked up, bagged, initialed, signed over and stored, and every transfer has two people and a time. Web evidence breaks each of those assumptions, and each one is a place an opponent will probe.

• There is no seizure. Nothing is taken from anyone. A copy is made, and the source keeps operating and keeps changing.
• The source is not fixed. Two examiners requesting the same URL at the same second can be served different bytes depending on login state, location, device, experiment assignment or account history.
• The source can disappear. A page can be deleted, edited, moved behind a login or excluded from an archive between collection and production.
• There is no neutral custodian. The party holding the original is a platform with no involvement in the matter and no obligation to anyone in it.
• Copies multiply silently. Files pass through email, cloud sync and shared drives, and cloud sync rewrites modification times without anyone touching the file.

What replaces the physical chain is documentation created at the time and hashes computed at the time. Those are the only substitutes available, and nearly every real defect in this subject is one of the two done late.

The guidance that exists, and the standard that does not

There is no US standard specific to chain of custody for web evidence, and no accreditation for it. That is worth saying out loud, because a product described as "compliant" with such a standard is describing something that does not exist. What does exist is guidance from four directions, all of it guidance rather than rule.

NIST SP 800-86 remains the most-cited US government publication in this space, and its custody language is plain:

"a clearly defined chain of custody should be followed to avoid allegations of mishandling or tampering of evidence. This involves keeping a log of every person who had physical custody of the evidence, documenting the actions that they performed on the evidence and at what time, storing the evidence in a secure location when it is not being used."

— NIST SP 800-86, August 2006, read 15 August 2026

Two caveats travel with it: the document is from 2006, and it was written for incident response rather than litigation. Its four-phase structure is still a defensible spine, and its verification language — computing digests of the original and the copy and comparing them — is what a web collection does. The more current text is SWGDE 18-F-002, which directs that collection notes be created contemporaneously — software employed, logs, reports, screenshots of the interface — and that custody documentation carry a unique identifier and the date and time of receipt.

The collection log is the artifact, not the paperwork

A capture log looks like administration and is actually the record everything else rests on. It is what a certification under FRE 902(13) is written from, it is what lets a second examiner repeat the collection, and it is the only place the environment is recorded, because the environment is not recoverable from the files afterwards. At minimum it should carry:

• Date and time with timezone, and the time source the machine was synchronized to.
• Examiner, machine, operating system, browser and version, and the capture tool and its version.
• The IP address and network used, and whether a VPN or proxy was in place — because the page served depends on it.
• Whether any account was logged in, and which.
• The exact URLs collected, with protocol, in sequence and untruncated.
• The hash of every file and of the manifest, recorded at the moment of collection.

Around the log sit three habits: write the scope down before collecting; repeat the acquisition later where content is dynamic, per SWGDE 21-F-001; and re-verify the hashes before production, recording the verification. The habit skipped most often is the cheapest: preserve the negative results. A log entry showing a URL returned 404 on a given date is evidence. A log that quietly omits the failed attempt is a gap, and it is the kind of gap that gets found.

What breaks a chain

The failure modes here are boringly consistent, which is good news: all of them are avoidable, and none requires special equipment to avoid.

• A gap between capture and hashing. A hash computed a week after collection proves integrity from that week forward, and the intervening week is unaccounted for. The most common real defect and the most avoidable.
• Editing an exhibit after collection. Cropping a screenshot, converting a PNG to PDF or tidying an HTML file changes the bytes and breaks the hash. Derived exhibits are fine — they have to be identified as derived, with the original retained.
• Collection by an interested party with no log. A client's own phone screenshots, emailed, with no record of when or how. Frequently the only thing that exists; always the weakest.
• Undocumented tooling. A capture made with an unnamed browser extension whose behavior nobody can describe cannot support a certification that the process produces an accurate result.
• Clock problems. An unsynchronized clock, or a log recording local time with no timezone. Timestamps in browser and platform artifacts are stored in several epochs — WebKit microseconds since 1601, Unix seconds, PRTime microseconds — and mis-conversion is a repeated source of wrong timelines.
• Custody by too many hands. Files passed through cloud drives and email with no log of who held what and when.
• Losing the source. If the page is gone and the only artifact is a screenshot with no headers, no hash and no third-party copy, the exhibit rests on one person's word.

Every item on that list is a step reconstructed afterwards rather than documented at the time. That is the whole pattern, and it is why a protocol written before collection outperforms a better tool used without one.

Custody of material you did not collect

Most of what an examiner handles was collected by somebody else: a platform production, a client's own export, a native file produced by the opposing party, images sent by a witness. Custody still applies, and it starts at receipt rather than at creation.

Record what arrived, from whom, by what channel, at what date and time, and hash it on receipt before anything is opened or converted. SWGDE 18-F-002 directs that where data is produced electronically — email attachments, cloud storage — a local static copy be created and the source documented, such as by preserving the original email or the complete hyperlink. That is the difference between a production that can be traced and a folder whose provenance is a memory.

Self-service exports deserve a specific caution, because they look more authoritative than they are. Meta's Download Your Information, its data-logs export announced by Meta Engineering on 4 February 2025, and Google Takeout all produce structured archives without legal process where the account holder cooperates. Two things are true of each: the export is the account holder's view, produced on demand and carrying no custodian certification, and its completeness is defined by the platform rather than by the request.

The clock, and why the first week decides the second year

Custody documentation cannot recover what no longer exists, and the clocks in this subject are short and of different lengths. Server logs on many hosts rotate in days to weeks. Meta's published law-enforcement guidelines state that it does not retain data for law-enforcement purposes absent a valid preservation request received before the user deleted the content. X publishes that some information, giving IP logs as its example, may be stored only for a very brief period, and publishes no figure. Internet Archive captures can be excluded on a site owner's request.

The consequence is arithmetic rather than argument: the first week of a matter determines what is provable in year two, and nothing done in year two recovers it. What preservation duty attaches, to whom, and what follows a failure to preserve are questions for counsel, and I do not answer them. What I can say is which records have short clocks, who holds them, and what a request has to name to be actionable.

What a perfect chain still does not establish

A flawless custody record establishes that the files produced are the files collected. It is worth having, it is achievable, and it is where the honest statement stops. It establishes nothing about:

• Whether the collected page was the page the public saw. The collection is one requester's view of a server that may serve differently to others.
• Whether the content is true. Custody is silent on falsity in both directions.
• Who wrote it. Authorship lives in platform records and device artifacts, not in the custody log.
• How many people read it. No custody practice measures exposure, and no platform metric measures readers.

Each is a separate question answered by a different method, and letting a well-documented chain imply the rest is the central overstatement risk in this discipline. It is also the easiest thing for an opponent to expose, because the overstatement usually sits in a report's summary rather than in its data. Stated at its correct size the method is strong: another examiner given the same log, the same manifest and the same files verifies the same hashes and reaches the same conclusion about integrity. A narrow claim survives contact with someone trying to break it.

Frequently Asked Questions

Published 2026-08-15