Reference Glossary
File integrity check
A verification process confirming a file's bytes are complete and unaltered from ingest through retrieval, typically by comparing checksums generated at different points in time.
Why it matters in a DAM
Files in a DAM move between storage tiers, get replicated to CDNs, and pass through platform migrations — any of those steps can silently truncate or corrupt data, and without a checksum comparison the damage isn't discovered until someone tries to open the asset, often months later. Regular integrity checks are how a DAM can actually demonstrate to legal, brand, or archival stakeholders that the file delivered today is byte-identical to what was originally ingested, rather than just assuming storage is reliable.
A worked example
Common mistake
Running an integrity check only once, at upload, and never again — corruption introduced during a later storage migration or backup restore then goes undetected until an asset fails to open in production.
A file integrity check compares a file against a known-good reference, usually a checksum (a short digital fingerprint computed from the file’s contents) generated when the file was first ingested. If the file is later recomputed and the checksum doesn’t match, something changed — whether through storage-media failure, an incomplete transfer, or accidental modification — and that mismatch is the signal, not the cause itself.
The value of the check comes from doing it more than once. A checksum captured only at ingest proves the file arrived intact, but says nothing about whether it survived the next storage migration, backup cycle, or platform upgrade unchanged. DAM systems used for compliance-sensitive or archival material typically recompute and compare checksums on a recurring schedule, not just at the moment of upload, so corruption is caught close to when it happens rather than discovered by a confused user much later.
Frequently asked
What is a file integrity check?
A file integrity check compares a file's checksum — a hash value such as MD5 or SHA-256 calculated from its exact bytes — against a reference checksum recorded earlier, typically at ingest. Matching values confirm the file is byte-identical to the original; a mismatch signals corruption or unauthorized alteration occurred somewhere between the two checks, even though the file still opens normally.
When should a DAM run integrity checks beyond upload?
Beyond the initial upload check, a DAM should re-verify checksums after any storage migration or platform move, since files can be corrupted while being copied between systems. Checks are also needed after large network transfers, and on a recurring schedule — for example annually — for archived assets sitting untouched in cold storage, where bit rot can silently degrade files over years without anyone noticing.
What's the mistake of checking integrity only once, at upload?
Checking integrity only at upload assumes a file stays untouched forever, but storage media degrades, transfers fail partway, and migrations between systems can silently corrupt bytes years later. Without follow-up checks, that damage goes completely unnoticed — the corrupted file sits in the DAM looking fine until someone finally opens it for a shoot, print run, or campaign and discovers it's unusable.
What does a checksum mismatch actually indicate?
A checksum mismatch means the file's current bytes no longer match the hash recorded at the last verified checkpoint — the file has been damaged or altered sometime since then, whether by storage media failure, an interrupted transfer, or an unintended edit. The checksum alone can't say which cause is responsible, only that the file is no longer identical to the trusted version and should be restored from backup.
Why do compliance-sensitive DAM deployments rely on integrity checks?
They're how a DAM can demonstrate to legal, brand, or archival stakeholders that the file delivered today is byte-identical to what was originally ingested, rather than just assuming storage is reliable.
What are the typical checkpoints for a file integrity check?
Ingest, where a checksum is computed and stored; storage migration, where it's recomputed and compared; and periodic audit, where it's recomputed and compared on a fixed schedule such as annually.
Sources
- The most common way to confirm file integrity is to generate a checksum or hash for each file, which acts as a unique digital fingerprint that can be recompared later. checked 2026-08-07 — Digital Preservation Coalition Handbook