Types of GDPR Data Breach: Confidentiality, Integrity and Availability

If you have been asked what is a confidentiality breach in the context of GDPR, the answer is one of three recognised breach types. Under the UK GDPR a personal data breach is any security incident that affects the confidentiality, integrity or availability of personal data, and a confidentiality breach is specifically the type where personal data is disclosed to, or accessed by, someone who was not authorised to see it. Understanding which of the three categories an incident falls into is the first thing the Information Commissioner’s Office expects you to work out, because it shapes how you assess the risk and whether you have to report it.

These three types come from what security professionals call the CIA triad: confidentiality, integrity and availability. They are the three properties that keep information trustworthy, and a breach is simply the loss of any one of them. A single incident can hit more than one at once, which is why a ransomware attack, for example, is usually both an availability and a confidentiality breach.

The 20 second answer, whichever type you were asked about

One question sorts almost every example you will be given. Take the incident and ask what happened to the data:

The three are not alternatives you pick between. One incident can be two or three at once, and ransomware usually is. The category does not decide whether you report; risk does, and the clock is 72 hours from awareness. If you need the actual deadline for a live incident, our ICO 72-hour deadline calculator works it out from the moment you became aware, including weekends.

What the UK GDPR actually defines as a breach

The legal definition is broad on purpose. A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The cause does not matter: it can be deliberate, like a hacker exfiltrating a customer database, or entirely accidental, like an email sent to the wrong recipient. What matters is the effect on the data, and that effect always falls into one or more of the three types below.

Confidentiality breach

A confidentiality breach happens when personal data is disclosed to, or accessed by, someone who was not authorised to see it. This is the type most people picture when they hear “data breach”, and it is the most common in practice.

Everyday examples include emailing a spreadsheet of customer details to the wrong address, sending a letter to the wrong postal address, a lost or stolen unencrypted laptop or USB stick, a misconfigured database left open to the internet, or an employee snooping on records they had no business reason to view. It also covers deliberate attacks such as hacking, phishing that harvests login details, and malware that steals data. The defining feature is always the same: personal data ended up in front of eyes that should not have seen it.

Integrity breach

An integrity breach is the loss of accuracy or completeness. It happens when personal data is altered without authorisation, whether that change is deliberate or accidental. The data still exists and may still be accessible, but it can no longer be trusted to be correct.

Examples include an attacker tampering with records, a faulty migration that corrupts fields across a database, someone overwriting the wrong customer’s file, or malware that silently changes stored values. Integrity breaches are easy to overlook because nothing is obviously missing or leaked, yet the consequences can be serious. If a patient’s medication record or a payroll file is quietly altered, decisions get made on wrong information.

Availability breach

An availability breach is the loss of access to personal data, or the loss of the data itself, when that loss has a real effect on the people the data is about. The classic modern example is ransomware, which encrypts your files so you can no longer reach them. It also covers accidental deletion with no backup, hardware failure that destroys the only copy, or a systems outage that locks you out of records you need.

A short outage that you recover from quickly with backups may not amount to a notifiable breach on its own, but a permanent loss, or a loss that stops you delivering a service people depend on, clearly does. The ICO’s own wording is the one to work to: a breach occurs “if the data is made unavailable and this unavailability has a significant negative effect on individuals” (ICO, Personal data breaches: a guide).

Note what that sentence does not say. It does not say permanent, and it does not set a number of hours. A temporary loss of availability is still an availability breach, and whether it is notifiable turns on the effect on people, not on how long it lasted. A two hour outage at a hospital and a two hour outage at a stationery wholesaler are the same incident in IT terms and different incidents under the UK GDPR.

That is also why the statutory wording in Article 4(12) puts “destruction” and “loss” in the same list as disclosure: the law treats data you can no longer reach as just as much of a breach as data someone else has read.

Which situation describes an example of an availability breach?

This comes up as a quiz or exam question often enough that it is worth answering directly. An availability breach is any situation where people who should be able to reach personal data can no longer reach it, or where the data is gone. Nobody has to have seen the data, and nothing has to have been altered. Loss of access is the whole test.

Run any candidate situation through one question: after this incident, can the organisation still get to the personal data when it needs it? If the answer is no, even temporarily, it is an availability breach.

Situations that are availability breaches:

• Ransomware encrypts a customer database and the organisation cannot open its own records. The textbook example.
• A server fails and the only copy of the data is on it, with no working backup.
• An employee deletes a folder of records in error and it cannot be restored.
• A backup restore fails during a migration and a period of records is lost.
• A flood or fire destroys the on-site server holding patient or customer files.
• A cloud provider outage locks a clinic out of appointment records for a day, so people cannot be treated or contacted.
• A laptop with the only copy of a spreadsheet is lost. If it was encrypted, it is an availability breach and not a confidentiality one.

Situations that are not availability breaches, and what they are instead:

• An email containing personal data is sent to the wrong recipient. Nothing was lost; it was seen by the wrong person. That is a confidentiality breach.
• A member of staff looks up a neighbour’s record with no business reason. Again confidentiality, not availability.
• A misconfigured database is left open to the internet. Confidentiality.
• Records are silently corrupted during a system migration so the data still exists but is wrong. That is an integrity breach.
• Someone edits a date of birth or a payment amount without authority. Integrity.

The common trap in the question is ransomware, because it usually counts twice. Modern ransomware exfiltrates a copy before it encrypts, so the same incident is an availability breach and a confidentiality breach at once, and you assess the risk across both effects rather than picking one label.

The second trap is duration. A short outage you recover from with a good backup can still be an availability breach; whether it is notifiable is a separate question, decided by the effect on individuals rather than by the number of hours.

Which of the following is an example of an integrity breach?

The integrity question is the one people get wrong most often, because the instinctive answer to “was there a breach?” is to look for data that leaked or data that vanished, and an integrity breach does neither. An integrity breach is any situation where personal data is altered without authorisation, so the data is still there and still reachable but can no longer be relied on to be correct. Deliberate or accidental makes no difference to the classification.

The test is one question: after this incident, is the personal data still an accurate record of the person? If the answer is no, it is an integrity breach, whoever caused it and whatever their intent.

Situations that are integrity breaches:

• A faulty data migration corrupts fields across a customer database, so addresses, dates or balances no longer match the people they belong to.
• An attacker edits records rather than stealing them, for example changing bank details on supplier or payroll files.
• Malware silently changes stored values without removing or copying anything.
• A member of staff overwrites the wrong customer’s file with another customer’s details.
• A patient’s medication record or allergy flag is altered without authority, which is the case regulators treat most seriously because a wrong record leads directly to a wrong decision.
• A bulk update runs against the wrong filter and writes the same value across thousands of rows.
• A restore puts back an out-of-date version over current records, so the data that is live is no longer the true one.

Situations that are not integrity breaches, and what they are instead:

• An email with personal data goes to the wrong recipient. Nothing was changed. Confidentiality.
• A spreadsheet of staff details is left on a public share. Confidentiality.
• Ransomware encrypts the customer database so nobody can open it. The data is unreadable rather than wrong, so on its own that is availability.
• A server dies and the only copy dies with it. Availability.
• A member of staff reads a record they had no reason to read. Confidentiality.
• A correction you made on purpose, such as fixing a misspelled name after a data subject asked you to. Authorised change is not a breach at all; keeping personal data accurate is a requirement under the accuracy principle.

Three traps to watch in the exam version of this question.

Encryption is not alteration. Ransomware changes the bytes on disk, so people reach for “integrity”. Classify it by effect on the people the data is about: they lose access, so it is availability, and if a copy was exfiltrated first it is also confidentiality.

Accidental counts. A clumsy migration and a malicious edit land in the same category. The regulation does not distinguish by intent when it classifies the breach, only when it weighs the risk and the response.

Integrity breaches are the hardest to notice, and the 72 hour clock still applies. Nothing is missing and nothing is public, so these can sit undetected for months. The deadline runs from when you become aware, so the practical defence is detection: change logging, checksums on bulk updates, and a restore test that compares record counts and sample values rather than just confirming the job ran.

Which type triggers a report to the ICO?

The type of breach does not automatically decide whether you report. What decides it is risk. You must assess whether the breach is likely to result in a risk to the rights and freedoms of individuals, thinking about consequences like identity theft, financial loss, discrimination or distress. If a risk is likely, you must notify the ICO without undue delay and within 72 hours of becoming aware of it. That clock runs from the moment you discover the breach, not from when it happened, and it does not pause for weekends or nights.

Not every incident meets that bar. Losing an internal list of desk phone extensions, or recovering a misdirected email before anyone opens it, is unlikely to need reporting. But you must still record every breach internally, whether or not you report it, so you can show the ICO your reasoning if asked. Article 33(4) also lets you report in phases if you do not have every detail within 72 hours, so a lack of full information is never a reason to miss the deadline.

For the practical mechanics of that report, see our guide to data breach reporting and the ICO 72-hour rule, and for the financial exposure, GDPR breach compensation covers what individuals can claim. If you want to reduce the chance of any of these types happening in the first place, a cyber security risk assessment is where to start.

Frequently asked questions

What is a confidentiality breach in the context of GDPR? A confidentiality breach is a type of personal data breach where personal data is disclosed to, or accessed by, someone who was not authorised to see it. Examples include emailing data to the wrong person, a lost unencrypted device, or a hacker accessing a customer database. It is the most common of the three GDPR breach types.

What is an integrity breach in the context of GDPR? An integrity breach is the unauthorised or accidental alteration of personal data, so the data is no longer accurate or complete. The information still exists but can no longer be trusted, for example when records are tampered with, corrupted during a migration, or overwritten in error.

What is an availability breach in the context of GDPR? An availability breach is the loss of access to personal data, or the loss of the data itself, in a way that affects the people it relates to. Ransomware encrypting your files, accidental deletion with no backup, and hardware failure that destroys the only copy are all availability breaches.

Which situation describes an example of an availability breach? Any situation where personal data can no longer be reached or no longer exists: ransomware encrypting a database, a server failing with no usable backup, records deleted in error, or a cloud outage that locks staff out of the files they need. If data was merely seen by the wrong person it is a confidentiality breach, and if it was altered it is an integrity breach.

Can one incident be more than one type of breach? Yes. Many incidents affect more than one property of the data at once. A ransomware attack that both locks you out of files and steals a copy of them is an availability breach and a confidentiality breach at the same time, and you assess the risk across all the effects it has.

Do I have to report every type of data breach to the ICO? No. You only have to notify the ICO if the breach is likely to result in a risk to individuals’ rights and freedoms, and then within 72 hours of becoming aware of it. You must, however, keep an internal record of every breach regardless of whether it is reportable.