Data breach notification is the legal obligation of a controller under the GDPR to report a personal data breach to the competent supervisory authority and, when the breach is likely to cause a high risk to individuals, to inform the affected people directly. It is set out in Articles 33 and 34 of the regulation and is widely known as the 72-hour rule, because the authority must be notified without undue delay and, where feasible, within 72 hours of the controller becoming aware of the breach.
The duty turns security incidents into a matter of accountability: the controller must assess risk, document every breach and be able to justify each decision not to notify.
What counts as a personal data breach
A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Not every security incident qualifies: an attack blocked before any personal data was touched is an incident, but not a breach in this sense.
Supervisory authorities classify breaches by the security property that failed. The three categories below often occur together in a single event, such as ransomware that both encrypts and exfiltrates data.
| Breach type | Meaning | Typical example |
|---|---|---|
| Confidentiality breach | Unauthorized disclosure or access | Email sent to the wrong recipients |
| Integrity breach | Unauthorized alteration of data | Tampered bank details in a supplier record |
| Availability breach | Loss of access or destruction | Ransomware with no usable backup |
A temporary loss of availability can still be a breach when it affects people, for example when a hospital cannot access patient records during treatment.
How the 72-hour clock and the two duties work
The clock starts when the controller becomes aware of the breach, which means having a reasonable degree of certainty that a security incident has compromised personal data. A short initial investigation is allowed, but deliberately delaying awareness is not. A processor must inform the controller without undue delay, and the controller’s clock then runs from that moment.
Article 33 and Article 34 create two separate duties with different thresholds, as the following table shows.
| Aspect | Article 33 notification | Article 34 communication |
|---|---|---|
| Recipient | Competent supervisory authority | Affected data subjects |
| Threshold | Unless unlikely to result in risk | Likely to result in high risk |
| Deadline | Where feasible within 72 hours | Without undue delay |
| Content | Facts, numbers, consequences, measures | Plain-language description and advice |
| Exemptions | Breach unlikely to result in risk | Encryption, mitigating measures, disproportionate effort |
When full information is not available within 72 hours, the controller may notify in phases, sending what it knows and supplementing it later. A late notification must state the reasons for the delay. Under the one-stop-shop mechanism, a controller with cross-border processing usually notifies its lead supervisory authority.
Assessing risk to individuals
The decision to notify rests on a risk assessment from the perspective of the individuals, not the organization. Relevant factors include the type and sensitivity of data, the volume of records, how easily people can be identified, the severity of consequences and whether the recipients are trusted.
| Scenario | Likely risk | Resulting duty |
|---|---|---|
| Strongly encrypted laptop lost, key secure | Unlikely | Document internally only |
| Customer list sent to one trusted partner by mistake | Risk, quickly contained | Notify the authority |
| Health records exfiltrated by attackers | High | Notify the authority and individuals |
| Passwords leaked without strong hashing | High | Notify both and require password resets |
| Service outage of a few minutes | Usually unlikely | Document internally only |
Special category data, financial data, identity documents and data about children push the assessment toward high risk. Encryption only removes the duty to tell individuals when the key itself was not compromised.
Documentation, related regimes and sanctions
Article 33(5) requires the controller to document every personal data breach, including those not notified, with the facts, effects and remedial action. This breach register is distinct from the records of processing activities, but authorities often request both during an investigation.
Breach notification under the GDPR often overlaps with other reporting duties, so incident response plans must map several clocks running in parallel.
| Regime | Scope | Initial deadline |
|---|---|---|
| GDPR | Personal data breaches | 72 hours to the authority |
| UK GDPR | Personal data breaches in the United Kingdom | 72 hours to the ICO |
| NIS2 Directive | Significant incidents at essential and important entities | 24-hour early warning |
| ePrivacy rules for telecoms | Breaches at electronic communications providers | 24 hours to the authority |
Failure to notify can lead to an administrative GDPR fine of up to 10 million euros or 2 percent of worldwide annual turnover, whichever is higher. In practice, authorities often treat late or missing notification as an aggravating factor when they sanction the underlying security failure.
Common mistakes in breach notification
- Waiting for a complete forensic report before notifying, instead of using phased notification.
- Assessing risk from the company perspective, such as reputational damage, instead of harm to individuals.
- Not documenting non-notified breaches, which leaves no evidence that the decision was reasoned.
- Missing processor clauses in contracts, so suppliers do not report incidents promptly.
- Vague messages to individuals that do not explain what happened or what people should do.
Mature organizations rehearse breach scenarios, keep notification templates ready and involve the data protection officer from the first hour, which makes the 72-hour deadline realistic.
In everyday language
Data breach notification means that an organization must own up quickly when personal information it holds is lost, stolen or exposed. It has to tell the data protection regulator, usually within three days, and if the leak could seriously hurt people, it must also tell those people directly.
Think of it like a building manager who discovers that tenants’ spare keys were stolen. The manager must report it and, if burglaries are likely, warn the tenants so they can change their locks.
Seen in the real world
On a Friday evening, an online retailer discovers that attackers used a compromised administrator account to export about 48,000 customer records containing names, addresses and order histories. Payment cards are processed by a separate provider and are not affected, but the passwords were stored with an outdated hashing method.
The incident team contains the attack overnight and the data protection officer files an initial notification on Sunday, well inside 72 hours, with an estimated number of affected people. Because weakly hashed passwords create a high risk of account takeover, the retailer also emails every affected customer, forces password resets and recommends changing reused passwords elsewhere. A supplementary notification follows ten days later with the forensic findings and the new hashing scheme, and the authority closes the case with recommendations rather than a fine.