Someone asks you, months after you saved a web page: who captured this, how do you know it has not changed, and who has had it since? If you can answer with a dated log, the capture stands up. If you can answer only with "I think it was in the shared folder", you have a file and an argument.
That log is the chain of custody. This article sets out what to record at each step for a captured web page, and where chains most often break.
What a chain of custody is
That gives three things to write down every time the evidence is touched: who, when and why. Everything below is that rule applied to a web page.
A chain of custody is a practice, not a statute. It does not make evidence admissible, and it does not decide the weight a court gives it. Its job is narrower: to remove the easy objection that the file could have been swapped or edited on the way.
Why a web page is different
A seized laptop is a physical object with a serial number. A web page is not. The live page keeps changing, and you cannot hand it over. So your custody starts at the moment of capture, and the capture has to describe itself well enough to stand for the page.
That is also why the standards written for devices only partly fit. ISO/IEC 27037, the international guideline on identifying, collecting, acquiring and preserving digital evidence, centres on integrity and on traditional IT systems and media. It is a useful model of the discipline, but it is not a recipe for web pages. In the UK, the ACPO Good Practice Guide for Digital Evidence sets out principles for each stage of the evidence lifecycle (plan, capture, analyse, present), was written for police work, and is still listed as current. Both are guidance, and both point the same way as the steps below.
The links in the chain
1. Before you capture: say why
Write down, before you press anything:
- who is capturing, and on whose instruction
- the matter or reason (a complaint, a contract dispute, a compliance review)
- the exact address you intend to capture
This takes a minute and is the part people skip. Later it separates "captured as part of the dispute" from "found in the archive and relied on afterwards".
2. The capture: let the tool describe itself
At capture, record the address you requested, the address you ended up on if a redirect happened, the start and end time (in UTC, to avoid argument over time zones), the tool and its version, and the machine or service that ran it. If the tool writes these into the file or a manifest, better still: the record travels with the evidence.
Do not tidy the page first. No scrolling, no closing banners by hand, no "save as" from a browser you have been using for other things. Each manual step is something you will have to explain.
3. Fix the file: hash it, then timestamp it
Straight after capture, compute a SHA-256 hash of the file:
sha256sum capture.html
Record the hash in the log. From then on, any copy can be checked against it. If you can, have the hash independently timestamped, so the date does not rest on your word alone. We explain what the hash does and does not prove in what a SHA-256 hash proves about a web capture, and how to check a timestamp in how to verify an RFC 3161 timestamp with OpenSSL.
4. Store the original, and work on copies
Keep one original, read-only, in a place with controlled access. Do every later task (reading, annotating, converting to PDF for an exhibit) on a copy. Opening the original in an editor and saving it, even without changing anything, can alter the bytes and break the hash.
5. Every handover: who, when, why, and a hash check
Each time the file moves to a colleague, an expert or an opposing party, add a row to the log. On receipt, the recipient hashes the file and compares it with the recorded value. A match goes in the log. A mismatch is a finding, not an inconvenience.
6. Production: check before you rely on it
Before the file goes into a bundle or a witness statement, hash it once more and compare. Keep the log with the file, and be ready to explain each entry.
A log you can copy
One row per event is enough:
| When (UTC) | Who | What happened | Why | SHA-256 checked |
|---|---|---|---|---|
| 2026-10-13 09:14 | A. Patel | Captured example.com/terms; tool and version noted |
Dispute with supplier, matter 214 | Recorded: 9f2c… |
| 2026-10-13 09:20 | A. Patel | Original stored read-only; timestamp requested | Preservation | Match |
| 2026-10-14 11:02 | A. Patel to J. Okafor | Copy sent by secure link | Review by solicitor | Match on receipt |
| 2026-10-20 15:30 | J. Okafor | PDF exhibit produced from a copy | Exhibit 3 | Original unchanged: match |
The hash is shortened in the example. In your log, write all 64 characters.
Where chains break
- No record of the first step. The capture exists, but nobody wrote down who made it or why.
- Working on the original. One edit, even an innocent one, and the hash no longer matches.
- Informal copies. A file passed around by messaging app, renamed and re-saved, with no check at either end.
- Shared logins. If three people use one account, the log cannot say which of them did something.
- A gap in time. The capture was made on Monday, hashed on Thursday. For three days the file could have been anything.
How Archivepanel fits
Archivepanel covers the first links, and keeps the rest of the chain visible. A real browser captures a public page and stores it as a self-contained HTML file with scripts stripped. A JSON manifest records the requested and final addresses, the times, the tool versions and a SHA-256 digest for every file. As each capture completes, the digest is sent to DigiCert for an RFC 3161 timestamp. Stored snapshots are never rewritten, and deleting is the only way one leaves the account.
On the paid plan, each team member signs in with their own account, and the activity log names who queued, stopped or deleted a capture. Each record can carry tags and a note for the reason it was made. See capturing a page and trusted timestamps.
Be clear about its limits. The activity log records captures, schedules, team changes and deletions; it is not a record of every download, so log your own handovers as above. It captures public pages only, one page at a time, as a browser sees them from our servers. The DigiCert timestamp is not an eIDAS qualified timestamp.
Sources
- NIST Computer Security Resource Center, Glossary: chain of custody, citing NIST SP 800-72 and SP 800-101 Rev. 1.
- ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence; scope as summarised in ISO27001security (the standard itself is sold by ISO).
- Association of Chief Police Officers, ACPO Good Practice Guide for Digital Evidence, Version 5, National Standards listing, published 1 March 2012.