Chain of custody is the documented chronological history of digital evidence from the moment it is identified through its presentation in court. It records every person who touched the evidence, every action performed on it, every location where it was stored and every transfer between custodians. In digital forensics, chain of custody extends beyond physical handling to include cryptographic verification that the data itself was not altered at any stage.
Physical evidence has a natural chain of custody. A weapon is bagged, tagged, logged into an evidence room and signed out by each person who handles it. Digital evidence is different. A file can be copied, modified, deleted or corrupted without leaving visible traces. The chain of custody for digital evidence must therefore include mathematical proof of integrity at every stage. That proof comes from cryptographic hash functions.
A SHA-256 hash is a 256-bit value computed from the contents of a file. Any change to the file, even the modification of a single byte, produces a completely different hash value. By computing the SHA-256 hash at collection, before analysis, during analysis, after analysis and at every transfer point, examiners create a verifiable chain of mathematical proof that the evidence remained unaltered throughout the investigation.
Chain of custody documentation in digital forensics must answer five questions for every piece of evidence: Who collected it? When was it collected? How was it collected? Who has handled it since collection? Has it been modified at any point? If any of these questions cannot be answered with documented proof, the chain is broken.
Why Chain of Custody Matters for Court Admissibility
Digital evidence without proper chain of custody is vulnerable to exclusion. Opposing counsel will argue that the evidence may have been altered, planted or contaminated. Without documentation proving otherwise, the court has no basis to trust the evidence.
The legal frameworks governing digital evidence admissibility are explicit about chain of custody requirements. In the United States, the Federal Rules of Evidence Rule 901(b)(9) requires authentication of evidence produced by a system or process. The proponent must demonstrate that the system produces accurate results. For digital forensics, this means proving that the tools used to collect and analyze evidence did not modify it. SHA-256 hashing before and after analysis satisfies this requirement.
The Federal Rules of Civil Procedure Rule 37(e) addresses spoliation of electronically stored information. If a party fails to take reasonable steps to preserve ESI and it is lost or altered, the court may impose sanctions ranging from adverse inference instructions to case-dispositive sanctions. Proper chain of custody documentation demonstrates that reasonable preservation steps were taken.
In Canada, Section 31.2 of the Canada Evidence Act governs the authentication of electronic documents. The Sedona Canada Principles Addressing Electronic Discovery provide further guidance on proportional preservation and production. Canadian courts have excluded digital evidence where the examiner could not demonstrate that proper handling procedures were followed.
A 2024 BC Supreme Court ruling excluded email evidence because the examiner opened PST files in a read-write viewer. Opposing counsel's expert identified timestamp modifications consistent with write access. The emails were excluded under the best evidence rule. Proper chain of custody with read-only access and hash verification would have prevented this outcome entirely.
How Sherlock Tools Maintain Chain of Custody
Every Sherlock forensic tool is designed with chain of custody as a core requirement rather than an afterthought. The following mechanisms operate automatically during every examination session.
Per-Artifact SHA-256 Hashing
Sherlock tools compute a SHA-256 hash for every individual artifact during analysis. In PST Viewer, this means a unique hash for every email message. In Android Acquirer, this means a unique hash for every extracted file. Per-artifact hashing goes beyond whole-file hashing. A PST file may contain 50,000 emails. Whole-file hashing proves the container was not modified. Per-artifact hashing proves each individual item within the container was not modified. Courts expect this granular verification from qualified examiners.
Timestamped Manifests
Every export operation generates a timestamped manifest listing each artifact, its SHA-256 hash, the source file it was extracted from and the exact time of extraction. This manifest serves as a verifiable index of produced evidence. Any qualified examiner can independently verify every hash value in the manifest against the original source evidence.
Read-Only Acquisition Mode
Sherlock PST Viewer opens email archives in strict read-only mode. The tool never writes to the source file. No timestamps are modified. No metadata is altered. The original file remains byte-for-byte identical before and after analysis. This is verifiable by comparing SHA-256 hashes pre- and post-examination. Sherlock Android Acquirer performs logical acquisition via ADB without modifying device storage. The helper APK runs with standard permissions and does not root or alter the device.
Session IDs and Examiner Tracking
Every examination session receives a unique session identifier. The session ID links all actions, exports and hash computations to a specific examiner at a specific time on a specific machine. If multiple examiners work on the same evidence at different times, their sessions are tracked independently. This granular tracking eliminates ambiguity about who did what and when.
Automated Audit Logging
Sherlock tools log every examiner action automatically. Every search query executed, every filter applied, every message viewed, every artifact exported. The audit log is generated from the tool's internal event system with no manual note-taking required. This eliminates the documentation gaps that occur when examiners rely on handwritten notes or memory.
Chain of Custody Documentation Checklist
The following checklist represents the minimum documentation requirements for maintaining defensible chain of custody in a digital forensics engagement. Sherlock tools automate items marked with an asterisk.
| Item | Description | When |
|---|---|---|
| Custodian identification | Name, role and contact information for the evidence custodian | Collection |
| Device documentation | Serial number, make, model, storage media type and capacity | Collection |
| Collection method | Tool used, write-blocking method, imaging parameters | Collection |
| Source hash * | SHA-256 hash of original evidence before any processing | Collection |
| Forensic copy hash * | SHA-256 hash of working copy verified against source hash | Pre-analysis |
| Tool identification * | Name, version and license of forensic tools used | Analysis |
| Session ID * | Unique identifier linking all actions to a specific examination session | Analysis |
| Examiner identification * | Name, credentials and role of the examiner performing analysis | Analysis |
| Action log * | Timestamped record of every search, filter and export action | Analysis |
| Per-artifact hashes * | SHA-256 hash for every individual artifact examined or exported | Analysis / Export |
| Export manifest * | List of all exported artifacts with hashes, source references and timestamps | Export |
| Post-analysis hash * | SHA-256 hash of original evidence after analysis, verified against source hash | Post-analysis |
| Transfer log | Record of every custody transfer including recipient, date and purpose | Ongoing |
| Storage documentation | Secure storage location, access controls and environmental conditions | Ongoing |
How PST Viewer Generates Chain of Custody Logs
Sherlock PST Viewer Forensic Edition generates chain of custody documentation automatically during every examination session. When the examiner opens a PST or OST file, the tool records the source file path, the source file SHA-256 hash, the examiner name from the license, the tool version number and a unique session ID with timestamp.
During analysis, the tool logs every search query with the exact search terms and timestamp. Every filter applied is documented including date ranges, sender/recipient filters and keyword filters. When the examiner marks emails for inclusion in a forensic report, those selections are logged with timestamps. Marks are stored separately from the evidence file so the source PST is never modified.
When the examiner generates a PDF report, the report itself contains the chain of custody metadata. The title page documents the tool version, license holder, session ID, generation timestamp and source file SHA-256 hash. Each evidence card includes the per-message SHA-256 hash computed at the time of report generation. The examiner can re-open the same PST file at any later date and verify that all hash values match, proving no modification occurred between sessions.
After examination, the tool provides a verification function that re-computes the SHA-256 hash of the source file and compares it to the hash recorded at session start. A match confirms the evidence was not modified during analysis. This verification result is included in the chain of custody log.
How Android Acquirer Generates Chain of Custody Logs
Sherlock Android Acquirer Forensic Edition generates chain of custody documentation for mobile device acquisitions. When the tool connects to an Android device, it records the device serial number, manufacturer, model name, Android version, build number and bootloader lock status. This device identification data is included in the forensic report and cannot be fabricated after the fact because it is read directly from the device hardware.
During acquisition, the tool logs which data categories were selected for extraction (SMS, contacts, call logs, media, apps, Wi-Fi networks, browser history, calendar, accounts). Each extracted file receives an individual SHA-256 hash computed at the moment of extraction. The extraction output folder contains both the raw data and a hash manifest listing every file with its corresponding SHA-256 value.
The forensic PDF report generated by Android Acquirer documents the complete acquisition chain: device identification, examiner details, acquisition timestamp, selected data categories, bootloader status, helper APK deployment status and SHA-256 hashes for all extracted artifacts. This report serves as the formal chain of custody document for the mobile device evidence.
Common Chain of Custody Failures
Understanding how chain of custody fails is as important as understanding how to maintain it. The following failures are documented from published court rulings and forensic community literature.
- Opening evidence in read-write mode
- Consumer-grade file viewers open files in read-write mode by default. This modifies last-accessed timestamps at minimum and may alter file metadata. When opposing counsel's expert identifies these modifications, the chain of custody is broken. Sherlock tools prevent this by enforcing strict read-only access.
- Failure to hash before analysis
- If the examiner does not compute a hash of the original evidence before beginning analysis, there is no baseline to compare against. The examiner cannot prove the evidence was not modified because there is no mathematical reference point. This failure is irreversible. Sherlock tools compute the source hash automatically at session start.
- Manual documentation gaps
- Examiners who rely on handwritten notes or manual logging inevitably leave gaps. A search query goes unrecorded. A filter is applied but not documented. These gaps create opportunities for opposing counsel to question the completeness of the examination record. Sherlock tools log every action automatically with no manual input required.
- Untracked custody transfers
- When evidence changes hands between examiners, attorneys or storage facilities without documentation, the chain is broken. Every transfer must be logged with the names of both parties, the date, the purpose and a hash verification confirming the evidence was not altered during transfer.
- Working on original evidence
- Analyzing original evidence instead of a forensic copy creates a single point of failure. If the original is accidentally modified, the evidence may be permanently compromised. Always create a forensic copy and verify the copy hash matches the original before beginning analysis.
Legal Standards for Digital Chain of Custody
The following legal frameworks define chain of custody requirements for digital evidence in Canadian and US jurisdictions.
- Federal Rules of Evidence (US) - Rule 901(b)(9)
- Requires authentication of evidence produced by a process or system. SHA-256 hashing and chain of custody documentation satisfy this requirement by demonstrating the integrity of the analytical process.
- Federal Rules of Civil Procedure (US) - Rule 37(e)
- Addresses spoliation of electronically stored information. Read-only access and pre/post analysis hash verification demonstrate that no spoliation occurred during examination.
- Canada Evidence Act - Section 31.2
- Addresses authentication of electronic documents. Chain of custody reports generated by Sherlock tools provide the documentation needed to satisfy authentication requirements under Canadian law.
- NIST SP 800-86
- The NIST Guide to Integrating Forensic Techniques into Incident Response provides technical guidance on evidence collection, examination, analysis and reporting. Chain of custody documentation is a core requirement throughout the process.
External Resources
For additional guidance on chain of custody in digital forensics: