How do DFIR firms preserve chain of custody?

What a chain of custody records

Audience: a CISO, counsel, incident commander, or engineering leader who needs to know what 'chain of custody' actually is before a DFIR firm starts moving images. The preserve-evidence page on this site is the capture list and the field list this record sits on. The what-is-dfir page on this site is the explainer (identify, preserve, analyze, report; forensic soundness; chain of custody). The never-delete-after-breach page on this site is the isolate-don't-destroy anti-list. The best-digital-forensics-firms page on this site is the criteria checklist (not a ranking). This page is the handling record: what a chain records, how transfers and hashes work, why examiners use a working copy, a fictional custody-log example, and what to demand of a provider. It does not rank DFIR firms, does not name any, and does not ship a downloadable form. The how-to-select-a-dfir-provider page on this site is the selection decision tree. A dedicated information-to-give-a-dfir-firm guide is not on this site yet.

NIST SP 800-86 describes chain of custody as tracking movement of evidence through collection, safeguarding, and analysis by documenting each person who handled it, the date and time of collection or transfer, and the purpose of the transfer. The chain is itself evidence. A Slack 'fyi' is not a chain. Last verified 7 September 2026. Not legal advice.

• At collection: what it is; unique ID; source system / volume / account; UTC date and time; collector name and role; method and tool (name, version, command line); hashes of original and copy; where the original and the working copy now live; why it was taken.
• At every transfer: from whom, to whom, UTC time, why, receiving storage, and a confirmation the hashes still match on receipt.
• In storage: location, access list, write-protect or equivalent, access logs on the evidence store, and any deviation (live capture you could not write-block, a cloud API with no snapshot).
• Limit handlers. Every extra copy is another transfer you must record. NIST SP 800-61r2 wants designated people, not a blast.
• This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.

Four kinds of claim — do not mix them

A matching hash, a filled log, and a court ruling are not the same kind of claim. This page keeps them apart. Last verified 7 September 2026. Not legal advice.

Hashes and the working copy

A hash is a cryptographic digest of the bits. Record it for the original and for the copy at acquisition, and again at every transfer. A match is an integrity check: the bits you have now are the bits you hashed then. A match is not a ruling that a court will admit the copy. NIST SP 800-86 treats hashing as part of preserving integrity during collection — guidance, not a statute. Last verified 7 September 2026. Not legal advice.

• Working copy, not the original. Acquire, hash, and examine a duplicate. NIST SP 800-86: collection should preserve the integrity of the data. RFC 3227: make a bit-level copy and do not analyse the evidence copy.
• Name the algorithm YOUR procedure names (MD5, SHA-1, or SHA-256 are common in notes). Record tool, version, and command line so another examiner can repeat the digest.
• Hash original and copy at acquisition. Confirm the hashes still match on every receipt. A mismatch is the record: stop, write what happened, and do not silently re-hash until it looks right.
• Use write-blocking on media you can write-block. Live memory and some cloud APIs have no write-blocker. Document the gap: how, why, who, when (UTC).
• Personnel should be trained for the method they are using. NIST SP 800-86: untrained collection is how originals get written.

The transfer log

Every time the evidence changes hands or storage, the chain gets a row. From whom, to whom, UTC time, purpose, receiving location, and the hash check on receipt. Wide distribution of the image is how the chain and privilege both fray. Counsel-directed collection is common practice so working papers can sit under attorney-client privilege and work-product; that is practice, not a ruling that privilege will attach. The contact-breach-counsel page on this site is the privilege-and-engagement checklist. Last verified 7 September 2026. Not legal advice.

Worked custody-log example (fictional)

The table below is invented. Cedar & Pine Analytics Ltd, incident INC-FIC-2026-0914, workstation WS-4412, and the people and hashes are fictional. It is a teaching log, not a real case, not YOUR form, and not a downloadable template this product ships. Hashes are labelled fictional. Last verified 7 September 2026. Not legal advice.

What to demand of a DFIR provider — verification checklist

These are handling questions, not a ranking and not a vendor list. Verify against YOUR engagement letter and YOUR procedure. The best-digital-forensics-firms page on this site is the criteria checklist (not a ranking). The how-to-select-a-dfir-provider page on this site is the selection decision tree. A dedicated information-to-give-a-dfir-firm guide is not on this site yet. Last verified 7 September 2026. Not legal advice.

• A written chain of custody for every item: unique ID, UTC times, named handlers, purpose of each transfer, storage location.
• Hashes of original and working copy at acquisition, and a hash check recorded on every receipt. Name the algorithm.
• Examination on a working copy. Original stored write-protected. RFC 3227: do not analyse the evidence copy.
• Tool name, version, and command line in the notes so another examiner can reconstruct the acquisition.
• Documented gaps where write-blocking was impossible (live memory, some cloud APIs).
• Limited handlers. Ask who else will receive a copy and why.
• Counsel-directed engagement is common practice for privilege; it is not a ruling that privilege will attach. The contact-breach-counsel page on this site is that checklist.
• This page does not rank DFIR firms, does not name any, and does not interpret YOUR panel or policy.

What you need to do now

If evidence is already moving, start the log on the next transfer — do not wait for a prettier form. If nothing has been collected yet, the preserve-evidence page on this site is the capture order. Isolate, do not wipe. Last verified 7 September 2026. Not legal advice.

• Open a chain for each item you already have: unique ID, UTC time, who holds it, hashes if they exist, where it lives.
• Stop informal copies. A shared drive dump is a transfer you did not record.
• Work from a working copy. Hash original and copy. Do not analyse the evidence copy.
• Call counsel before you spread the image. The contact-breach-counsel page on this site is the privilege-and-engagement checklist.
• The never-delete-after-breach page on this site is the anti-list that keeps this chain from becoming a story about a wiped host.

Glossary

Terms as this page uses them. Where a source names the idea, the kind of source is in the third column so a guidance document is not mistaken for a statute. Last verified 7 September 2026.

Where this shows up in ShipReady Metrics

This product does not keep a chain of custody. The signed-in app does not image hosts, keep a chain of custody, produce a forensic report, retain a DFIR firm, or file with a regulator. It does not rank forensic vendors and does not ship a downloadable custody form. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a forensic exam, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. Compliance surfaces also hold evidence artifacts (control-mapped collection and review for SOC 2 / ISO 27001-style programs — a timestamped evidence record for controls, not a host image and not a forensic chain of custody). The cyber risk register lives under Security. None of those surfaces preserves volatile memory, images a disk, or substitutes for the commander, counsel, the insurer, or DFIR.

Primary sources (last verified 7 September 2026)

Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.

NIST SP 800-86 (August 2006), Guide to Integrating Forensic Techniques into Incident Response, remains the current final guide this page cites for collection that preserves integrity, working copies, hashes, trained personnel, and chain of custody — documenting each person who handled the evidence, the date and time of collection or transfer, and the purpose of the transfer. Guidance, not a statute, last verified still final on 7 September 2026. ISO/IEC 27037 is a standard of guidelines for identification, collection, acquisition, and preservation of digital evidence; it is not reproduced here, is not a law, and the full text is paywalled. ISO/IEC 27041, 27042, and 27043 are related standards of guidelines (assurance of suitability and adequacy of methods; analysis and interpretation; incident investigation principles); they are named, not reproduced. RFC 3227 (February 2002), Guidelines for Evidence Collection and Archiving, is IETF BCP 55 — a Best Current Practice, not a statute; make a bit-level copy and do not analyse the evidence copy. SWGDE publishes consensus digital-evidence guidelines, not a statute and not a ranking of firms. Federal Rule of Evidence 901 is cited for context as a US federal authentication rule, not as a global statute and not as a determination that YOUR copy is admissible. NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide this cluster cites for designated handlers and for acquire, preserve, secure, and document — guidance, not a statute.

Frequently asked questions