Category: Security & Breach Notification

Integrity Breach

Also known as: Integrity Data Breach

Simply put

An integrity breach happens when personal data is changed or corrupted without proper authorisation, whether deliberately or by accident. Unlike a breach where data is stolen or leaked, the information itself is altered or manipulated, so it may no longer be accurate or reliable. This is one recognised category of personal data breach alongside breaches affecting confidentiality and availability.

Formal definition

An integrity breach is a type of personal data breach characterised by the unauthorised or accidental alteration, manipulation, corruption, or destruction of personal data. It is generally distinguished from a confidentiality breach (unauthorised disclosure of, or access to, personal data) and an availability breach (accidental or unlawful loss of access to, or destruction of, personal data); a single incident may involve more than one of these categories. Integrity breaches may arise from intentional acts, such as unauthorised changes made after gaining access to systems, or from accidental events, and they can be difficult to detect where alterations are made without triggering defences. Note: the tripartite categorisation of breaches derives from regulatory guidance (notably guidance issued in relation to personal data breaches) rather than from an explicit definition of 'integrity breach' in the GDPR text; readers should verify the applicable categorisation and any notification obligations against the current official Regulation and relevant guidance. The evidence supplied includes an unrelated use of 'integrity breach' in an academic-conduct context, which is outside the scope of this data-protection definition.

Why it matters

An integrity breach can be more insidious than a breach involving theft or leakage of data, because the information itself is altered or corrupted rather than simply removed or exposed. Where personal data is changed without authorisation, it may no longer be accurate or reliable, which can undermine decisions taken on the basis of that data and erode trust in the systems that hold it. This category of breach also intersects with the accuracy principle: data that has been silently manipulated may present as complete and available while being fundamentally wrong.

Detection is a particular challenge. As some industry commentary notes, an integrity breach can occur where someone gains access to systems and quietly changes data or system behaviour without triggering defensive controls, meaning the alteration may go unnoticed for a considerable period. This makes both identification and remediation harder than in cases where data is exfiltrated and its absence or exposure is more readily apparent.

From a compliance perspective, it is important to recognise that the tripartite categorisation of breaches into confidentiality, integrity, and availability derives from regulatory guidance on personal data breaches rather than from an explicit definition of 'integrity breach' in the GDPR text itself. A single incident may fall into more than one category. Organisations should therefore assess each incident against the applicable categorisation and verify any notification obligations against the current official Regulation and relevant supervisory authority guidance, as the position may vary and evolve.

Who it's relevant to

Data Protection Officers and Compliance Leads

DPOs and compliance teams need to be able to classify incidents correctly when assessing whether a personal data breach has occurred and what obligations follow. Recognising an integrity breach as a distinct category, and understanding that an incident may span multiple categories, supports accurate breach assessment. Because the tripartite categorisation derives from guidance rather than an explicit GDPR definition, these professionals should confirm the applicable framework and notification requirements against the current Regulation and relevant guidance.

Security and Engineering Teams

Those responsible for system security should be aware that integrity breaches can occur where data or system behaviour is altered quietly, without triggering defensive controls, making detection difficult. This informs the design of monitoring, logging, and change-detection measures aimed at identifying unauthorised or accidental alterations to personal data, in addition to controls focused on preventing exfiltration.

Records and Data Quality Owners

Teams responsible for the accuracy and reliability of personal data records have a direct interest, because an integrity breach can render data inaccurate or unreliable even where it remains available and undisclosed. Understanding this category helps them consider how corrupted or manipulated data might affect downstream processes and decisions that rely on that data.

Inside Integrity Breach

Unauthorised alteration of personal data

An integrity breach involves personal data being changed, corrupted, or tampered with in a manner that was not authorised, affecting the accuracy or reliability of that data. It is one of the three recognised categories of personal data breach under the GDPR, alongside confidentiality breaches and availability breaches.

Relationship to the breach of security concept

An integrity breach is a type of personal data breach, which the GDPR defines as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Integrity breaches map specifically to the 'alteration' element of that definition.

Accidental or unlawful causation

The alteration may result either from deliberate/unlawful acts (for example, a malicious actor modifying records) or from accidental causes (for example, a faulty process corrupting data). Both fall within scope, and the cause is relevant to the subsequent risk assessment.

Risk-based notification triggers

Whether an integrity breach must be notified generally depends on assessing the risk to the rights and freedoms of affected individuals. Notification to the supervisory authority and, in higher-risk cases, communication to affected data subjects are governed by the GDPR's breach notification provisions and associated regulatory guidance.

Overlap with the accuracy principle

Integrity breaches can undermine the data accuracy principle, since altered data may no longer be accurate or up to date. The concept also connects to the integrity and confidentiality principle, which requires appropriate security of personal data. Practitioners should verify the specific article references against the current official text.

Common questions

Answers to the questions practitioners most commonly ask about Integrity Breach.

Is an integrity breach the same as a confidentiality breach?

No. Under GDPR guidance, a personal data breach is typically categorised into three types: confidentiality, integrity, and availability breaches. A confidentiality breach involves unauthorised or accidental disclosure of, or access to, personal data, whereas an integrity breach involves unauthorised or accidental alteration of personal data. A single incident can involve more than one category at once, but they are distinct concepts and should be assessed separately as part of your breach analysis.

Does every integrity breach have to be reported to the supervisory authority?

Not necessarily. Notification obligations under the GDPR generally turn on whether the breach is likely to result in a risk to the rights and freedoms of individuals, rather than on the breach category itself. An integrity breach that is unlikely to result in such a risk may not trigger the duty to notify the supervisory authority, though you should document your assessment either way. Because thresholds and regulator expectations can vary, verify the current position against the applicable official text and any relevant supervisory authority guidance.

How should we detect that an integrity breach has occurred?

Detection typically relies on technical and organisational measures that reveal unauthorised or accidental alteration, such as data validation checks, audit logs, integrity monitoring, checksums or hashing, and access logging. Alerts from these controls, together with staff reports and reconciliation processes, generally feed into your incident triage. The appropriate measures depend on the nature of the processing and the risk involved, and should be assessed rather than applied uniformly.

What should our breach response procedure capture when data has been altered?

In most cases you should record what data was affected, the nature and extent of the alteration, when it occurred and was detected, the categories and approximate number of individuals concerned, and the potential consequences for those individuals. Your procedure should also cover containment, whether the original values can be restored, and the risk assessment that informs any notification decisions. Documenting these steps supports your accountability obligations, though the exact detail required is context dependent.

How do we assess the risk to individuals from an integrity breach?

Risk assessment generally considers the type of breach, the sensitivity and volume of the altered data, the ease with which affected individuals could be identified, the severity of possible consequences, and whether the alteration could lead to incorrect decisions or harm. Special category data under Article 9 may raise the potential severity. This is a case-by-case, risk-based judgement, and you should document your reasoning rather than rely on a fixed rule.

What technical measures can reduce the likelihood or impact of an integrity breach?

Measures that are commonly used include access controls and least-privilege permissions, audit logging, integrity verification such as hashing or checksums, input validation, version control, and reliable backups that allow altered data to be restored. The appropriate combination is subject to assessment based on the nature, scope, context and purposes of the processing and the risks it presents, so no single set of controls will be suitable in all circumstances.

Common misconceptions

An integrity breach only occurs when a malicious attacker deliberately changes data.

Alteration can be accidental as well as unlawful. A software bug, misconfigured process, or human error that corrupts personal data can constitute an integrity breach, subject to assessment of the facts.

Every integrity breach must be reported to the supervisory authority and to affected individuals.

Notification obligations are generally risk-based. Whether an integrity breach requires reporting typically depends on the assessed risk to individuals' rights and freedoms, and thresholds for authority notification and individual communication differ. Practitioners should assess each incident against the current notification provisions and guidance.

An integrity breach is entirely separate from confidentiality and availability breaches.

The three categories describe different impacts but a single incident can involve more than one. For example, an attack might both alter data (integrity) and expose it (confidentiality), so incidents should be assessed across all relevant categories rather than assigned to only one.

Best practices

When investigating an incident, classify it against all three breach categories (confidentiality, integrity, availability) rather than assuming it fits only one, as a single event can span multiple types.

Document the cause of any data alteration, distinguishing accidental from unlawful origins, since this feeds directly into the risk assessment and any notification decision.

Conduct a risk-to-individuals assessment for each suspected integrity breach and record the reasoning, because notification obligations are generally risk-based rather than automatic.

Maintain data integrity controls and audit trails so that unauthorised or accidental alterations can be detected, evidenced, and where possible reversed.

Verify the applicable breach notification timeframes, thresholds, and article references against the current official GDPR text and relevant regulator guidance before acting, as detail and interpretation can vary.

Where altered data affects accuracy, take steps to correct or restore the data to support compliance with the accuracy principle and to limit downstream impact on data subjects.