What is a personal data breach?
A personal data breach is a security failure that affects personal data, as defined in Article 4(12) of Regulation (EU) 2016/679 (GDPR). The definition needs two things: a breach of security and one of five outcomes for personal data. Intent is not required, because the definition expressly covers accidental breaches.
How the notification duty fits into the rest of data protection law is set out in the GDPR guide for companies.
Which incidents count as a personal data breach?
Any incident that leads to at least one of the five outcomes in Article 4(12) GDPR is a personal data breach. Unauthorised access is an outcome of its own: someone who reads data without authorisation has disclosed nothing and changed nothing, and it is still a breach.
| Outcome under Article 4(12) | Security objective affected | Example |
|---|---|---|
| Destruction | Availability | A mailbox is deleted and no backup exists |
| Loss | Availability | An unencrypted laptop is left on a train |
| Alteration | Integrity | A faulty import overwrites customer addresses |
| Unauthorised disclosure | Confidentiality | A mail merge goes to the wrong distribution list |
| Unauthorised access | Confidentiality | An employee without permission views personnel files |
The "security objective" column maps the outcomes to the three objectives of information security. The mapping shows that an outage with no data leaving the organisation can also be a personal data breach.
Personal data breach, GDPR infringement and security incident: three scopes
The three terms trigger different duties, even where they describe the same event. Only a breach under Article 4(12) starts the notification chain of Articles 33 and 34 GDPR.
| Term | What it means | Triggers Article 33 GDPR? |
|---|---|---|
| Personal data breach | a breach of security with one of the five outcomes for personal data | yes |
| GDPR infringement | any breach of the GDPR, such as processing without a legal basis | only if a security breach occurs at the same time |
| Security incident | an impairment of information security, with or without personal data | only where personal data is involved; other laws can impose their own reporting duties |
Every personal data breach is therefore a security incident. A GDPR infringement, by contrast, can exist without any security incident.
Does every personal data breach have to be reported?
No, the duties depend on the likely risk to the rights and freedoms of the individuals concerned. Article 33(1) and Article 34(1) GDPR set two separate thresholds:
| Likely risk | Notification to the supervisory authority (Article 33) | Communication to individuals (Article 34) | Internal documentation (Article 33(5)) |
|---|---|---|---|
| no risk | no | no | yes |
| risk | yes | no | yes |
| high risk | yes | yes, except in the cases of Article 34(3) | yes |
For the assessment, Recital 85 GDPR lists the damage a breach can cause. It includes identity theft or fraud, financial loss, discrimination, damage to reputation and unauthorised reversal of pseudonymisation.
The documentation under Article 33(5) also applies to breaches that are not notified. It covers the facts, the effects and the remedial action and must allow the supervisory authority to verify compliance. An organisation that does not notify therefore keeps the reasons for that decision on record.
What must a notification under Article 33 GDPR contain?
Article 33(3) GDPR sets four minimum items. Under Article 34(2), the communication to individuals must contain three of them and describe the nature of the breach in clear and plain language.
| Minimum item | Notification to the authority | Communication to individuals |
|---|---|---|
| (a) nature of the breach, where possible with the categories and approximate number of individuals and records concerned | yes | nature of the breach in plain language |
| (b) name and contact details of the data protection officer or another contact point | yes | yes |
| (c) likely consequences of the breach | yes | yes |
| (d) measures taken or proposed, including mitigation | yes | yes |
The details under point (a) depend on groundwork: an organisation that knows which systems hold which data categories can name categories and orders of magnitude within the deadline.
The 72 hours run from awareness
Under Article 33(1) GDPR, the deadline starts when the controller becomes aware of the breach, not when the root-cause analysis is complete. Notification is due "without undue delay and, where feasible, not later than 72 hours" after awareness. A later notification must be accompanied by reasons for the delay.
A processor notifies the controller without undue delay under Article 33(2), not the supervisory authority. The processor's reporting time does not use up the controller's 72 hours, because these only run from the controller's own awareness. Article 28(3)(f) GDPR also obliges the processor to assist the controller with the obligations of Articles 32 to 36.
How roles, reporting lines and forms are fixed before an incident is shown in the data breach response plan.
Communication to individuals can be skipped in only three cases
Article 34(3) GDPR exempts the controller from communicating a high-risk breach if one of three conditions is met.
| Exception | What the provision requires |
|---|---|
| Point (a): protection measures | The measures were applied to the affected data and render it unintelligible to unauthorised persons, such as encryption. If the key is also affected, the data is no longer unintelligible. |
| Point (b): subsequent measures | After later measures, the high risk is no longer likely to materialise. |
| Point (c): disproportionate effort | The information is not dropped. A public communication or a similarly effective measure takes its place. |
GDPR and NIS2 notifications run separately
An incident at an entity in scope of NIS2 can trigger both a GDPR notification and a report under § 32 of the German BSI Act (BSIG). The two reports go to different bodies and follow different deadlines.
| Feature | GDPR | § 32 BSIG |
|---|---|---|
| Trigger | personal data breach | significant security incident, with or without personal data |
| Recipient | competent data protection supervisory authority | joint reporting office set up by the BSI and the BBK |
| First deadline | without undue delay, where feasible within 72 hours of awareness | early initial report without undue delay, at the latest 24 hours after becoming aware |
| Further stages | information provided in phases | report at the latest 72 hours after becoming aware; interim report only at the request of the BSI; final report at the latest one month after the 72-hour report |
| Informing third parties | communication to individuals in case of high risk | under § 35 BSIG, the BSI can order the entity to inform the recipients of its services |
The 72 hours under the BSIG run from awareness, not from the initial report. Under § 28(5) to (7) BSIG, different rules apply to telecommunications providers, certain energy installations and financial entities under DORA. The stages are explained in detail in the entry on NIS2 incident reporting.
Rizzqo shows personal data on the affected system
Rizzqo carries on every system, application and service provider the personal-data flag it inherits from the processing activities it supports. If a server or a SaaS service is hit by an incident, the asset shows whether the assessment under Article 33 GDPR starts.
The categories of personal data sit on the processing activity itself, which is linked to the system. They provide the data categories for the notification under Article 33(3)(a). The inherited confidentiality rating shows how sensitive the data is rated. Every asset carries a named owner, and remedial measures run as tasks whose risk reduction is applied on completion.