Deposition-defensible digital evidence guide

Deposition-defensible evidence: making digital evidence survive a challenge

Deposition defensible digital evidence is digital evidence handled so it can survive a challenge in a deposition or court: hashed at collection, preserved unaltered, logged at every step, and packaged so the other side can verify it themselves. Integrity is one part of assessing evidence, alongside its source, collection and meaning. Opposing counsel does not have to disprove your file. They only have to make the room wonder how you handled it. No tool can guarantee admissibility (the court decides that), but you can take the easy reasons off the table.

What opposing counsel asks, and how a checkable package answers it:

The short answer

Defensible means you can answer each question about a piece of evidence calmly, with proof: where it came from, who handled it, what was done to it, and how you know it is the same file today as the day you collected it.

The data has not changed, and you can show it. The custody record was written as things happened, not pieced together after. The next reviewer can repeat the check against a trusted baseline. That answers an integrity question, not every question about the evidence.

The questions you will be asked

Depositions hunt for the weakest link. When was this collected, and by whom? Where has it lived, and who had access? Could anyone have changed it? How do you know this is identical to the original?

The trap is almost never one bad answer. It is the pile-up of “I don't recall,” “I'd have to check,” and “I believe so.” Each soft answer widens the gap. The fix is records written at the time: a hash captured at intake, an audit log, an export the other side can check. A retained intake hash gives a reproducible answer to whether checked file contents match that baseline. Other questions still require records and testimony.

Hashing replaces “trust me”

A hash like SHA-256 reduces any file to a fixed 64-character fingerprint. Change one bit, embedded metadata, a line ending, a single pixel, and the fingerprint changes completely. Record it when you collect the file, recompute it later, and a match means unchanged. Mismatch means something happened, and you want to know before opposing counsel does.

Two things make it hold up. Hash early, before anyone opens the file, so the value reflects the original. And use a standard algorithm the other side can run themselves. A hash only helps if they can reproduce it. SHA-256 is everywhere because anyone can check it.

Audit log and preserved originals

A hash proves the file did not change. It does not tell you who handled it. That is the audit log’s job: each material event timestamped and attributed, append-only. Audit and custody entries cannot be updated after insert. Authorized case purge has its own audit record. Retention, backups, administrator access and restoration remain part of protecting that history. A log you can edit is just a document, and opposing counsel will treat it as one. A log that only grows is evidence about your evidence.

Preserve the originals at intake under their recorded fingerprint, log the custody and export events, and you can show that interference would leave a trace. That is tamper-evident, not tamper-proof. No real system is tamper-proof. Claiming otherwise in a deposition is itself a weakness.

An export the other side can check

The strongest moment in a custody fight is when you hand the other side something they verify themselves and watch it pass. Enable the export manifest to include file checksums; and the recipient recomputes the hashes; if one byte changed, it shows.

That independence is the whole point. If verification only works inside your app, the obvious objection is “of course it passes in your own tool.” Independent checking lets a recipient compare bytes with the supplied hashes. The baseline must still be trusted, and collection and custody still need supporting records.

How does chain of custody really break?

Chains rarely snap. They erode, and usually nobody meant any harm.

The gap: a stretch where nobody can say where the file was, because it sat in a shared folder or an email thread. The silent edit: a file opened “just to look” re-saves and quietly changes the hash. The orphan copy: the version produced in discovery can't be tied back to the original by any recorded fingerprint. The editable log: a custody record kept in a document that could have been changed after the fact.

None of these require bad faith. That is why process beats intent. “I would never alter evidence” is not an answer. The question is whether you could prove it. An early hash, preserved originals, an append-only log, and a checkable export go a long way toward answering it for you.

What to ask any vendor

Most vendors will claim all of this. The gap is in the details, so pin them down before you commit:

• Can I verify an export without your software installed, on a machine you've never touched?
• What exactly does the audit log record, and can anyone, including an admin, edit or delete an entry?
• When is the hash computed, and what algorithm? (If it isn't SHA-256 at intake, ask why.)
• Will you put your NIST and FIPS claims in writing? “Aligned” and “certified” are not the same word.

A straight answer to these tells you more than any feature list.

Where EMP Intake fits

EMP is the intake and integrity layer, the step between acquisition and review where you build a record you can defend. It does not replace Cellebrite, EnCase, or Axiom, and it is not a review platform. It sits between them. On import (files and CSV), it hashes each file at intake with SHA-256, preserves the originals, and writes intake, custody, edit and export events to an append-only log. Enable Manifest for file checksums and recipient verification. Use the package verifier for supported package checks or the SHA-256 tool to calculate a file hash. Standard and Professional add Chain of Custody and Audit Timeline.

EMP Intake WS runs on a Windows workstation and keeps evidence on your machine; Teams is the shared-case build, with a pilot planned for 2027. Neither uploads evidence to a cloud. The integrity model is NIST SP 800-86 / 800-101 aligned as a design target, not certified, and not FIPS-validated. SP 800-101 references concern handling and exporting mobile-device evidence acquired elsewhere, not extraction from a device. It is tamper-evident, not tamper-proof.

The purpose is to retain originals, record handling and make file-integrity checks reproducible.