Data integrity means the data is accurate and consistent over its entire lifecycle. It has not been corrupted, altered without authorization, or degraded through processing. Integrity covers the data itself and the relationships between data. A foreign key that points to a nonexistent record breaks integrity. A checksum that no longer matches breaks integrity. A record modified by someone without permission breaks integrity.

Integrity is distinct from security, though the two overlap. Security protects data from unauthorized access. Integrity ensures that authorized changes are correct and complete. A system can be secure and still have integrity problems. A bug in an application can corrupt records without any attacker involvement. A failed disk can silently flip bits. A botched migration can truncate fields. The defenses are checksums, validation rules, referential constraints, audit trails, and backups. Each catches a different failure mode. Checksums detect corruption. Constraints prevent invalid relationships. Audit trails show who changed what and when. Backups provide recovery when prevention fails. Integrity is not a feature you add at the end. It is a property of the whole system, from how data is entered to how it is stored to how it is retrieved. Lose it and the data becomes untrustworthy. Untrustworthy data is worse than no data because it leads to confident wrong decisions.

Integrity protections

• Checksums — detect accidental corruption
• Constraints — enforce valid relationships
• Audit trails — track who changed what
• Access controls — limit who can modify data
• Backups — recover from corruption or loss

Data integrity is trust. Without it, every report, model, and decision built on the data is suspect.