What it means
Integrity is about information and systems remaining correct for their intended purpose, with changes made through authorized processes. An unauthorized alteration, an accidental truncation, or a faulty calculation can each undermine integrity. Security teams therefore examine both malicious manipulation and ordinary processing failures.
A useful design identifies who may change information, how changes are validated, and how the organization can detect and recover from an incorrect result. Hashes can help identify changed bytes when compared with a trusted reference, but they do not prove that the original information was true. Business checks and trusted change records remain important.
The idea at a glance / Foundations
A legitimate change can preserve integrity.
Two inventory copies both change. Only one matches the approved, completed shipment.
Controlled example: the starting quantity of 100 is correct, S17 is the only transaction, and its approval and completion records are trusted and protected from the inventory editor.
READ THE PICTURE
Check the authorized result
Shipping one unit through approved transaction S17 leaves 99. Both copies have changed from 100, but the hidden edit to zero has no authorized transaction to explain it. Integrity concerns the legitimate, correct result.
Keep in mindMatching 99 is only a consistency check in this example. Integrity also depends on valid authorization, accurate inputs, and a correct process. A difference alone does not identify its cause.
Read the complete example
- Check the authorized result. Shipping one unit through approved transaction S17 leaves 99. Both copies have changed from 100, but the hidden edit to zero has no authorized transaction to explain it. Integrity concerns the legitimate, correct result. The controlled inventory starts at 100 units. Trusted transaction S17 records approval to ship one unit and confirms the shipment completed. No other transaction occurred, so the expected inventory is 100 minus 1, or 99. The approved update stores 99 through the authorized process and agrees with that evidence. In the second copy, an unapproved direct edit stores zero and contradicts the same trusted evidence. Both copies differ from the original bytes. A hash of the original would flag both changes, so byte comparison alone would not distinguish this legitimate update from the hidden edit. The expected quantity and transaction evidence must be protected and correct; merely obtaining 99 does not prove that an editor was authorized. In a real investigation, an unexplained value could also come from a processing error, omitted transaction, or incorrect baseline; compare evidence before assigning cause.
Matching 99 is only a consistency check in this example. Integrity also depends on valid authorization, accurate inputs, and a correct process. A difference alone does not identify its cause.
Diagram references: NIST SP 800-12 Rev. 1 - Data Integrity and Integrity Verification
AN ILLUSTRATIVE SCENARIO
A food manufacturer recipe file
A food manufacturer uses a controlled recipe file to set production quantities. An operator notices that one ingredient value differs from the approved version. The team stops the affected change process, compares the file with a trusted approved copy, and reviews the change record. It investigates whether the difference came from an authorized revision, an import mistake, or unauthorized editing. The file being readable and available does not establish that its values are suitable for production.
Put it to work
- Identify important records, calculations, and configurations, along with the approved process and people or systems allowed to change them.
- Use appropriate validation, access restrictions, versioning, and change records; protect reference copies and integrity-check values from the same unauthorized edits.
- Exercise a safe incorrect-change scenario with synthetic data and verify detection, investigation, and restoration to an approved state.
How to check your work
Trace a sample change from approval through implementation and verification. Confirm that the final value matches the authorized intent, that an unauthorized test change is caught, and that a trustworthy recovery copy is available.
Connect the ideas
- CIA triad
A shorthand for naming whether a loss is disclosure, unauthorized change, or downtime.
- Hashing
A one-way fingerprint of data used to detect change or store verifiers, not a reversible way to hide records you must later read.
- Audit trail
An append-oriented history of security-relevant actions that can be shown to a later reviewer.
- Backup
A copy of data kept so integrity and availability can be restored after loss, preferably beyond the production identity’s reach.