Data integrity refers to the completeness, integrity and accuracy of data throughout its entire lifecycle: data must not be altered, deleted or supplemented without detection — whether through technical errors or unauthorised interference. Alongside confidentiality and availability, data integrity is one of the three core values of information security and is enshrined in law under Article 5(1)(f) and Article 32 of the GDPR.
What is data integrity?
Data integrity is the property of data that ensures it has remained unchanged and complete since its creation or last authorised modification. ISO/IEC 27000 defines integrity concisely as the property of accuracy and completeness; the BSI additionally encompasses the correct functioning of the systems that process that data. The concept therefore covers not only stored content, but the entire chain from capture through transmission and storage to archiving or deletion.
One point is frequently misunderstood: most data integrity procedures do not prevent changes — they make changes detectable. A hash value does not stop anyone from modifying a file; it ensures that the modification becomes apparent. This distinction between tamper protection and tamper detection determines which measures an organisation actually needs. Where changes are to be technically ruled out, immutable storage methods are required; where demonstrability is sufficient, cryptographic checksums and separately secured logging are enough.
Equally important is the distinction from factual accuracy. Data integrity confirms that a value has not been altered without authorisation — not that it is factually correct. An incorrectly recorded telephone number remains incorrect even when stored with integrity protection. The GDPR draws a clear distinction between the two requirements: Article 5(1)(d) requires the accuracy of personal data, while Article 5(1)(f) requires its integrity and confidentiality. Conflating the two principles regularly leads to planning that fails to meet one or both requirements.
Why is data integrity important?
Data integrity matters because virtually every decision within an organisation is based on data whose accuracy is tacitly assumed. If availability fails, the organisation notices immediately. If confidentiality is breached, it becomes visible sooner or later. A breach of data integrity, by contrast, can go undetected for months — and continues to have an effect throughout that time: in analyses, financial settlements, operational data, medical findings or situational reports.
Attackers have long factored in this dynamic. Alongside encrypting data through ransomware, targeted manipulation is part of the standard toolkit: altered payment details in invoices, manipulated master data, forged instructions in communication channels, modified log files to conceal an intrusion. Such attacks are harder for those affected to detect than a complete system failure — and the damage they cause stems not from the incident itself, but from every subsequent decision made on the basis of the manipulated data.
There is also an evidential dimension to consider. Following a security incident, an organisation must be able to demonstrate which data was affected and which was not. Without integrity evidence, the only option is to assume that all data holdings may have been compromised — with corresponding consequences for recovery, reporting obligations and liability. Furthermore, an unauthorised alteration of personal data constitutes a personal data breach under Article 4(12) GDPR and may trigger the 72-hour reporting obligation under Article 33 GDPR.
How does data integrity differ from data quality, data consistency and data security?
Data integrity, data quality, data consistency and data security describe different properties that are frequently used interchangeably in practice. The distinction is not mere pedantry: it determines which teams are responsible and what measures are needed to address a deficiency. A data quality project does not improve integrity, and an encryption project does not improve data quality.
| Term | Core question | Relationship to data integrity |
|---|---|---|
| Data integrity | Is the data unchanged and complete? | The reference point; a core objective of information security |
| Data quality | Is the data factually correct, current and fit for purpose? | Presupposes data integrity, but goes further in terms of content |
| Data consistency | Is the data free of contradictions across systems and relationships? | A sub-aspect of logical data integrity |
| Data security | Is the data protected from loss and unauthorised access? | An overarching term encompassing integrity, confidentiality and availability |
| Data protection | Is the processing of personal data lawful? | The legal framework, which includes data integrity as a requirement |
| Authenticity | Is the data demonstrably from the stated source? | A complementary security objective; unreliable without integrity |
Data integrity and authenticity are particularly closely intertwined. A message whose sender is established but whose content can be altered in transit is worthless — and vice versa. Cryptographic methods therefore typically address both objectives together.
What types of data integrity are there?
Data integrity is conventionally divided into physical and logical integrity. Physical data integrity concerns the error-free storage and transmission of data at the hardware level: it is threatened by storage media defects, memory bit errors, transmission errors, power failures during write operations and gradual storage degradation, known in English as silent data corruption or bit rot. Countermeasures include ECC memory, file-system-level checksums, redundant storage architectures and regular consistency checks of data holdings.
Logical data integrity concerns the internal consistency of data within its structure. In relational databases, it is classically divided into four categories: entity integrity requires that every record be identifiable by a unique, non-empty primary key; referential integrity ensures that every foreign key refers to an actually existing record, so that no orphaned links arise; domain integrity restricts values to permitted data types, formats and value ranges; and user-defined integrity encodes business rules — for example, that an end date must not precede the start date.
At the transaction level, logical data integrity is secured by the ACID principle: atomicity, consistency, isolation and durability. This guarantees that a transaction either takes effect in full or not at all — the reason why an aborted booking process leaves no half-committed records behind.
What causes data integrity violations?
Data integrity is violated both unintentionally and deliberately, with unintentional causes being significantly more common in practice. These include hardware defects and bit errors, faulty software and interfaces, interrupted transmissions, errors during migrations and imports, inconsistent character set or format conversions, and straightforward human input errors. A single misconfigured import can corrupt more records than a targeted attack.
Deliberate violations of data integrity range from manipulation by insiders with legitimate access rights, through malware and ransomware, to attacks during transmission. In a man-in-the-middle attack, communication is not merely intercepted but altered before being passed on — a scenario against which pure transport encryption without authentication of the remote party provides no reliable protection. Attacks on log data are particularly significant: anyone who can alter log files eliminates the traces of all other actions.
A frequently underestimated case is integrity violation caused by legitimate processes. Automated clean-up routines, synchronisation between systems with differing data models, and uncoordinated bulk changes regularly destroy data holdings with no malicious intent — and without triggering any security measure, because the person initiating the action was authorised to do so.
How can data integrity be ensured technically?
Data integrity is ensured technically through checksums, cryptographic methods, transaction security, immutable storage and comprehensive logging. No single method covers all requirements; effective protection comes only from a combination tailored to the organisation’s specific security needs.
| Method | Effect | Limitation |
|---|---|---|
| Checksum (e.g. CRC) | Detects accidental transmission and storage errors | No protection against targeted manipulation |
| Cryptographic hash function (e.g. SHA-256) | Makes any change detectable | Only effective if the hash value itself is stored in a tamper-proof location |
| HMAC | Change detection using a shared key | No non-repudiation with respect to third parties |
| Digital signature | Integrity, authenticity and non-repudiation | Requires key management and PKI infrastructure |
| Authenticated encryption (AEAD) | Confidentiality and integrity in a single step | Protects transport and storage, but not data entry |
| ACID transactions | Consistent states within databases | Effective only within the respective system |
| WORM / immutable storage | Prevents subsequent modification, even by administrators | Requires clearly defined retention periods |
| Logging, optionally with hash chaining | Makes changes detectable and attributable | Only effective when logs are stored separately and in a protected location |
Two points deserve particular attention. First: encryption alone does not ensure data integrity. Pure confidentiality methods without authentication are malleable — an attacker can deliberately alter the ciphertext without knowing its content, and the recipient will not notice. This is why current methods such as AES-GCM or ChaCha20-Poly1305 use authenticated encryption, which provides confidentiality and integrity together. End-to-end encryption also only protects against manipulation when it includes message authentication.
Second: hash methods become outdated. MD5 and SHA-1 are considered unsuitable for integrity verification due to practically feasible collision attacks. For the selection of current methods and key lengths, the authoritative reference in German-speaking countries is BSI Technical Guideline TR-02102-1. An integrity proof based on a broken method is no longer a proof — even if it continues to function technically.
At the organisational level, these technical measures are complemented by a permissions framework based on the principle of least privilege, separation of execution and control for critical changes, the four-eyes principle, verified backups with restoration testing, and versioning. Backups only secure integrity if their immutability is guaranteed — ransomware typically targets backup copies first.
What legal requirements apply to data integrity?
Data integrity is explicitly required under several regulatory frameworks. The GDPR references it in Article 5(1)(f) as a fundamental principle and specifies it further in Article 32(1)(b) as an obligation to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems; Article 32(1)(d) additionally requires a process for regularly testing and evaluating the effectiveness of these measures. The Standard Data Protection Model of the German supervisory authorities lists integrity as a distinct assurance objective and assigns specific measures to it, making the implementation of Article 32 GDPR auditable.
For operators of critical infrastructure and entities covered by the NIS 2 Directive (EU) 2022/2555, requirements arise from Article 21, which mandates risk management measures including cryptographic concepts, backup management and security in procurement, development and maintenance. In Germany, these obligations for critical infrastructure are supplemented by the BSI Act.
In accounting, the GoBD apply — based on Section 146(4) of the German Fiscal Code (AO): a booking entry must not be altered in such a way that its original content can no longer be determined. This gives rise to the obligation for immutable storage and comprehensive logging — the practical origin of most audit-compliance requirements in German organisations. In regulated pharmaceutical and medical device environments, data integrity is an established discipline in its own right: FDA 21 CFR Part 11 and Annex 11 of the EU GMP Guidelines require traceable electronic records, typically described by the ALCOA+ principles (attributable, legible, contemporaneous, original, accurate — and additionally complete, consistent, enduring and available).
For evidential purposes, the eIDAS Regulation (EU) No 910/2014 — with its qualified signatures and timestamps — and BSI Technical Guideline TR-03125 (TR-ESOR) on the preservation of evidential value in cryptographically signed documents are authoritative. They address the question of how data integrity can be demonstrated over retention periods of years or decades — an aspect that technical measures alone cannot cover, since algorithms and certificates age over time.
What role does data integrity play in crisis and emergency communication?
In crisis communication, data integrity is directly relevant to operational decision-making, because recipients act immediately on the basis of the information transmitted. An altered location, a manipulated alert message or a forged instruction takes effect within minutes during an operation — quite unlike a falsified record in a reporting system, which may take weeks to surface. The situation is compounded by the fact that in a crisis there is neither time nor calm for clarifying queries, and recipients under pressure are less likely to apply critical scrutiny.
Three requirements follow from this. First, the sender must be unambiguously identifiable so that instructions can be attributed. Second, the message content must be immutable in transit, which requires authenticated encryption. Third, the sequence of events must remain traceable after the fact: who communicated what and when, who received it, and what administrative interventions took place? This documentation is not only relevant for post-incident review, but also for reporting obligations, regulatory proceedings and the presentation of evidence to insurers. In Business Continuity Management, it is therefore listed as a distinct requirement for emergency communication tools.
In practice, the failure more often lies not in cryptography but in the choice of channel. When participants switch to personal messaging apps or verbal instructions during an incident, a communication record is created that is neither complete nor verifiable — and cannot be reconstructed after the event. Organisations typically address this through approved communication solutions in which sender identity, message history and administrative interventions are centrally logged and exportable. Their GDPR compliance and integrity assurance must be considered together, since log data itself constitutes personal data.
Teamwire can demonstrate how message histories, permissions and administrative interventions can be logged in a traceable and auditable manner — in a demo or a free trial.
What mistakes most commonly compromise data integrity?
The most common mistake is assuming that encryption and backups already cover data integrity. Both address different security objectives: encryption without authentication protects confidentiality; backups protect availability. Further typical weaknesses include:
- Checksums are generated but never systematically verified
- Log files are stored on the same system whose manipulation they are supposed to evidence
- Backups are not write-protected and are therefore vulnerable to ransomware
- Administrative accounts can modify data and logs without detection; separation of execution and control is absent
- Interfaces between systems do not validate imported data for plausibility and completeness
- Restorations from backups are never tested, meaning corrupted backups are only discovered in a real emergency
- Outdated hash methods remain in use for compatibility reasons
- Integrity requirements are not differentiated by protection level, so non-critical data is heavily protected whilst critical data is overlooked
Key takeaways
- Data integrity refers to the completeness, integrity and accuracy of data throughout its entire lifecycle — from capture through transmission and storage to archiving.
- Alongside confidentiality and availability, data integrity is one of the three core values of information security and is enshrined in Article 5(1)(f) and Article 32 of the GDPR.
- Most integrity methods do not prevent changes — they make them detectable; genuine change protection requires immutable storage.
- Data integrity is not the same as factual accuracy: an incorrectly recorded value remains incorrect even when stored with integrity protection.
- A distinction is drawn between physical data integrity (hardware, transmission, storage) and logical data integrity, encompassing entity, referential, domain and user-defined integrity.
- Encryption alone does not ensure integrity — authenticated methods such as AES-GCM or ChaCha20-Poly1305, or supplementary MAC or signature methods, are required.
- Key measures include hash values, HMAC, digital signatures, ACID transactions, WORM storage, versioning and protected logging in a separate, secure location.
- The most common cause of data integrity loss is unintentional errors in migrations, interfaces and bulk changes — not attacks.
- Legal requirements arise from the GDPR, the NIS 2 Directive (EU) 2022/2555, the BSI Act, the GoBD and Section 146(4) AO, as well as sector-specific requirements from 21 CFR Part 11 and EU GMP Annex 11.
- An unauthorised alteration of personal data constitutes a personal data breach under Article 4(12) GDPR and may trigger the reporting obligation under Article 33 GDPR.