What is a Personal Data Breach?

Summary

A personal data breach is a security failure that results in personal data being destroyed, lost, altered, disclosed, or accessed without authorisation, whether by accident or on purpose. An email sent to the wrong person or a lost laptop can count. You must record every breach and, where feasible, report it to the regulator within 72 hours if it is likely to put people at risk.

This guide explains the legal definition, the three types of breach, common examples, how to assess the risk, and when to tell the regulator and affected people. Article references are to the GDPR.

Examples come from the UK regulator’s guidance, which is written for the UK GDPR.

Key Takeaways

•  A breach is about what happens to personal data, not only about losing it. Unauthorised access, accidental disclosure, unwanted changes and data becoming unavailable can all be breaches.

•  Not every breach has to be reported. You must notify the regulator only if the breach is likely to pose a risk to people, and notify the people themselves only if the risk is high.

•  Every breach must be recorded, including the ones you decide not to report (Article 33(5)).

The Legal Definition

Article 4(12) defines a personal data breach as a security breach that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

The UK regulator, the ICO, explains in its guide to personal data breaches that this includes accidental and deliberate breaches. It also says a breach is more than just losing personal data.

Two points follow from the wording. There must be a security failure, and it must affect personal data. A security incident that doesn’t involve personal data isn’t a personal data breach, though it may still matter under other rules.

The Three Types of Breach

The ICO describes a personal data breach as a security incident that affects the confidentiality, integrity, or availability of personal data. In plain terms:

•  Confidentiality: someone sees or receives personal data they should not, such as a customer list sent to the wrong email address.

•  Integrity: personal data is changed without permission, such as records altered by an attacker or by mistake.

•  Availability: personal data is lost or cannot be accessed, such as files deleted by accident or locked by an attack.

A single incident can fall into more than one type. The ICO says data becoming unavailable is a breach when that unavailability significantly harms individuals.

Common Examples

The ICO lists examples of personal data breaches, including:

•  access by an unauthorised third party;

•  deliberate or accidental action, or inaction, by a controller or processor;

•  sending personal data to an incorrect recipient;

•  computing devices containing personal data being lost or stolen;

•  alteration of personal data without permission; and

•  loss of availability of personal data.

Many breaches start with ordinary mistakes. The ICO says human error is the leading cause of reported data breaches, and suggests measures such as training, a “check twice, send once” approach and disabling email autofill.

Not Every Breach Has to Be Reported

The key question is the effect on people. The ICO says the focus is on the potential negative consequences for individuals, and that you should assess both how severe they could be and how likely they are.

The ICO gives contrasting examples:

•  Report to the regulator: the theft of a customer database whose data may be used to commit identity fraud.

•  Usually no need to report: the loss or inappropriate alteration of a staff telephone list.

•  Tell the people affected: a hospital breach that accidentally discloses patient records, because of the sensitivity of the data.

•  No need to tell the people affected: a university member of staff accidentally deletes alumni contact details, which are then restored from a backup.

Even if you decide not to report, the ICO says you must be able to justify the decision, so document it.

When to Tell the Regulator

Article 33(1) requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. This does not apply if the breach is unlikely to result in a risk to people’s rights and freedoms. If you report after 72 hours, you must explain the delay.

Article 33(3) lists what the report must contain, at least:

•  the nature of the breach, including where possible the categories and approximate number of people and records concerned;

•  the name and contact details of the data protection officer or another contact point;

•  the likely consequences of the breach; and

•  the measures taken or proposed to deal with it and reduce its effects.

You do not need every answer before reporting. Article 33(4) allows you to provide the information in phases. The ICO adds that if you cannot give full details within 72 hours, it is a good idea to explain why and say when you expect to send more.

Our guide to data breach reporting covers the process step by step.

When to Tell the People Affected

Article 34(1) requires the controller to tell affected people without undue delay when the breach is likely to pose a high risk to their rights and freedoms. The message must describe the breach in clear, plain language and include the contact point, the likely consequences, and the measures taken (Article 34(2)).

The ICO also recommends practical advice, such as forcing a password reset, encouraging strong, unique passwords, and warning people to watch for phishing emails or fraud on their accounts.

Article 34(3) sets out when you do not need to tell people directly:

•  the data was protected by measures that make it unintelligible to anyone not authorised to access it, such as encryption;

•  you have taken steps since the breach that mean the high risk is no longer likely to happen; or

•  contacting everyone individually would involve disproportionate effort, in which case a public notice or similar measure must be used instead.

Article 34(4) allows the regulator to require you to inform people if it considers the risk is high.

Suppliers Must Tell You Too

Many breaches happen at a supplier, such as a hosting company, IT provider or software platform. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a breach.

The ICO gives the example of an IT firm that stores customer records and detects an attack that results in unlawful access. The IT firm tells its client, and the client then reports the breach to the ICO if it is reportable. The ICO says the contract must set out breach-reporting arrangements under Article 28. Our guide to GDPR sub-processors explains how this works down the supplier chain.

Record Every Breach

Article 33(5) requires the controller to document any personal data breach, including the facts, its effects and the remedial action taken. The record must allow the regulator to check that you have complied with the notification rules.

A simple breach log that includes the date, what happened, the data and people involved, the risk assessment, the reporting decision, and the actions taken covers what Article 33(5) requires. Review it periodically to spot recurring causes.

Five Steps to Prepare

The ICO’s checklist suggests organisations prepare before anything goes wrong. Five practical steps:

•  Teach staff to recognise a breach: including mistakes such as wrongly addressed emails, not only cyber attacks.

•  Name who is responsible: a person or team who decides whether a breach has occurred and whether to report it.

•  Set an escalation route: so staff know who to tell, and how quickly.

•  Prepare a response plan: covering risk assessment, reporting to the regulator and telling individuals.

•  Check supplier contracts: make sure processors must tell you about breaches without undue delay.

A GDPR audit can check whether these are in place.

Conclusion

A personal data breach is any security failure that affects personal data, from a cyber attack to a misdirected email. Record every one, assess the risk to the people involved, and report to the regulator within 72 hours where that risk is likely. Where the risk is high, tell the people affected as well.

We are updating this guide because the original stated the 72-hour rule without its conditions, did not cover what a report must contain, the exceptions to telling individuals, the processor’s duty, or the record-keeping rule, and did not link to the law. Review your breach procedure against these points, and speak to our GDPR consultants if you want them to check it.

Frequently Asked Questions

Is Sending an Email to the Wrong Person a Data Breach?

It can be. The ICO lists sending personal data to an incorrect recipient as an example of a personal data breach. Whether you must report it depends on the risk. The ICO gives the example of medical records sent to the wrong professional, who told the sender and deleted them, as unlikely to result in a risk.

Do All Data Breaches Have to Be Reported?

No. Under Article 33(1), you report to the regulator only if the breach is likely to result in a risk to people. Under Article 34(1), you notify affected people only if the risk is high. Article 33(5) still requires you to record every breach.

When Does the 72 Hour Deadline Start?

It starts when the controller becomes aware of the breach, not when the breach happened. Article 33(1) requires notice without undue delay and, where feasible, within 72 hours of that point. If you notify later, you must explain the delay.

Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.