Personal Data Breach (Data Breach): Notification Under Articles 33 and 34 GDPR
What to do in the event of a personal data breach: the procedure from detection through to documentation, the 72-hour deadline, the three risk levels, notification to the supervisory authority (Article 33), and communication to the data subjects (Article 34 GDPR).
A personal data breach, commonly referred to as a "data breach", is a security incident affecting personal data. Anyone who identifies such a breach is under time pressure: the GDPR attaches to it an obligation to notify the supervisory authority and, in certain circumstances, an obligation to communicate the breach to the data subjects, both subject to a short deadline. This page walks through the entire procedure and refers to the sub-pages for the details.
Key takeaways
- A personal data breach is any breach of security leading to the destruction, loss, alteration, or unauthorized disclosure of, or unauthorized access to, personal data (Article 4(12) GDPR).
- The legal consequences depend on the risk: from the point at which a risk exists, notification to the supervisory authority is required (Article 33); from the point at which a high risk exists, the data subjects must additionally be informed (Article 34).
- The notification to the supervisory authority must be made without undue delay and, where feasible, within 72 hours of becoming aware of the breach (Article 33(1) GDPR).
- You must document every breach, including one that is not subject to notification (Article 33(5) GDPR).
- Failure to notify, or notifying late or incompletely, risks an administrative fine (Article 83(4)(a) GDPR) and measures by the supervisory authority.
1. What a personal data breach is
The concept is legally defined in Article 4(12) GDPR and is dealt with in detail in the overview of definitions (see personal data breach). What is decisive is this: the issue is data security, not every infringement of data protection law. Processing without a legal basis is unlawful, but in itself does not yet amount to a personal data breach within the meaning of the notification obligations.
A breach exists as soon as one of three protected interests relating to personal data is impaired:
- Confidentiality: unauthorized or unintended disclosure of, or access to, data (for example, a letter sent to the wrong recipient, or a successful hacking attack).
- Integrity: unauthorized or unintended alteration of data.
- Availability: unauthorized or unintended loss of access to, or destruction of, data (for example, an encrypting ransomware attack, or a lost storage medium). A breach also exists where the data is merely unavailable for a not insignificant period of time.
A personal data breach is always also a security incident, but not every security incident affects personal data (EDPB, Guidelines 9/2022, para. 15). Scheduled and announced system maintenance that temporarily renders data unavailable is therefore not a personal data breach. The organizational obligations begin earlier: anyone processing personal data must, through technical and organizational measures, first be placed in a position to detect a breach at all (Article 32 GDPR).
2. The procedure at a glance
The following procedure applies to every personal data breach: from becoming aware of it, through the preliminary review and the risk assessment, to the three possible legal consequences and the concluding documentation. The risk assessment is the central junction, because it determines whether notification, communication, or documentation alone is required.
For the notification to the supervisory authority, the 72-hour period runs from the point in time at which awareness is obtained. The procedure is not a rigid scheme: immediate containment measures and the risk assessment take place in parallel, not one after the other.
3. The three risk levels and their legal consequences
The GDPR works with two thresholds, from which three levels result. What is decisive is always the risk to the rights and freedoms of the data subjects, not the risk to your own business.
| Risk level | When | Notification to supervisory authority (Article 33) | Communication to the data subjects (Article 34) | Documentation (Article 33(5)) |
|---|---|---|---|---|
| No or low risk | The breach is not likely to result in a risk | no | no | yes |
| Risk | The breach is likely to result in a risk | yes | no | yes |
| High risk | The breach is likely to result in a high risk | yes | yes | yes |
The classification is a forecast made from the perspective prevailing at the time of becoming aware of the breach. How it is carried out methodically is addressed on the sub-page risk assessment.
When in doubt, notify. Where a risk cannot be ruled out with certainty, the breach must be notified. If it later emerges that no risk existed after all, the notification can be corrected with the supervisory authority without any sanction being threatened. Conversely, failure to notify a breach that was in fact subject to notification is punishable by an administrative fine.
4. Acting immediately: the first steps
The following steps belong in every response plan. Anyone who has determined and rehearsed them in advance gains the decisive hours. Notification alone is not sufficient: containment, risk mitigation, protection of the data subjects, and documentation remain obligatory alongside it. The details are set out on the sub-page first steps and internal procedure.
5. Beyond the GDPR: further notification obligations
The notification obligations under Articles 33 and 34 GDPR do not stand alone. A single security incident can trigger several mutually independent notification obligations, each with its own addressees, deadlines, and content. The GDPR notification neither replaces these other notifications nor is replaced by them (EDPB, Guidelines 9/2022, para. 134). In the event of an incident, it must therefore always be examined whether regimes other than the GDPR apply:
- NIS 2 Directive and national implementing law: security notification obligations for essential and important entities in the case of significant security incidents, owed to the competent cybersecurity authorities. Where such an incident is accompanied by a personal data breach, the notification under Article 33 GDPR continues to apply alongside it.
- eIDAS Regulation: trust service providers notify security breaches with a significant impact to the competent supervisory body (Article 19 eIDAS Regulation); where the breach also concerns personal data, the data protection supervisory authority must be informed as well.
- Telecommunications: providers of publicly available telecommunications services are subject to a sector-specific obligation to notify and to communicate (§ 169 of the German Telecommunications Act, TKG).
- Sector-specific and contractual obligations: sectoral law, regulatory requirements, and contracts (for instance, obligations to inform contracting controllers) may call for further notifications.
The GDPR notification should therefore be conceived from the outset as part of an incident response plan that covers all relevant notification channels.
6. Consequences of infringements
Anyone who infringes the obligation to notify or to communicate risks an administrative fine of up to EUR 10 million or 2 percent of total worldwide annual turnover (Article 83(4)(a) GDPR). The distinction is important: a missing notification and inadequate data security are two separate infringements that can be penalized alongside one another (Articles 33 and 34 GDPR on the one hand, Article 32 GDPR on the other). In addition, there are measures by the supervisory authority such as a reprimand, an order to communicate the breach to the data subjects subsequently (Article 34(4) GDPR), or a ban on processing, as well as claims for damages by the data subjects (Article 82 GDPR). A failure to notify may moreover be treated as an indication of inadequate security measures.
7. Prevention: typical cases and countermeasures
The most effective response to data breaches is to avoid them. Tried and tested countermeasures can be assigned to the most frequent categories of cases; the details form part of the technical and organizational measures under Article 32 GDPR (EDPB, Guidelines 01/2021).
| Typical incident | Effective countermeasures |
|---|---|
| Ransomware | Up-to-date patch management, separate and tested backups, anti-malware, network segmentation |
| Misdirected transmission (email, letter) | Four-eyes principle, BCC for multiple recipients, automated instead of manual addressing, delayed sending |
| Loss or theft of devices | Device encryption, strong authentication, mobile device management with remote wipe |
| Account takeover and phishing | Multi-factor authentication, monitoring and regular review of forwarding rules, staff training |
| Data exfiltration via web vulnerabilities | Input validation, penetration testing, logging and intrusion detection |
8. Structure of this chapter
First steps and internal procedure
Detection, containment, internal reporting, preliminary review, from when the breach counts as known and the 72-hour period begins, obligations of processors.
Risk assessment
The three-tier risk model, the assessment factors, severity and likelihood of occurrence of the adverse effects, the risk matrix, and special cases such as encryption.
Notification to the supervisory authority (Article 33)
When, to whom, with what content, and within what deadline notification is made; phased and bundled notification; the documentation obligation under paragraph 5.
Communication to the data subjects (Article 34)
When communication is required in the case of a high risk, content and form, deadline, and the exceptions under Article 34(3) GDPR.
Article 33 GDPR
Statutory text: notification of a personal data breach to the supervisory authority.
Article 34 GDPR
Statutory text: communication of a personal data breach to the data subject.
EDPB Guidelines 9/2022
Guidelines on personal data breach notification.
EDPB Guidelines 01/2021
Worked examples regarding personal data breach notification.
9. Frequently asked questions
About the author
About the author
This article was written by Dr. Thomas Helbing, specialist lawyer for IT law in Munich.
Since 2020 and continuously through today (2026), Handelsblatt has recognized Dr. Helbing as one of "Germany's Best Lawyers" in IT law and data protection law.
According to Kanzleimonitor.de (2024 to 2026 editions), he ranks among the leading lawyers for data protection and IT law and is listed among the top 100 lawyers in Germany (2024/25). Kanzleimonitor is considered a particularly meaningful market study because it is based exclusively on personal recommendations from in-house counsel.
Dr. Helbing has many years of advisory experience in data protection and IT law and advises clients of all sizes, from startups through fast-growing SaaS companies and unicorns to international corporate groups.
His professional background covers the full spectrum of IT and technology law practice. He began his career at a major international law firm, then gained in-house experience at a DAX-listed company, and is himself an entrepreneur and founder of several digital ventures. He also has hands-on programming experience, which allows him to understand technical systems, software architectures and digital business models not only from a legal perspective but also from a technical one.
For many years, his clients have included technology companies and SaaS providers, leading German research institutions and a systemically important German bank. His advisory focus lies in particular on GDPR compliance, the data economy, SaaS, AI regulation and IT contract law.
Automated individual decision-making (Article 22 GDPR)
General prohibition, statutory criteria and exceptions of automated individual decision-making under Article 22 GDPR: solely automated processing, profiling and scoring, safeguards under Article 22(3), sensitive data and the relationship to the AI Act.
First Steps and Internal Procedure in the Event of a Personal Data Breach
What has to be done immediately after a data breach has been discovered: detection and containment, internal reporting, the preliminary review, from when the breach counts as known and the 72-hour period begins, and the obligations of processors.