Producing a file verification report
For audits, handovers and chain of custody — what actually needs to be in it.
A hash on its own proves very little. "This file's SHA-256 is 3a7b…" raises the obvious questions: which file, computed when, by whom, and with what? A verification report is simply the hash plus the context that makes it meaningful later, when the person reading it is not you and the file is months old.
What the report must contain
| Field | Why it matters |
|---|---|
| File name and size | Identifies which artefact; size catches obvious substitutions early |
| Digest | The evidence itself |
| Algorithm | A digest is meaningless without it; also shows whether it is still trusted |
| Timestamp with time zone | Places the check on the timeline of events |
| Operator | Who performed it, so it can be attested to |
| Purpose | Why the check happened, which is what an auditor actually asks |
| Report ID | Lets the document be referenced from a ticket, case file or control |
Use SHA-256, and say so
For anything that may be questioned, use SHA-256. MD5 and SHA-1 are both vulnerable to deliberate collisions, which means a report built on them cannot distinguish "this file is unchanged" from "someone produced a different file with a matching digest". For an integrity record, that is the entire point.
If you are re-verifying against a legacy MD5 published years ago, record both: the original MD5 for continuity with the old record, and a fresh SHA-256 going forward. The difference is explained here.
A workable procedure
- Hash the files before they move or change hands, not after.
- Hash every file in the set in one run, so a single timestamp covers the whole batch.
- Record the purpose and operator while you still remember them.
- Export the report and store it somewhere the files themselves are not.
- On receipt at the other end, recalculate and compare against the report.
- Keep both reports. The pair is the actual evidence, not either one alone.
The report generator covers steps 2 to 4 in one pass and exports to PDF, CSV, JSON, HTML or TXT.
What undermines a report
- ×Storing the report beside the files. If an attacker can alter the files they can alter the report. Keep it elsewhere, ideally somewhere append-only.
- ×Omitting the algorithm. A bare 64-character string is not self-describing enough to re-verify with confidence.
- ×Hashing after the fact. A digest taken once a file has already been through three systems documents its current state, not its original one.
- ×Recording a partial run. If some files failed, the report must show it. A report that silently covers 9 of 10 files is worse than none.
- ×Treating it as proof of origin. A hash proves a file has not changed since it was hashed. It says nothing about where the file came from or whether it was legitimate to begin with.
What this is not
A self-generated verification report is a record you made; it is not notarised, not independently witnessed and not timestamped by a trusted third party. For most audit, handover and internal compliance purposes that is exactly what is expected. If you need something stronger — a cryptographic timestamp from a trusted authority, or a signed attestation — a hash report is the input to that process rather than a substitute for it. Where the evidentiary bar matters, confirm the requirements with whoever owns the process before relying on this.