6 Digital evidence chain of custody is the documented record showing that a file presented in court is exactly the file that was collected, and that every person and system that touched it is accounted for. With physical evidence, chain of custody means sealed bags, signatures and a property room log. With digital evidence, the same principles apply, but the bag is a storage system and the signatures are hashes and audit records. When the chain breaks, defense counsel can challenge authenticity and a judge may exclude the evidence or a jury may discount it. Most of the controls that keep the chain intact live in the evidence management application, but the storage layer underneath either supports them or undermines them. This article explains how. What digital evidence chain of custody has to show A defensible chain answers four questions: Who collected, accessed, copied or exported the file? When did each action happen? What was done (viewed, copied, redacted, shared, deleted)? Was the file altered? Can the agency prove the bits are identical to what was collected? The first three come from audit logs, kept by both the evidence application and the storage platform. The fourth comes from cryptographic hashing and storage that prevents silent change. Hashing: the digital seal A cryptographic hash function produces a fixed-length fingerprint of a file. Change one bit and the fingerprint changes completely. Evidence systems typically compute a hash at the moment of ingest (SHA-256 is widely used today) and store it with the file’s metadata. Any later copy can be hashed again and compared. A match shows the copy is identical to the original. Hashing also has legal weight. Federal Rule of Evidence 902(14), effective December 1, 2017, allows data copied from an electronic device, storage medium or file to be self-authenticated when a qualified person certifies that it was identified by a process of digital identification, such as matching hash values. Many states have similar rules or practices. That makes consistent hashing at collection, at transfer and at export a core part of digital evidence chain of custody. Immutability: making alteration impossible, not just detectable Hashes prove whether a file has changed. Immutability prevents change in the first place. Write-once, read-many (WORM) controls, such as object lock in compliance mode, block anyone from overwriting or deleting a file until its retention period ends, including administrators with full privileges. That matters for chain of custody because it removes a whole class of challenge. If the storage system cannot modify the file, an argument that it might have been altered at rest is much weaker. It also protects against ransomware encrypting evidence and against accidental deletion. Versioning complements immutability. When a redacted copy is created, it should be a new object with its own hash and lineage, not a modification of the original. Audit logs at every layer The evidence application records user actions: who searched, viewed, downloaded or shared a file. The storage layer should keep its own logs of API calls, administrative actions, policy changes and access by service accounts. Two independent logs make tampering harder to hide and give auditors a way to cross-check. Good storage audit logs are: Complete, covering reads, writes, deletes and configuration changes. Time-synchronized, so events line up across systems. Protected from modification, ideally written to immutable storage themselves. Retained at least as long as the evidence they describe; some statutes require deletion logs to be kept permanently. The principles are covered in storage audit trail. Integrity checks over time Evidence kept for years faces a quieter risk: bit rot and media failure. Storage platforms that store checksums for every object and periodically verify them can detect and repair corruption before anyone notices. This background verification, combined with erasure coding or replication, means the file retrieved years later still matches its original hash. The mechanics are described in object storage integrity verification and data durability in high-density storage systems. Access control and separation of duties Chain of custody is also about limiting who can touch evidence at all: Role-based access so patrol officers, detectives, prosecutors and records staff see only what they need. Multi-factor authentication, which the CJIS Security Policy requires for access to criminal justice information. Separation between storage administrators and evidence custodians, so no single person can both change retention policy and access evidence. Encryption at rest and in transit with managed keys. The CJIS Security Policy 6.1, released in June 2026, raised minimum encryption strength for key controls to 256-bit. Separation of duties deserves particular attention in smaller agencies, where one IT administrator may manage everything. Even there, retention policy changes can require a second approver, and storage-level actions can be logged to a location the administrator cannot modify. Those two controls alone close many of the questions defense counsel tends to raise. Chain of custody across copies and transfers Evidence moves: from camera to dock, from dock to repository, from repository to prosecutor, from prosecutor to defense. Each hop is a point where the chain can break. Good practice includes hashing before and after every transfer, using secure transfer methods, logging every export with recipient details and producing exports with a manifest of hashes. When evidence is replicated to a second site or migrated to new storage, the same verification should be run and recorded. Common ways the chain breaks Most chain of custody problems are not dramatic tampering. They are gaps that make it hard to prove nothing happened: Evidence copied to USB drives or shared folders outside the evidence system, with no hash recorded and no log of who handled it. Shared administrator accounts, so logs show that “admin” did something but not which person. Clock drift between camera docks, servers and storage, making the sequence of events hard to reconstruct. Log retention shorter than evidence retention, so access records are gone by the time an appeal arrives years later. Unverified migrations, where evidence was moved to new hardware or a new vendor without hashing before and after. Redactions saved over originals, leaving no unaltered copy. Each of these is preventable with policy plus storage that enforces it. What prosecutors and defense counsel ask for When evidence is challenged, the questions are predictable. Prosecutors want to show a complete history: original hash, every access and export, and confirmation that the version produced matches the original. Defense counsel may ask who had administrative rights to the storage, whether deletions were possible, whether any files from the same incident are missing and how the agency knows the timestamps are accurate. An agency that can answer those questions from records, rather than from memory, is in a far stronger position. Building the storage and logging design around those questions from the start is cheaper than reconstructing answers later. Checklist: storage features that support digital evidence chain of custody Hash computed at ingest and stored with metadata. Re-verification on every copy, export and migration. Write-once retention locks that administrators cannot override. Versioning so redactions and edits never overwrite originals. Independent, immutable storage-level audit logs. Background integrity verification with automatic repair. MFA, role-based access and separation of duties. Encryption at rest and in transit meeting current CJIS guidance. Export manifests that include hashes and chain records. Putting it together Digital evidence chain of custody is built from hashing, immutability, logging, integrity checks and tight access control. The evidence application orchestrates it, but the storage layer decides whether those controls hold up for the decade or more that some evidence must survive. Agencies evaluating storage should ask not only how much it holds, but how it proves that what it holds has never changed. For the wider set of requirements, see our hub on digital evidence storage. Frequently asked questions What hash algorithm should be used for digital evidence? SHA-256 is widely used today. Older algorithms such as MD5 and SHA-1 are still seen in legacy tools but are considered weaker, so many agencies record SHA-256 alongside or instead of them. Does immutable storage replace hashing? No. Immutability prevents change; hashing proves no change occurred. Courts and auditors expect both. Who should be able to delete digital evidence? Only authorized custodians following an approved retention schedule, with no active legal hold, and every deletion should be logged permanently. What happens to chain of custody during a storage migration? Every object should be hashed before and after the move and the results recorded. Platforms that refresh hardware in place without a bulk migration reduce this risk. Are storage logs admissible in court? Logs can support authentication when they are complete, protected from tampering and explained by a qualified witness. Admissibility rules vary by jurisdiction. Further reading Digital evidence storage Digital evidence retention Body-worn camera storage Cloud DEMS vs on-prem evidence storage Storage audit trail
