72h data breach notification: the precise procedure (Articles 33 + 34 GDPR)

A personal data breach creates two separate duties with two different thresholds and two different addressees. Anyone who conflates them either notifies too much to the wrong body or informs data subjects too late.

1. Art. 33 + 34 GDPR

Art. 33 and Art. 34 GDPR govern two separate routes: Art. 33 the notification to the supervisory authority from the threshold 'risk', Art. 34 the communication to the data subjects from the higher threshold 'high risk'.

"In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay." — Art. 33(1) GDPR

Two stages:

• Art. 33: notification to the supervisory authority (always where there is a risk) — being late does not remove the duty to notify; the notification is then made together with reasons for the delay.
• Art. 34: information to the data subjects (only where there is a high risk) — without undue delay and in clear and plain language, where the breach is likely to result in a high risk to the rights and freedoms of natural persons.

Both articles apply unchanged in Germany and Austria; what differs is the national superstructure: the competent authority, the supplementary criminal and administrative penalty provisions and the practice on reprimands. These differences are set out in section 4 and section 9.

2. When is notification mandatory?

There is a duty to notify whenever the breach is likely to result in a risk to the rights and freedoms of natural persons — the notification is dispensed with only in the converse case, where such a risk is unlikely to arise (Art. 33(1) GDPR).

What matters is keeping the two thresholds cleanly apart. The GDPR does not use 'risk' and 'high risk' synonymously: Art. 33(1) GDPR refers to a risk, Art. 34(1) GDPR to a high risk. For assessing a case this means: first examine whether any risk arises at all (notification yes/no), then separately whether it is high (communication yes/no).

Practical recommendation for the classification: work through the case along four questions — which types of data are affected (special categories under Art. 9(1) GDPR — health data, genetic and biometric data for the purpose of uniquely identifying a natural person; why a high risk is close at hand with them: section 5), how many people, how easily the data can be misused, and whether technical safeguards such as encryption take effect. Record the answers in writing — they later serve as the reasoning in the documentation register (section 6).

The following classification is practical guidance, not a statutory categorisation; what remains decisive is the assessment of the individual case under Art. 33(1) and Art. 34(1) GDPR. The column 'Decisive factor' names in each case the feature on which the classification turns.

3. The 72h action plan

The process falls into five stages — detection and crisis team (0-2h), containment and initial forensics (2-8h), classification (8-24h), drafting the notification (24-48h), sending it and keeping the record (48-72h); the sole anchor for the deadline is awareness under Art. 33(1) GDPR. The stages are this article's practical timing; the law only says 'without undue delay and, where feasible, not later than 72 hours' from the point at which the controller became aware of the breach.

What counts is awareness, not the completion of the forensics and not the decision of the management. The wording refers to 72 hours, not working days. Practical recommendation: arrange the availability of IT, the data protection officer and the management so that a breach detected on a Friday evening is not assessed only on the Monday, and document the moment of awareness to the minute — it later decides whether reasons for the delay must be attached.

The role of the data protection officer: the DPO informs and advises the controller, monitors compliance with the GDPR, advises on the data protection impact assessment, cooperates with the supervisory authority and acts as its contact point (Art. 39(1)(a) to (e) GDPR); the DPO is the contact point for data subjects under Art. 38(4) GDPR. That is why the DPO appears in the table at classification, drafting and sending — not as the person deciding on the notification, but as an advisory and monitoring function.

Practical recommendation for service providers: set the notification and information routes with your processors contractually. Art. 28(1) GDPR in any event only permits working with processors providing sufficient guarantees of appropriate technical and organisational measures; the contract under Art. 28(3) GDPR sets out the subject matter, duration, nature and purpose of the processing, the type of data, the categories of data subjects and the obligations and rights of the controller.

4. Notification to the supervisory authority

The notification goes to the supervisory authority competent for you — in Germany, for companies, to the authority competent under Land law, in Austria to the Data Protection Authority — and contains the mandatory information set out in Art. 33(3).

Mandatory content (Art. 33(3)):

1. Description of the breach (nature, circumstances)
2. Approximate number of data subjects + records
3. Categories of data
4. Likely consequences
5. Measures to address the breach
6. Measures to mitigate the damage
7. Contact details of the DPO / controller

Practical recommendation: determine in advance which internal source each of these seven items comes from — the number of data subjects from the database analysis, the data categories from the record of processing activities, the contact details from the documentation appointing the DPO. Anyone who only clarifies this allocation during the incident loses hours that are missing from the 72.

Practical recommendation: clarify before the emergency which Land authority is competent for you, and record the portal URL, the telephone number and the required form in the emergency plan — during an incident, searching for the right body otherwise costs time that is missing from the 72 hours.

Notification portals (examples):

• Example Bavaria: Bavarian Data Protection Supervisory Authority (BayLDA), lda.bayern.de — competent for non-public bodies. The Bavarian Commissioner for Data Protection (datenschutz-bayern.de), by contrast, is competent for the public sector.
• BfDI: bfdi.bund.de/datenpannen — only for federal public bodies and certain providers of telecommunications services (§ 9(1) BDSG), not for companies generally.
• Austria: Art. 33 GDPR applies word for word; the competent body is the Austrian Data Protection Authority (Datenschutzbehörde) as the national supervisory authority under Art. 51 GDPR (§ 18(1) DSG) — dsb.gv.at. The notification there therefore does not go to the BfDI or to a German Land authority; Art. 34 GDPR (information to data subjects) likewise applies unchanged. In addition to Art. 83 GDPR, § 62(1) DSG provides for national administrative penalties of up to EUR 50,000 (for example, intentionally unlawful access to a data processing operation); the body competent for these decisions is likewise the Data Protection Authority (§ 62(5) DSG).

Austrian particularity: § 11 DSG provides for a proportionate application of Art. 83 GDPR — in particular a reprimand by the Data Protection Authority instead of a fine for first-time infringements. That changes nothing about the duty to notify itself, but it does change the expectation as to how a first-time, cleanly documented incident will be handled.

5. Art. 34: information to data subjects

Data subjects must be informed where the breach is likely to result in a high risk to the rights and freedoms of natural persons — typically in the case of health, financial or identity data — without undue delay and in clear and plain language (Art. 34(1) GDPR).

Health data, genetic and biometric data for the purpose of uniquely identifying a natural person belong to the special categories under Art. 9(1) GDPR, the processing of which is prohibited in principle — with them, the assumption of a high risk is correspondingly close at hand.

Mandatory content:

• Clear description of the breach in plain language
• Contact details of the DPO
• Likely consequences
• Measures to mitigate the damage
• Recommendations to the data subject on how to limit the damage (change the password, inform the bank, monitor the account)

Exceptions under Art. 34(3): Art. 34(3) GDPR names three cases in which the communication is not required; they apply only where their conditions are actually met:

• Encryption was effective (the key was not compromised along with the data) — the provision requires that appropriate technical and organisational protection measures, in particular encryption, were applied.
• Measures effectively averted the risk — the high risk no longer exists as a result of subsequent measures.
• Disproportionate effort → a public communication instead — the individual communication is replaced by a public communication, not simply dropped.

Practical recommendation: for every exception relied on, document which of the three conditions you are assuming and what it follows from — in the case of encryption, for example, the method, the key management and the evidence that the key was not exfiltrated as well. This reasoning belongs in the same file as the notification decision under Art. 33 (section 6).

6. Mandatory documentation (Art. 33(5))

Every personal data breach must be documented, including one that need not be notified (Art. 33(5) GDPR). The documentation is the evidence that an omitted notification was a reasoned decision and not a failure to act.

• Date + time of occurrence + of becoming aware — the moment of awareness is the deadline anchor of Art. 33(1) GDPR; also record who learned of what and when.
• Detailed description — nature and circumstances, systems affected, data categories and the approximate number of data subjects and records; the notification under Art. 33(3) requires the same information.
• Consequences + risk assessment — assess both thresholds separately: risk (Art. 33(1) GDPR) and high risk (Art. 34(1) GDPR). Recommended: identify special categories under Art. 9(1) GDPR separately.
• Measures — containment, remediation and damage mitigation, each with a time stamp and the person responsible; where an exception is relied on, it is advisable to add the reasoning under Art. 34(3) GDPR (section 5).
• Reasons where no notification was made — this is the heart of the register: the decision against a notification must be comprehensible and forms part of the evidence of accountability under Art. 5(2) GDPR.

In practice, the breach case is measured against your record of processing activities — contradictions show up there; the order in which the supervisory authority examines matters is set out in the FAQ under 'What does the supervisory authority examine after a notified breach?'.

Practical rhythm (a recommendation, not a statutory deadline): evaluate the register at least annually and, in addition, after every notifiable incident — clusters at one point are the best indication of which technical or organisational measure is due next.

7. 8 practitioner cases

The eight cases are typified practitioner examples: they show how the two thresholds from section 2 affect the response — from the documented decision not to notify to the communication under Art. 34 GDPR, and even the pure loss of data without exfiltration is assessed for a risk. The column 'Decisive factor' names in each case the feature on which the classification turns; the examples make no statement about the outcome or the amount of any fine — the statutory range is set out in section 9.

8. Where NIS2 applies in parallel: two notification routes

If your company falls under the NIS2 regime, the same incident can trigger two notification chains at once: the 72-hour notification to the data protection supervisory authority under Art. 33(1) GDPR and the staged notification of a significant security incident to the cybersecurity reporting body.

Who is covered (Germany): operators of critical installations count as particularly important entities, as do — irrespective of the size thresholds — qualified trust service providers, top-level domain name registries, DNS service providers and certain providers of telecommunications services; in addition, other entities of a type specified in Annex 1 BSIG with at least 250 employees or more than EUR 50 million annual turnover and at the same time more than EUR 43 million annual balance sheet total. Important entities are trust service providers and certain smaller providers of telecommunications services — these irrespective of the size thresholds — as well as anyone operating a type under Annex 1 or Annex 2 BSIG and employing at least 50 employees or having an annual turnover and an annual balance sheet total of more than EUR 10 million each, in so far as the entity is not already a particularly important entity (§ 28(1) and (2) BSIG). Austria: the corresponding classifications are set out in § 24 and § 25 NISG 2026 (BGBl. I Nr. 94/2025); the Austrian obligations apply from 1 October 2026.

The trigger for the NIS2 notification is a significant security incident. In Germany that is an incident which has caused or can cause severe operational disruption of the services or financial loss for the entity concerned, or which has affected or can affect other natural or legal persons by causing considerable material or non-material damage (§ 2 no. 11 BSIG; a statutory instrument under § 56(5) BSIG may specify the definition further). In Austria, a cybersecurity incident is considered significant where it has caused or can cause severe operational disruption of the services provided by the entity or severe financial loss for the entity concerned, or where it has affected or can affect other natural or legal persons by causing considerable material or non-material damage (§ 35(1) NISG 2026, applicable from 1 October 2026). This threshold is a different one from that of Art. 33(1) GDPR — an incident can meet one and not the other.

All the deadlines in the following table are statutory deadlines.

Where the incident is ongoing, a progress notification or progress report initially takes the place of the final one; in Germany the final notification must be submitted once handling has been completed (§ 32(1) BSIG), in Austria the final report within one month of the completion of incident handling (§ 34(2) no. 5 NISG 2026, applicable from 1 October 2026). § 32(1) no. 3 BSIG requires an interim notification only upon request. Practical recommendation: keep a joint incident file for both notification routes, but separate assessment fields — the thresholds, the addressees and the deadlines differ, the recording of the facts does not.

9. Range of sanctions for infringements of Art. 33 and 34

Infringements of the notification and communication duties fall within the fine range of Art. 83(4) GDPR — up to EUR 10,000,000 or, in the case of an undertaking, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher; the catalogue in that paragraph covers, among others, Art. 25 to 39 GDPR, which include Art. 33 and Art. 34.

The higher range of Art. 83(5) GDPR — up to EUR 20,000,000 or up to 4% of worldwide annual turnover — applies to other types of infringement: infringements of the principles of processing and the conditions for consent (Art. 5, 6, 7, 9 GDPR) and of the rights of the data subject (Art. 12 to 22 GDPR). Both can concern the same incident where the breach results from a processing defect — the allocation follows the type of infringement, not the event.

Row 1 names the range relevant to infringements of Art. 33 and Art. 34 GDPR, row 2 distinguishes the higher range for other types of infringement from it, and rows 3 and 4 name the national supplementary provisions; the last two rows concern not Art. 33/34 GDPR but the parallel NIS2 obligations from section 8.

On the Austrian practice regarding reprimands, see section 4.