What a custody record is actually for
Chain of custody is the documented history of who held a piece of evidence and what they did with it. It attaches to records from every layer of a domain matter — registry, registrar, DNS, hosting, third-party archive — and it belongs to none of them, because its subject is not the domain. Its subject is the examiner's own conduct.
That is what makes it the section of a report most directly exposed to challenge. Everything else in a domain report describes something a third party did. This part describes what the expert did, and it is the one area where the expert is the only available witness. The purpose of the log is that a challenge to an exhibit can be answered with a record rather than a recollection.
It is also unglamorous work that is either done at the time or not done at all. NIST's guidance describes maintaining a log of every person who had custody of the evidence, documenting the actions they performed and at what time, and storing the evidence securely when not in use (NIST SP 800-86). SWGDE adds that the record should easily identify each person taking possession, with evidence descriptions, receipt times and all transfers. None of it can be assembled afterwards from memory.
The collection log, written as the work happens
The operative document is a single append-only collection log for the engagement — a record that can be added to but not rewritten. Each entry records date, time and time zone, the operator, the source queried or file received, the tool and version, the exact action taken, and the result.
SWGDE's requirement is that detailed collection notes be created contemporaneously, including the software employed, logs, reports, screenshots of the interface, downloaded data size, number of files, file names and hash values. NIST similarly calls for a detailed log of every step taken to collect the data, including information about each tool used, so that others can replicate the procedure. Tool selection and the reasoning behind it are part of the deliverable rather than background: the reporting phase includes describing the actions used and explaining how the tools and procedures were selected.
Contemporaneous means written at the time the thing happened. This is the one hard timing rule in an area that otherwise borrows its deadlines from elsewhere, and it is where the common failure occurs. A log reconstructed a month later from file timestamps and memory is a different kind of document than a log written as the work proceeded, and the difference is visible to anyone who looks at it closely.
Integrity is a hash comparison, not an assertion
Integrity is demonstrated arithmetically or it is not demonstrated. NIST describes verification as using tools to compute the message digest of the original and copied data and then comparing the digests to confirm they are the same. A message digest, or hash, is a fixed-length fingerprint of a file; any change to the file produces a different fingerprint.
Two practices follow. Hashes are computed at capture, under more than one algorithm — SWGDE recommends multiple algorithms to guard against a hash collision, where two different files produce the same fingerprint. And a verification hash is recalculated after acquisition, and again before any re-examination, to confirm that nothing has changed in storage.
The manifest carrying those values travels with the capture set rather than living somewhere separate. This sounds procedural because it is, but it has a direct evidentiary consequence: in United States federal practice the certification route for data copied from an electronic device, storage medium or file turns on authentication by a process of digital identification (FRE 902). That phrase is what makes the hash record a working part of an authentication path rather than housekeeping. Whether and how any rule applies in a given matter is for counsel.
Sealed original set, separate working copy
The discipline NIST describes is making a copy of the evidence, performing examination and analysis using only the copy, and verifying the integrity of both original and copy. In domain work that means a sealed capture set that is never edited, renamed, converted or re-saved after collection, and a separate working copy where every piece of analysis is done.
The failures here are mundane and they recur. Files inside the sealed set get renamed for tidiness, which changes nothing about their contents and everything about the story. Captures get converted to PDF for convenience, at which point the operative copy is a derivative nobody hashed. Evidence files get emailed, so the version in circulation is an attachment with its own history. Capture sets get stored in a location where files are silently re-written or synchronized, and the modification times all shift.
None of those is fatal alone, and all are avoidable at zero cost by deciding once, at the start, where the sealed set lives and that nothing touches it. When something does go wrong — a file altered, a set moved — it goes in the exception log. An acknowledged anomaly with a hash trail is manageable. An unacknowledged one found by someone else is not.
Productions enter custody too
Custody is easy to think of as applying only to what the examiner collected. It applies equally to what arrives from somebody else. Records produced by a registrar, a registry, a hosting provider or an opposing party enter custody on receipt, and they belong in the same log as self-collected captures.
What gets recorded is the transmittal itself, the date and time of receipt, the form in which the material arrived, the hash of each file as received before anything is opened or extracted, and every subsequent handling step. Hashing on receipt is the step that gets skipped, and it is the one that matters, because it fixes the state of the production at the boundary between the custodian's handling and the examiner's.
That boundary is also the limit of what an expert can honestly say. The examiner cannot document what happened to a record inside a custodian's systems before transmittal, and should not purport to. What he can document is exactly what was received, when, in what form, and everything since. Where the material later passes to counsel, a vendor or a second expert, each transfer is logged with recipient, date and time, form and verifying hash — and from there completeness depends on people who did not write the protocol.
What a chain of custody cannot establish
It cannot establish provenance. Custody begins at collection, not at creation. For a registrar-produced record, everything that happened inside the custodian's systems before the transmittal is outside the examiner's knowledge, and a custody log documents handling rather than origin.
A hash cannot establish accuracy. It shows that a file has not changed since the digest was computed, and nothing earlier. It says nothing about whether the captured page, response or log reflected reality at the moment of capture, and nothing about whether the source was authentic. An expert who describes a hash as proving a record is genuine has overstated a narrow and useful fact.
It cannot cure non-reproducibility. Web captures frequently cannot be repeated, because responses depend on visitor credentials, browser, location, date and time. A custody log makes that explicit; it does not fix it.
It cannot vouch for a third-party archive. What the examiner can document is the retrieval he performed. The archive's own crawl history, exclusions and lag sit outside anything he can attest to.
And it cannot survive multi-party handling on its own. Once material passes to counsel, a vendor or another expert, the chain depends on entries other people make. It is also worth noting that NIST SP 800-86 dates from 2006: its principles hold, but some of its specific tooling references predate cloud DNS, CDNs and the current registration-data regime.
Reproducibility when the source has already moved on
The stated purpose of a collection log is that a second examiner, given the same log and the same sources, can repeat the steps and reach the same place. In domain work, full repetition is frequently impossible. The live record has moved on: the page changed, the redirect was removed, the registration data was updated, the log aged out. The thing being reproduced no longer exists.
That changes what the log is for. Where a second examiner cannot re-run the capture, the record of how the original capture was made becomes the only thing available to evaluate. Which resolver answered, which user agent was sent, whether redirects were followed, what time zone the workstation was set to, which archive snapshot was retrieved and when it was crawled — these stop being metadata and become the substance of what can be assessed.
So the log is written for a reader who cannot check the source. Every parameter that could have changed the result is recorded, not just the ones that seemed interesting at the time. And where a capture could not be repeated even by the original examiner — a page that rendered differently an hour later, a redirect that fired once and not again — that is written down with the conditions of both attempts.
How custody appears in the report, and under questioning
The custody file is a distinct deliverable from the evidence: the collection log; the manifest of every artifact with its size and multiple hash values; the transfer record showing who received what, when, in what form, verified by which hash; a description of how and where the material is stored; and an exception log recording any item altered, any capture that could not be reproduced, and any handling anomaly.
In the report itself, the methodology section describes the process, names the tools and versions, explains why they were chosen, and states plainly what the custody record does and does not establish. That last sentence is the one that does the work. A custody record establishes that these files are the files that were collected, at those times, by that person, and that they have not changed since. It does not establish that their contents are accurate, or that anything happened before they were collected.
I have testified in domain-related legal cases and provided expert witness reports in others, and this is the material that comes up most reliably, because it is the part where the expert is the witness to his own conduct. The current record of engagements and credentials is maintained at hartzer.com rather than on this site.