Integrity in information security means that data is accurate, complete and unmodified except through authorized processes. It's the property you're protecting when you hash a file, digitally sign a document, or require two-person approval for production changes.
Integrity failures are particularly dangerous because they often go undetected. A confidentiality breach surfaces when data shows up where it shouldn't. An availability failure is obvious, where the system is down. Integrity compromise can persist quietly: records altered, logs truncated, configurations changed without authorization, firmware replaced with a backdoored version. The organization continues operating against corrupted ground truth.
The attack surface for integrity is wide. SQL injection modifies database records without authorization. A privileged insider adjusts financial records or audit logs. A man-in-the-middle attack intercepts and alters a transaction in transit. Ransomware operators sometimes corrupt backup data rather than just encrypting primary data, specifically to undermine recovery. Without integrity, you can't trust that what you're seeing reflects reality.
Technical controls for integrity operate at multiple layers. Cryptographic hashing (SHA-256, SHA-3) lets you verify that a file matches its original state (e.g., any modification produces a different hash). Digital signatures bind a hash to an identity, providing non-repudiation: proof that a specific party produced this artifact and it hasn't changed since. Version control systems maintain cryptographically verifiable change histories. Write-once log storage prevents after-the-fact modification of audit trails. File integrity monitoring tools (Tripwire, AIDE, auditd) alert on unauthorized changes to critical system files.
Non-repudiation deserves specific attention in compliance contexts. When a user acknowledges a policy, approves a change, or signs off on a transaction, integrity controls ensure that action can't be disavowed later. This is why audit log protection and access controls around log modification are treated as critical controls in NIST 800-53 (AU control family) and NIST 800-171 (3.3.x). Assessors will look for both the existence of audit logs and evidence that those logs can't be altered by the subjects whose actions they record.
