# 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).

> Quelle: https://www.thomashelbing.com/en/wissen/dsgvo-hub/einzelthemen/datenschutzverletzung
> Sprache: en



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.

<Callout type="info">
  **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.
</Callout>

## 1. What a personal data breach is [#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](/docs/dsgvo-hub/begriffe-und-definitionen/1.2.12-verletzung-des-schutzes-personenbezogener-daten)). 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](https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202209_personal_data_breach_notification_v2.0_de_0.pdf), 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 [#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.

<Mermaid
  chart="flowchart TD
  K[&#x22;Awareness of a possible<br/>personal data breach&#x22;] --> M[&#x22;Internal report to the<br/>data protection officer /<br/>reporting point&#x22;]
  M --> V[&#x22;Preliminary review, where needed<br/>internal investigation and<br/>immediate measures&#x22;]
  V --> R{&#x22;Risk assessment&#x22;}
  R -->|&#x22;no / low risk&#x22;| D[&#x22;Internal documentation&#x22;]
  R -->|&#x22;risk&#x22;| A33[&#x22;Notification to the<br/>supervisory authority<br/>Article 33&#x22;]
  R -->|&#x22;high risk&#x22;| A34[&#x22;Notification to supervisory authority<br/>+ communication to the<br/>data subjects, Articles 33 and 34&#x22;]
  A33 --> D
  A34 --> D
  V -. &#x22;Processing on behalf<br/>of another party&#x22; .-> AG[&#x22;Inform the contracting controller<br/>without undue delay, Article 33(2)&#x22;]"
/>

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 [#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](/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.2-risikobewertung).

<Callout type="warn">
  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.
</Callout>

## 4. Acting immediately: the first steps [#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](/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.1-erste-schritte-und-interner-ablauf).

<Steps>
  <Step>
    **Contain.**

     Stop the incident and prevent it from spreading (isolate the system, reset access credentials, remote wipe, request the recipient to delete the data).
  </Step>

  <Step>
    **Report internally.**

     Inform the data protection officer or the internal reporting point immediately, providing all known details of the incident.
  </Step>

  <Step>
    **Establish the facts.**

     Examine whether a personal data breach exists at all, and record the date and time at which sufficient awareness was obtained. The 72-hour period runs from that point in time.
  </Step>

  <Step>
    **Assess the risk.**

     Determine the risk level on the basis of the severity and the likelihood of occurrence of the possible adverse effects.
  </Step>

  <Step>
    **Respond and document.**

     Notify and communicate according to the risk level. In every case, document the entire matter.
  </Step>
</Steps>

## 5. Beyond the GDPR: further notification obligations [#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](https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202209_personal_data_breach_notification_v2.0_de_0.pdf), 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 [#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 [#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](https://www.edpb.europa.eu/system/files/2022-09/edpb_guidelines_012021_pdbnotification_adopted_de.pdf)).

| 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 [#8-structure-of-this-chapter]

<Cards>
  <Card title="First steps and internal procedure" href="/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.1-erste-schritte-und-interner-ablauf" description="Detection, containment, internal reporting, preliminary review, from when the breach counts as known and the 72-hour period begins, obligations of processors." />

  <Card title="Risk assessment" href="/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.2-risikobewertung" description="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." />

  <Card title="Notification to the supervisory authority (Article 33)" href="/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.3-meldung-an-die-aufsichtsbehoerde" description="When, to whom, with what content, and within what deadline notification is made; phased and bundled notification; the documentation obligation under paragraph 5." />

  <Card title="Communication to the data subjects (Article 34)" href="/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.4-benachrichtigung-der-betroffenen" description="When communication is required in the case of a high risk, content and form, deadline, and the exceptions under Article 34(3) GDPR." />

  <Card title="Article 33 GDPR" href="https://dsgvo-gesetz.de/art-33-dsgvo/" description="Statutory text: notification of a personal data breach to the supervisory authority." />

  <Card title="Article 34 GDPR" href="https://dsgvo-gesetz.de/art-34-dsgvo/" description="Statutory text: communication of a personal data breach to the data subject." />

  <Card title="EDPB Guidelines 9/2022" href="https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en" description="Guidelines on personal data breach notification." />

  <Card title="EDPB Guidelines 01/2021" href="https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012021-examples-regarding-personal-data-breach_en" description="Worked examples regarding personal data breach notification." />
</Cards>

## 9. Frequently asked questions [#9-frequently-asked-questions]

<Accordions type="single">
  <Accordion title="I have just discovered a data breach. What do I have to do first?">
    First contain it (stop the incident, prevent it from spreading), then immediately inform the data protection officer or the internal reporting point. In parallel, establish whether a personal data breach really exists, and record the date and time of becoming aware, because the 72-hour period runs from that point in time. Then assess the risk and, depending on the outcome, notify and communicate. Document the entire matter. Details on the sub-page [first steps and internal procedure](/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.1-erste-schritte-und-interner-ablauf).
  </Accordion>

  <Accordion title="Do I have to notify every data breach to the supervisory authority?">
    No. Notification is required only where the breach is likely to result in a risk to the rights and freedoms of natural persons (Article 33(1) GDPR). Where a risk can be ruled out, the notification is not required. You must, however, document the breach in every case (Article 33(5) GDPR). Where the risk cannot be ruled out with certainty, you should notify.
  </Accordion>

  <Accordion title="By when do I have to notify?">
    Without undue delay and, where feasible, within 72 hours after you became aware of the breach (Article 33(1) GDPR). Where the notification is made later, you must accompany it with reasons for the delay. The 72 hours are an upper limit, not a buffer period: anyone in a position to notify earlier must notify earlier.
  </Accordion>

  <Accordion title="From when does the 72-hour period run, from the incident or from becoming aware of it?">
    From becoming aware of it. What is decisive is not the point in time of the incident, but the moment at which you know with sufficient certainty that a security incident has affected personal data. A short phase for clarifying whether a breach exists at all is permissible. It must not, however, be used to delay matters. More on this under [first steps and internal procedure](/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.1-erste-schritte-und-interner-ablauf).
  </Accordion>

  <Accordion title="To which supervisory authority do I have to notify?">
    To the supervisory authority competent for you. If you process data across borders, you notify the lead supervisory authority, which serves as the single point of contact (one-stop shop). The lead authority is not necessarily located where the data subjects reside or where the incident took place. When in doubt, notify the supervisory authority of the place where the incident occurred.
  </Accordion>

  <Accordion title="Do I also have to inform the data subjects?">
    Only where the breach is likely to result in a high risk to the rights and freedoms of the data subjects (Article 34(1) GDPR). In that case, the data subjects must be informed without undue delay in clear and plain language. A higher threshold therefore applies to the communication than to the notification to the supervisory authority. Details under [communication to the data subjects](/docs/dsgvo-hub/einzelthemen/datenschutzverletzung/1.3.15.4-benachrichtigung-der-betroffenen).
  </Accordion>

  <Accordion title="The data was encrypted. Do I still have to notify?">
    It depends. Where the data concerned is encrypted using a state-of-the-art method and the key has remained secure, the data is inaccessible to unauthorized persons. In that case, the communication to the data subjects is as a rule not required (Article 34(3)(a) GDPR). A notification to the supervisory authority may nevertheless be necessary, for instance where availability is impaired at the same time and no backup exists. If the key is compromised, a fresh assessment must be made.
  </Accordion>

  <Accordion title="My service provider caused the breach. Who notifies?">
    The processor reports the breach to you as the controller without undue delay (Article 33(2) GDPR). It does not itself notify the supervisory authority and does not have to assess the risk. The notification to the supervisory authority and the risk assessment are your task as the controller. Your deadline begins as soon as the processor has informed you.
  </Accordion>

  <Accordion title="I do not yet know all the details. Can I provide information later?">
    Yes. Where not all information is available, you may first submit an initial notification and provide the missing information in phases without undue further delay (Article 33(4) GDPR). Missing details do not justify postponing the initial notification beyond the deadline.
  </Accordion>

  <Accordion title="What happens if I do not notify, or notify too late?">
    A failure to notify, or a late or incomplete notification, may be penalized with an administrative fine (Article 83(4)(a) GDPR). The supervisory authority may additionally order corrective measures, for instance the subsequent communication of the breach to the data subjects. Alongside this, claims for damages by the data subjects come into consideration (Article 82 GDPR). Missing notifications may moreover be treated as an indication of inadequate security measures.
  </Accordion>

  <Accordion title="Do I have to document the breach even if I do not notify it?">
    Yes. You must document every personal data breach, including the facts, its effects, and the remedial action taken, irrespective of whether it is subject to notification (Article 33(5) GDPR). This documentation must enable the supervisory authority to verify compliance and forms part of [accountability](/docs/dsgvo-hub/einzelthemen/grundsaetze-der-verarbeitung/1.3.3.9-rechenschaftspflicht) (Article 5(2) GDPR).
  </Accordion>
</Accordions>


---

## About the author

This article was written by [Dr. Thomas Helbing, specialist lawyer for IT law in Munich](https://www.thomashelbing.com/en).

Since 2020 and continuously through today (2026), Handelsblatt has [recognized](https://www.thomashelbing.com/en#auszeichnungen) 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](https://www.thomashelbing.com/en#stationen) 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](https://www.thomashelbing.com/en#referenzen) 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**.