Isn't storing the file's hash enough?

No. The hash proves two copies are identical, but it says nothing about who produced the file or when, and on its own it doesn't stop someone from replacing both the file and its hash. It proves integrity, not origin or date.

What's the difference between integrity, authenticity and timestamping?

Integrity = the content didn't change (hash). Authenticity = this person or system produced it (a key signature). Timestamping = it existed on a given date (a third party that can't backdate it). They are three separate proofs, and solid evidence needs all three.

What must the system record to sustain the chain?

A tamper-evident, append-only event log: who collected, received, moved, stored and accessed each item of evidence, with the date. If that log can be edited without a trace, the chain breaks exactly where nobody is looking.

What digital chain of custody really is (and what your software must do)

When digital evidence has to hold up before a third party —an audit, a legal process, a forensic review— the question isn't «does the hash match?». It's broader: «how do I know this file is the same one that was collected, that it was produced by who it claims, and that it existed when it claims?». That is digital chain of custody: not a value, but a continuous proof that travels with the file from its origin.

It rests on four guarantees, and they are distinct from one another:

1. Integrity — the content didn't change

This is what the hash gives you: a cryptographic fingerprint (SHA-256, say) that changes completely if a single bit changes. You recompute the hash and compare; if they match, the two copies are identical.

But integrity alone is fragile as proof: if someone can replace the file, they can also recompute and replace the hash. The hash proves two copies are equal; it doesn't prove nobody changed both of them.

2. Authenticity — who produced it

This is where the digital signature comes in: the producer signs the hash with their private key, and anyone verifies with the public one. Now the file isn't just intact, it's attributable. Replacing file and hash is no longer enough: you'd need the signer's private key.

The signature adds a third layer almost nobody looks at: trust that the public key really belongs to who it claims. Cryptography alone doesn't settle that —a PKI, a certificate or a registry does— and it's where most integrity reports fall apart.

3. Verifiable date — when it existed

A hash and a signature are a point with no date. They prove the file is this one and that this person signed it, but not that it existed on Tuesday and not Thursday. For that you need a timestamp: a third party that attests to the date and cannot backdate it. Without one, anyone can sign a document today and present it as a year old.

4. Traceability — who touched it afterwards

The first three describe the file. The fourth describes its journey: a tamper-evident, append-only event log of who collected, received, moved, stored and accessed it, with the date. If that log can be edited without a trace, the chain breaks exactly where nobody looks. A log you can rewrite isn't custody, it's decoration.

What this means for your software

A system that «stores the hash» covers one of the four. One that genuinely sustains chain of custody:

computes and stores each item's hash (integrity),
signs it with a key whose ownership can be verified (authenticity),
stamps it with a time from a trusted third party (date),
and writes every access to an append-only log that can't be edited (traceability).

None of the four is optional if the goal is for the evidence to survive a challenge. And the one most often forgotten is the last, because it's the only one you can't see in the file.