Skip to main content
DataRidge
Category: Cryptography and Encryption

Integrity

Also known as: data integrity
Simply put

In a data protection and security context, integrity refers to keeping data accurate, complete, and unchanged except through authorized means. It is one of the core aims of information security, alongside confidentiality and availability. The evidence available here does not cover the technical or regulatory framing of integrity, so this entry describes the general concept rather than a specific standard's definition.

Formal definition

Integrity, within information security, generally denotes the property that data is protected against unauthorized or accidental alteration, ensuring it remains accurate, complete, and reliable throughout its lifecycle. It is conventionally treated as one component of the confidentiality-integrity-availability model and is distinct from data governance concerns such as data quality, lineage, and stewardship, even where those disciplines overlap in practice. The evidence packet provided does not include authoritative security or regulatory sources (for example, ISO/IEC standards, the NIST Privacy Framework, or the GDPR) defining integrity; the sources present address integrity as a moral or ethical virtue rather than as a security property. Accordingly, this entry does not cite a governing instrument, and its scope excludes specific control requirements, measurement methods, and regulatory obligations, which should be sourced from an appropriate standard or legal text.

Why it matters

In information security, integrity is one of the three core aims commonly grouped as confidentiality, integrity, and availability. Where integrity fails, data can be altered, corrupted, or falsified without detection, undermining any decision, transaction, or record that relies on it. For compliance officers and privacy engineers, this matters because personal data that cannot be trusted to be accurate and complete may lead to wrongful outcomes for data subjects and may erode the demonstrable accountability that governance frameworks generally require. Stated intent to protect data is not sufficient; the ability to show that data has been preserved against unauthorized or accidental change is what makes integrity meaningful in practice.

Integrity also sits at the boundary between information security and data governance, and conflating the two is a common expert-level error. Security-side integrity concerns protection of data against unauthorized or accidental alteration, while governance-side disciplines such as data quality, lineage, and stewardship address whether data is fit for purpose and how its origins are tracked. These overlap in practice, but they are not the same thing, and an entry that collapses them risks assigning obligations to the wrong function.

It should be noted that the evidence available for this entry does not include authoritative security or regulatory sources defining integrity as a security property. The sources present treat integrity as a moral or ethical virtue rather than a technical control objective. As a result, this discussion describes the general concept and does not draw on a specific standard or legal instrument; readers requiring control requirements, measurement methods, or regulatory obligations should consult an appropriate standard or legal text.

Who it's relevant to

Privacy engineers
Privacy engineers are typically responsible for implementing safeguards that keep personal data accurate, complete, and protected against unauthorized or accidental alteration. This entry describes the general concept only; specific control requirements should be drawn from an applicable standard or legal text, which is out of scope here.
Information governance leads
Governance leads should note the distinction between integrity as a security property and governance disciplines such as data quality, lineage, and stewardship. These overlap in practice but are not interchangeable, and obligations should not be assigned as though they were the same function.
Compliance officers and data protection officers
For these roles, integrity supports demonstrable accountability, which generally requires evidence rather than stated intent. This entry does not cover the specific regulatory obligations, control requirements, or measurement methods that would apply under any particular regime; those should be sourced from the relevant instrument.

Inside Integrity

Data integrity
The property that data remains accurate, complete, and unaltered except through authorized and intended changes. Within information security, integrity is one of the three core objectives alongside confidentiality and availability.
Integrity controls
Technical and procedural mechanisms intended to detect or prevent unauthorized modification, such as hashing, checksums, digital signatures, version control, access restrictions, and change logging. These generally address whether data has been altered, not whether it should be disclosed.
Accuracy as a governance dimension
In data governance, integrity overlaps with data quality concerns including accuracy, completeness, and consistency, supported by stewardship, lineage tracking, and validation rules. This governance framing is distinct from the security-control framing even where they reinforce one another.
Relationship to accountability
Under governance frameworks, maintaining integrity typically requires demonstrable evidence, such as audit trails or change records, rather than a stated intent to keep data accurate. Accountability depends on being able to show that controls operate as described.

Common questions

Answers to the questions practitioners most commonly ask about Integrity.

Is integrity the same thing as data quality or data accuracy under governance frameworks?
No. Integrity, as a security property, generally refers to protecting data against unauthorized or accidental modification, deletion, or corruption so that it remains complete and unaltered relative to its authorized state. Data quality and accuracy are governance concerns addressing whether data is correct, fit for purpose, timely, and consistent. Data can have high integrity in the security sense (unchanged, tamper-evident) while still being inaccurate or of poor quality. The two overlap where controls that preserve integrity also support reliable, accurate records, but they should not be collapsed into one concept.
Does maintaining integrity mean the data is protected overall, or does confidentiality still need to be addressed separately?
Integrity is only one of the commonly cited security properties, typically stated alongside confidentiality and availability. Preserving integrity ensures data is not improperly altered, but it does not by itself prevent unauthorized disclosure (confidentiality) or ensure timely access (availability). A control that guarantees integrity does not guarantee that the underlying data is otherwise protected, and integrity controls generally do not make personal data non-personal. These properties must be addressed together rather than treated as interchangeable.
What controls are commonly used to detect and prevent unauthorized modification of data?
Organizations typically rely on a combination of technical and procedural measures, such as access controls and least-privilege permissions to limit who can change data, cryptographic hashing or checksums to detect alteration, digital signatures for authenticity, version control, and audit logging to record changes. The appropriate mix depends on context, the sensitivity of the data, and the threat model. No single control should be treated as a guarantee; effectiveness depends on implementation and monitoring.
How should integrity controls be documented to support accountability?
Accountability under governance frameworks generally requires demonstrable evidence rather than stated intent. This typically means documenting which integrity controls are in place, how they are configured, who is responsible for them, and how they are tested and reviewed. Audit logs, change records, and periodic assessment results can serve as evidence. The scope of what must be documented depends on the applicable framework and the organization's own policies, and this entry does not cover specific retention periods for such records.
How does responsibility for integrity divide between a data controller and a data processor?
Responsibility depends on the role and the arrangement between the parties. A controller generally determines the purposes and means of processing and remains accountable for ensuring appropriate integrity measures are in place, while a processor typically implements integrity controls on the controller's behalf under contractual instructions. The precise allocation of obligations should be set out in the governing agreement. This entry does not cover the detailed contractual terms or cross-border considerations that may also apply.
How can an organization verify that integrity controls are working over time?
Verification is generally an ongoing activity rather than a one-time step. Common approaches include periodic integrity checks using hashes or checksums, review of audit and change logs, reconciliation against authoritative sources, and testing of controls as part of security assessments. Findings should feed back into control improvements. The suitable frequency and rigor depend on the sensitivity of the data and the organization's risk assessment, and no single verification method should be treated as conclusive on its own.

Common misconceptions

Integrity is the same as confidentiality, so protecting data from disclosure also protects its integrity.
Integrity and confidentiality are separate security objectives. Confidentiality concerns unauthorized disclosure, while integrity concerns unauthorized or unintended alteration. A dataset can be kept confidential yet still be corrupted, and data can retain integrity while being improperly exposed. The two require distinct controls.
Applying encryption to data ensures its integrity.
Encryption primarily addresses confidentiality and does not, by itself, guarantee that data has not been altered. Integrity generally relies on separate mechanisms such as hashing, digital signatures, or authenticated encryption. Encryption also does not render data non-personal where the underlying information still relates to an identifiable individual.
Integrity is purely a security matter and has no place in data governance.
Integrity spans both domains. Information security treats it as a control objective focused on unauthorized modification, while data governance treats accuracy, completeness, and consistency as data quality concerns supported by stewardship and lineage. The two overlap but should not be collapsed into a single discipline.

Best practices

Distinguish integrity controls from confidentiality controls in policy and design, and document which mechanism addresses which objective so gaps are not masked by overlapping tools.
Use appropriate technical mechanisms such as hashing, digital signatures, or authenticated encryption to detect unauthorized modification, rather than assuming encryption alone secures integrity.
Maintain audit trails and change logs that provide demonstrable evidence of who altered data and when, so accountability can be shown rather than merely asserted.
Coordinate security integrity controls with governance data quality processes, including stewardship, validation rules, and lineage tracking, while keeping the two disciplines clearly delineated.
Do not treat integrity mechanisms as changing the regulatory status of data; information that still relates to an identifiable individual generally remains personal data regardless of the controls applied.
Scope integrity requirements to the applicable regime and context, recognizing that specific obligations, retention rules, and enforcement details are addressed by other frameworks and are out of scope for this concept.