Guide · GDPR Art. 33, 34

As of 4 October 2026

Reporting a Personal Data Breach: 72-Hour Deadline, Duties and Steps

Misdirected email, stolen laptop, ransomware: in a personal data breach every hour counts. This guide shows when to notify the supervisory authority and inform data subjects, what goes into the notification, ten scenarios from the EDPB guidelines and a check with a 72-hour calculator.

Check your duties Duties at a glance

Notification duties under Art. 33 and 34
Content of the notification as a table
10 scenarios with assessment
Check with 72-hour calculator

app.simpleact.de

Data breach · Incident #2026-014

Email with customer data sent to the wrong list

Deadline supervisory authority41:12 hremaining · aware Mon 09:30

Mon 09:30Tip from a recipient, check started
Mon 10:15Email recalled, recipients asked to delete
Mon 14:00Risk assessment with the DPO
TueNotification to the supervisory authority
–Check whether to inform data subjects

Sample data · the deadline runs over weekends

In short

Notify a personal data breach to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it (Art. 33 GDPR) – unless it is unlikely to result in a risk to individuals. Where a high risk is likely, also inform the data subjects (Art. 34). Every breach is documented internally, even without notification.

Basics

What a personal data breach is – and which duties it triggers

The GDPR defines a "personal data breach" as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed (Art. 4(12)). The EDPB distinguishes three types: confidentiality breaches (data reaches unauthorised parties), integrity breaches (data is altered) and availability breaches (data is lost or inaccessible). One breach can involve several types at once.

Up to three duties follow. First, notification to the competent supervisory authority: without undue delay and, where feasible, not later than 72 hours after becoming aware – unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33(1)). Second, communication to data subjects where a high risk is likely (Art. 34(1)). Third – always – internal documentation of every breach with the facts, its effects and the remedial action taken (Art. 33(5)).

The 72 hours start with awareness, not with the incident. According to EDPB Guidelines 9/2022, a controller is aware when it has a reasonable degree of certainty that a security incident has compromised personal data. After a tip-off it may briefly investigate whether a breach has in fact occurred; that initial investigation must start as soon as possible. The deadline runs in hours – including weekends and public holidays.

The first to notice that something went wrong is often not the controller but a service provider. A processor notifies the controller without undue delay (Art. 33(2)); notifying the authority remains the controller's job. According to the EDPB guidelines, the controller is generally considered aware once the processor has informed it. That is why every data processing agreement needs a clear reporting chain (Art. 28(3)(f)).

What the notification must contain is set out in Art. 33(3): the nature of the breach with categories and approximate number of data subjects and records, the contact of the DPO or another contact point, the likely consequences and the measures taken or proposed. Where not all information is available, it may be provided in phases (para. 4). An incomplete notification within the deadline is therefore better than a complete one that is late. A late notification must be accompanied by reasons for the delay (para. 1, second sentence).

The communication to data subjects describes in clear and plain language what happened and contains at least the contact, the likely consequences and the measures (Art. 34(2)). It is not required where the data was rendered unintelligible to unauthorised persons, for instance by encryption, where subsequent measures have removed the high risk, or where it would involve disproportionate effort – in which case a public communication is needed instead (para. 3).

Infringements of Art. 33 and 34 can be fined under Art. 83(4)(a) with up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher. In practice something else often weighs more: if a breach becomes known another way – through data subjects, the press or the authority itself – the failure to notify is on the table next to the incident.

deadline from awareness – runs over weekends (Art. 33(1)): 72 h; deadline from awareness – runs over weekends (Art. 33(1))
types: confidentiality, integrity, availability (EDPB): 3; types: confidentiality, integrity, availability (EDPB)
or 2% of turnover: fine ceiling for breaches of Art. 33/34 (Art. 83(4)): €10m; or 2% of turnover: fine ceiling for breaches of Art. 33/34 (Art. 83(4))

Duties

Who must inform whom, and when?

The duties in a personal data breach at a glance – by recipient, trigger and deadline.

Notification to the supervisory authority: WhoController; TriggerEvery breach, unless a risk is unlikely; DeadlineWithout undue delay, where feasible within 72 hours of awareness; ReferenceArt. 33(1)
Reasons for delay: WhoController; TriggerNotification after more than 72 hours; DeadlineWith the notification; ReferenceArt. 33(1), 2nd sentence
Notification to the controller: WhoProcessor; TriggerEvery breach it becomes aware of; DeadlineWithout undue delay; ReferenceArt. 33(2)
Information in phases: WhoController; TriggerInformation not yet complete; DeadlineWithout undue further delay; ReferenceArt. 33(4)
Communication to data subjects: WhoController; TriggerHigh risk likely, no exception under para. 3; DeadlineWithout undue delay; ReferenceArt. 34(1)
Public communication: WhoController; TriggerHigh risk, individual communication disproportionate; DeadlineWithout undue delay; ReferenceArt. 34(3)(c)
Internal documentation: WhoController; TriggerEvery breach – even without notification; DeadlineOngoing; ReferenceArt. 33(5)

Scroll the table sideways →

Who must inform whom, and when?
Duty	Who	Trigger	Deadline	Reference
Notification to the supervisory authority	Controller	Every breach, unless a risk is unlikely	Without undue delay, where feasible within 72 hours of awareness	Art. 33(1)
Reasons for delay	Controller	Notification after more than 72 hours	With the notification	Art. 33(1), 2nd sentence
Notification to the controller	Processor	Every breach it becomes aware of	Without undue delay	Art. 33(2)
Information in phases	Controller	Information not yet complete	Without undue further delay	Art. 33(4)
Communication to data subjects	Controller	High risk likely, no exception under para. 3	Without undue delay	Art. 34(1)
Public communication	Controller	High risk, individual communication disproportionate	Without undue delay	Art. 34(3)(c)
Internal documentation	Controller	Every breach – even without notification	Ongoing	Art. 33(5)

The competent authority follows Art. 55 – in Germany, for companies usually the state data protection authority at the seat. Most authorities provide an online notification form.

Content

What goes into the notification and the communication

The minimum content under Art. 33(3) for the authority and Art. 34(2) for data subjects. The right-hand column shows what to prepare in practice – that is our recommendation.

Nature of the breach: AuthorityYes – point (a); Data subjectsYes – in clear and plain language; Practical tipWhat happened, when, how detected, which type (confidentiality, integrity, availability)?
Categories and approximate number of data subjects: AuthorityYes – point (a), where possible; Data subjects–; Practical tipAn estimate with a range beats no figure; refine later
Categories and approximate number of records: AuthorityYes – point (a), where possible; Data subjects–; Practical tipName special categories (Art. 9) explicitly
Contact of DPO or contact point: AuthorityYes – point (b); Data subjectsYes – Art. 34(2); Practical tipMake sure someone is reachable for questions
Likely consequences: AuthorityYes – point (c); Data subjectsYes – Art. 34(2); Practical tipConsequences for the people affected: identity theft, fraud, embarrassment, discrimination
Measures taken or proposed: AuthorityYes – point (d); Data subjectsYes – Art. 34(2); Practical tipContainment, remediation and what data subjects can do themselves, e.g. change passwords
Reasons for delay: AuthorityYes – para. 1, 2nd sentence; Data subjects–; Practical tipExplain honestly and specifically

Scroll the table sideways →

What goes into the notification and the communication
Item	Authority	Data subjects	Practical tip
Nature of the breach	Yes – point (a)	Yes – in clear and plain language	What happened, when, how detected, which type (confidentiality, integrity, availability)?
Categories and approximate number of data subjects	Yes – point (a), where possible	–	An estimate with a range beats no figure; refine later
Categories and approximate number of records	Yes – point (a), where possible	–	Name special categories (Art. 9) explicitly
Contact of DPO or contact point	Yes – point (b)	Yes – Art. 34(2)	Make sure someone is reachable for questions
Likely consequences	Yes – point (c)	Yes – Art. 34(2)	Consequences for the people affected: identity theft, fraud, embarrassment, discrimination
Measures taken or proposed	Yes – point (d)	Yes – Art. 34(2)	Containment, remediation and what data subjects can do themselves, e.g. change passwords
Reasons for delay	Yes – para. 1, 2nd sentence	–	Explain honestly and specifically

A first notification with the known facts is permitted; missing information is provided in phases (Art. 33(4)).

Interactive

Notification check with 72-hour calculator

Enter the time of awareness and answer four questions. You see whom to inform by when and get a skeleton for the notification under Art. 33(3). Nothing is stored or transmitted.

Became aware of the breach (date and time)

1 · Is personal data affected?

2 · Your role

3 · Risk to data subjects

app.simpleact.de

Your duties

Notification deadline

Enter the time of awareness

Counted conservatively from awareness, time in your time zone. The deadline runs over weekends and public holidays.

Notify the competent supervisory authority – without undue delay, where feasible within 72 hours (Art. 33(1))
No communication to data subjects as long as there is no high risk
Document the breach internally: facts, effects, remedial action (Art. 33(5))

Skeleton for the notification (Art. 33(3))

Notification of a personal data breach under Art. 33 GDPR
Became aware: [date, time] · Deadline: [date, time]

a) Nature of the breach: [what, when, how detected; confidentiality/integrity/availability]
   Data subjects: [categories], approx. [number]
   Records: [categories, Art. 9 where relevant], approx. [number]
b) Contact: [data protection officer or contact point, email, phone]
c) Likely consequences: [from the data subjects' perspective]
d) Measures: [taken / proposed, incl. mitigation]

Communication to data subjects: [yes – on / no – reasons]
Missing information will be provided under Art. 33(4).

A working aid, not legal advice. The risk assessment is a case-by-case decision – when in doubt, notify and add information in phases.

Scenarios

Ten data breaches and who to notify

The cases are summarised from Annex B of EDPB Guidelines 9/2022. They show the difference between risk and high risk – the assessment remains a case-by-case decision.

Encrypted backup on a USB key is stolen: Notify the authority?No; Inform data subjects?No; NoteIf encrypted to the state of the art, key not compromised and a backup exists. If the key is later compromised: notify.
Cyber attack on an online service, data exfiltrated: Notify the authority?Yes, if consequences are likely; Inform data subjects?Depending on the data and severity of consequences; Note–
Brief power outage at a call centre, customers cannot access records: Notify the authority?No; Inform data subjects?No; NoteNot notifiable, but to be documented under Art. 33(5).
Ransomware encrypts all data, no backup available: Notify the authority?Yes, if consequences are likely (loss of availability); Inform data subjects?Depending on the data and consequences; NoteWith a current backup and timely restore, no notification would have been needed.
Customer receives another person's bank statement: Notify the authority?Yes; Inform data subjects?Only those affected, if high risk; NoteBrief check whether a systemic flaw affects others.
Marketplace hacked, usernames, passwords and purchases published: Notify the authority?Yes (cross-border: lead authority); Inform data subjects?Yes, could lead to high risk; NoteForce password resets, check other notification duties.
Hosting provider finds a flaw, users can see others' account details: Notify the authority?Provider informs its clients, who assess and notify; Inform data subjects?If no high risk: no; NoteThe controller is considered aware once the provider informs it.
Hospital records unavailable for 30 hours after a cyber attack: Notify the authority?Yes; Inform data subjects?Yes; NoteHigh risk to patients' well-being and privacy.
Data of many students sent to a wrong list with 1,000+ recipients: Notify the authority?Yes; Inform data subjects?Depending on scope, data and consequences; Note–
Marketing email with all addresses in "to" or "cc": Notify the authority?May be required – many people, sensitive data or other risks; Inform data subjects?Depending on scope and data; NoteWith few addresses and no sensitive data possibly not needed.

Scroll the table sideways →

Ten data breaches and who to notify
Case	Notify the authority?	Inform data subjects?	Note
Encrypted backup on a USB key is stolen	No	No	If encrypted to the state of the art, key not compromised and a backup exists. If the key is later compromised: notify.
Cyber attack on an online service, data exfiltrated	Yes, if consequences are likely	Depending on the data and severity of consequences	–
Brief power outage at a call centre, customers cannot access records	No	No	Not notifiable, but to be documented under Art. 33(5).
Ransomware encrypts all data, no backup available	Yes, if consequences are likely (loss of availability)	Depending on the data and consequences	With a current backup and timely restore, no notification would have been needed.
Customer receives another person's bank statement	Yes	Only those affected, if high risk	Brief check whether a systemic flaw affects others.
Marketplace hacked, usernames, passwords and purchases published	Yes (cross-border: lead authority)	Yes, could lead to high risk	Force password resets, check other notification duties.
Hosting provider finds a flaw, users can see others' account details	Provider informs its clients, who assess and notify	If no high risk: no	The controller is considered aware once the provider informs it.
Hospital records unavailable for 30 hours after a cyber attack	Yes	Yes	High risk to patients' well-being and privacy.
Data of many students sent to a wrong list with 1,000+ recipients	Yes	Depending on scope, data and consequences	–
Marketing email with all addresses in "to" or "cc"	May be required – many people, sensitive data or other risks	Depending on scope and data	With few addresses and no sensitive data possibly not needed.

Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, Annex B (summarised).

Data breaches and AI

Data breaches in AI systems – and incidents under the AI Act

AI systems create new ways for data to end up in the wrong place. And the AI Act brings notification duties of its own that sit alongside the GDPR.

Typical AI data breaches

Confidential data entered into a public AI tool, a chatbot revealing other customers' data, histories visible to the wrong users, unprotected logs at the vendor. These are breaches under Art. 4(12) where personal data is involved.

Vendor as processor

If the AI vendor notices a breach, it must inform you without undue delay (Art. 33(2)). Check in the DPA how and how fast that happens – your 72 hours usually start with that notice.

Serious incidents under Art. 73 AI Act

Providers of high-risk AI report serious incidents to the market surveillance authority: at the latest 15 days after becoming aware, 2 days for widespread infringements or disruption of critical infrastructure, 10 days in the event of death.

Deployer duties

Deployers of high-risk AI inform without undue delay first the provider and then the importer or distributor and the competent market surveillance authorities of a serious incident (Art. 26(5) AI Act). Following the Digital Omnibus this applies to Annex III systems from 2 December 2027.

Two registers, two deadlines

One incident can be both a data breach and an AI incident. Then both deadlines run with their own recipients. Carry out both assessments and document them separately.

Prevention

Rules for entering personal data into AI tools, enterprise versions with training contractually excluded and short retention periods reduce the risk – that is our recommendation.

Further notification duties may apply, for example for operators of critical infrastructure or in certain sectors. Check them in parallel.

Approach

Handling a data breach in 7 steps

How an incident runs from discovery to closure. The process is a recommendation from practice; the deadlines come from Art. 33 and 34.

1
Detect and report internally
Everyone in the organisation must know where to report a suspicion – immediately, weekends included. Service providers report under the DPA.
2
Record the time
When did the breach become known with reasonable certainty? The 72 hours run from then. Record the time of the incident separately.
3
Contain
Stop the data leak, block access, recall emails, ask recipients to delete, reset passwords.
4
Assess the risk
Which data, how many people, how likely and how severe are the consequences? Involve the data protection officer.
5
Notify
Where there is a risk, notify the supervisory authority – incomplete if necessary. Where the risk is high, inform data subjects.
6
Fix and follow up
Remove the cause, provide missing information in phases (Art. 33(4)).
7
Document and learn
Record facts, effects, measures and decisions (Art. 33(5)). Feed lessons learned into TOMs and training.

Delay

What to do if the 72 hours have already passed

The 72 hours are not a cut-off: Art. 33(1) requires notification "without undue delay and, where feasible, not later than 72 hours". If the deadline has passed, notify anyway – with reasons for the delay. The authority then assesses whether the delay is understandable.

Often the problem is not the notification itself but a late start. Learning days later that a provider had a breach, or leaving a tip-off in an inbox, loses time you cannot get back. The EDPB expects the initial investigation to begin as soon as possible.

Just as important: the notification does not have to be complete. Where, and in so far as, it is not possible to provide the information at the same time, it may be provided in phases without undue further delay (Art. 33(4)). A first notification with the known facts within the deadline is therefore almost always the better route.

Notify anyway – with reasons for the delay
Better incomplete on time than complete too late
Provide missing information in phases
Fix the cause of the delay in your process

Common mistakes

Six mistakes with data breaches

Deadline counted from Monday

The 72 hours run in hours, over the weekend too. A breach discovered on Friday evening is due on Monday evening.

Not notified, not documented

Even a breach without a notification duty belongs in the documentation under Art. 33(5) – including the reasons why there is no risk.

Waiting for complete information

Notification may happen in phases. Waiting for every fact means missing the deadline.

Providers without a reporting chain

Without a clear rule in the DPA you learn of a breach at your provider too late or not at all.

Risk assessed from the company's view

What counts are the consequences for the people affected – identity theft, fraud, embarrassment – not reputational damage.

Encryption without evidence

The exception in Art. 34(3)(a) only helps if the encryption was effective and the key was not affected – you should be able to prove that.

With SimpleAct

Data breaches in SimpleAct

The GDPR module (from Professional) keeps every breach as an incident file – with an automatically calculated 72-hour deadline, status tracking and documentation under Art. 33(5).

Deadline calculated from the time of discovery, list sorted by it
Discovery and occurrence as separate timestamps
Status from "open" via "notified" to "closed"
Authority and data subject notification with time and reference
Risk rating, root cause analysis, measures, lessons learned
Link to the AI system and the RoPA entry

Data breach or AI incident?

Serious incidents under the AI Act have their own recipients and deadlines. In SimpleAct you keep them in incident management, data breaches in the GDPR module.

See incident management

FAQ

Frequently asked questions about data breach notification

No. Notification to the supervisory authority is not required where the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33(1)). Every breach must be documented, though (Art. 33(5)) – including the reasons why it was not notified.

When the controller becomes aware of the breach. According to the EDPB guidelines, that is when it has a reasonable degree of certainty that a security incident has compromised personal data. A short investigation is allowed but must start immediately.

Yes. The deadline is measured in hours and runs continuously. A breach discovered on Friday at 6 pm must be notified by Monday at 6 pm.

Under Art. 33(3) at least: the nature of the breach with categories and approximate number of data subjects and records, the contact of the DPO or another contact point, the likely consequences and the measures taken or proposed. Missing information may be provided later.

When the breach is likely to result in a high risk to their rights and freedoms (Art. 34(1)) – without undue delay and in clear, plain language. Exceptions apply for effective encryption, a risk removed afterwards or disproportionate effort; in the last case a public communication is needed.

The controller. The processor notifies it without undue delay (Art. 33(2)) and assists it (Art. 28(3)(f)). According to the EDPB guidelines the controller is generally considered aware from that notice.

Notification is still required, with reasons for the delay (Art. 33(1), second sentence). Infringements of Art. 33 and 34 can be fined under Art. 83(4)(a) with up to EUR 10 million or 2% of worldwide annual turnover.

Yes, if it discloses personal data to unauthorised people. Whether to notify depends on the risk: according to the EDPB examples, a marketing email with visible addresses may be uncritical with few recipients and no sensitive data, but notifiable with many people or sensitive data.

Not always. According to the EDPB guidelines, encryption by ransomware is a loss of availability. If a current backup exists and the data can be restored in good time, notification may not be required. If data was exfiltrated or there is no backup, it usually is.

Only if personal data is affected. Serious incidents under Art. 73 AI Act have their own recipients and deadlines. One incident can be both – then both notification duties run side by side.

More questions? We're happy to help. Send email · Try 7 days (credit card required)

Sources and status

As of 4 October 2026 · SimpleAct editorial team

This guide is general information and not legal advice. The scenarios are summarised from the EDPB guidelines; the assessment remains a case-by-case decision.

Changes

2026-10-04 – Page rebuilt: duties table, notification content, ten EDPB scenarios, notification check with 72-hour calculator, AI section.
2026-06-13 – First version.

Keep track of the 72 hours, weekends included

SimpleAct calculates notification deadlines, keeps the incident file and links breaches to the RoPA and AI systems. Try 7 days (credit card required) or book a demo.

Book a demo Try 7 days (credit card required)

Reporting a Personal Data Breach: 72-Hour Deadline, Duties and Steps

What a personal data breach is – and which duties it triggers

Who must inform whom, and when?

What goes into the notification and the communication

Notification check with 72-hour calculator

Ten data breaches and who to notify

Data breaches in AI systems – and incidents under the AI Act

Typical AI data breaches

Vendor as processor

Serious incidents under Art. 73 AI Act

Deployer duties

Two registers, two deadlines

Prevention

Handling a data breach in 7 steps

Detect and report internally

Record the time

Contain

Assess the risk

Notify

Fix and follow up

Document and learn

What to do if the 72 hours have already passed

Six mistakes with data breaches

Deadline counted from Monday

Not notified, not documented

Waiting for complete information

Providers without a reporting chain

Risk assessed from the company's view

Encryption without evidence

Data breaches in SimpleAct

Data breach or AI incident?

Frequently asked questions about data breach notification

Sources and status

Changes

Related topics

Keep track of the 72 hours, weekends included