Integrity and confidentiality is a GDPR principle requiring personal data to stay accurate, protected, and available only to authorised parties. It combines change control with access control, so organisations can reduce tampering, accidental damage, and unauthorised disclosure. The principle is central to technical and organisational safeguard design.
How Integrity And Confidentiality Work Together
Integrity and confidentiality are usually discussed as separate guarantees, but the GDPR principle treats them as a combined safeguard objective. Integrity protects personal data from unauthorised or accidental alteration, while confidentiality limits disclosure to people or systems with a valid need to know.
That combination matters because data can be harmed without being stolen, and it can be exposed without being changed. A record that is quietly altered may drive the wrong business or compliance decision, while a record that is widely exposed can create privacy, fraud, or regulatory consequences even if its contents remain technically correct.
The practical effect is that organisations should think about both change control and access control at the same time. A control design that only prevents disclosure, or only prevents tampering, does not fully satisfy the principle if the other failure mode remains open.
What The Principle Protects In Practice
This principle applies to the security of personal data throughout its lifecycle, from collection and storage through processing, transmission, and deletion. It is not only about perimeter protection, but also about whether the data remains trustworthy and only reachable by authorised parties in the environments where it is handled.
In practice, the principle covers common control areas such as access restrictions, strong authentication, segregation of duties, logging, validation, backup, and controlled change management. These are not separate ideas bolted onto privacy after the fact, they are part of how an organisation preserves the reliability and restricted handling of personal data.
For technical teams, the key point is that confidentiality and integrity often fail through ordinary operational mistakes, not just deliberate attacks. Misconfigured permissions, poor version control, weak approval workflows, and unsafe storage locations can all undermine the principle even when no breach headline exists.
A useful way to understand this principle is to compare it with security properties that are visible in other trust frameworks. Secure development and supply-chain controls, for example, focus on preserving the correctness of artifacts and the trustworthiness of their handling, which is why guidance such as SLSA is often relevant when organisations need to preserve integrity in software delivery, and why NIST SSDF (SP 800-218) is useful when integrity depends on disciplined development practices.
Why Organisations Treat It As A Core Safeguard
Integrity and confidentiality are central because they support trust in the data itself. If personal data can be altered unnoticed, then decisions, analytics, alerts, and records may all become unreliable. If personal data can be viewed too broadly, then the organisation risks privacy harm, contractual failure, and regulatory exposure.
The principle also connects directly to governance because it gives a clear design standard for technical and organisational safeguards. Teams can use it to justify why access reviews, encryption, auditability, configuration control, and change approval are not optional process overhead, but part of protecting personal data in a way that is consistent and defensible.
This is why compliance-oriented control sets often group confidentiality, integrity, and related privacy protections together rather than treating them separately. For many readers, the clearest external reference point is the SOC 2 Trust Services Criteria (AICPA), which reflects the same security logic across security, confidentiality, availability, processing integrity, and privacy.
Where organisations need a broader security programme view, NIST Cybersecurity Framework 2.0 provides a useful structure for mapping protection, detection, response, and recovery around the systems that store or process personal data.
Common Failure Modes And Security Implications
Integrity and confidentiality often fail through the same operational weaknesses. Excessive permissions, weak credential handling, unmanaged copies of data, and poor audit coverage make it easier for data to be viewed, changed, or both. In other words, the principle is not just about preventing theft, it is about preventing untrusted handling.
One practical example is data stored in overly broad collaboration tools or code repositories. That can create confidentiality loss if the data is exposed, but it can also create integrity loss if records are edited without a reliable trail or approval path. Similar issues arise when backups, test environments, or exports drift away from production controls.
The security implication is that organisations should not treat confidentiality and integrity as separate checkboxes. A control that limits disclosure but leaves data vulnerable to tampering still fails the principle, and a control that checks integrity but leaves personal data widely accessible still fails it too.
Risk and Threat Considerations
When integrity and confidentiality fail, the impact is broader than a simple data leak. Attackers or careless insiders can alter records, abuse exposed data, or combine both effects to undermine trust in the organisation’s systems and decisions.
Failure mechanism: Common failure paths include excessive access, weak change control, insecure storage, and poor monitoring. Those weaknesses allow unauthorised viewing, silent modification, or long-lived exposure of personal data.
Impact: The result can be privacy harm, fraudulent records, regulatory findings, operational disruption, and loss of trust in the data used for business or compliance decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Controls authorised access to personal data, supporting confidentiality. |
| PR.DS — Data Security | Protects data against tampering and unauthorised disclosure across storage and transfer. | |
| DE.CM — Continuous Monitoring | Supports detection of unauthorised access or change to personal data. | |
| Recommendation — Enforce least-privilege access and review permissions for personal data systems. Apply data protection controls to preserve integrity and confidentiality in transit and at rest. Monitor for anomalous access and unexpected data modification events. | ||
| CIS Controls v8 | 3 — Data Protection | Directly addresses confidentiality and integrity safeguards for sensitive data. |
| 6 — Access Control Management | Limits who can read or change personal data. | |
| 4 — Secure Configuration of Enterprise Assets and Software | Configuration control reduces tampering and exposure paths. | |
| Recommendation — Classify personal data and apply protective controls based on sensitivity. Restrict and periodically review access to systems that process personal data. Harden systems that store personal data and track configuration changes. | ||
| NIST SP 800-63 | IA — Digital Identity and Authentication | Authentication supports authorised access to personal data. |
| Recommendation — Require strong authentication before granting access to personal data resources. | ||
| NIST SP 800-53 Rev 5 | AC — Access Control | Defines access restrictions needed to protect confidentiality. |
| SI — System and Information Integrity | Addresses integrity protections for data and systems. | |
| AU — Audit and Accountability | Audit trails help prove who accessed or changed personal data. | |
| Recommendation — Use access control policies to limit viewing and modification of personal data. Apply integrity checks and monitoring to detect unauthorised data changes. Log access and changes to personal data and review audit evidence regularly. | ||
Practitioner Guidance
What practitioners should care about: This principle is a design requirement, not just a legal phrase. Teams should translate it into concrete controls that preserve data accuracy and restrict access wherever personal data is stored, processed, copied, or shared.
Common misunderstanding: It is easy to assume that encryption or access restrictions alone are enough. In practice, the principle is only met when the organisation also controls changes, reviews access, and can detect unauthorised modification or disclosure.
Practitioner takeaway: Treat integrity and confidentiality as one control objective with two failure modes, then validate both against the systems that actually hold personal data.
