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 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.
When should a DAM run integrity checks beyond upload?
After storage migrations and on a recurring periodic audit schedule, not just once at ingest, since corruption can be introduced later in the asset's lifecycle.
What's the mistake of checking integrity only once, at upload?
Corruption introduced during a later storage migration or backup restore goes undetected until an asset fails to open in production.
What does a checksum mismatch actually indicate?
That something changed since the reference checksum was recorded, whether through storage-media failure, an incomplete transfer, or accidental modification; the mismatch is the signal, not the cause.
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