GDPR data breach notification requirements can feel deceptively simple: “report within 72 hours.” In practice, teams struggle with two questions: when the clock starts and what actually has to be reported (and documented) under pressure.
This guide explains what the GDPR 72-hour rule really means, how to decide whether you must notify the supervisory authority under Article 33, when you must also inform affected individuals (Article 34), and what records you should keep even when no notification is made.
What counts as a “personal data breach” under the GDPR?
A personal data breach is more than hacking. It is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
In plain terms: if personal data is compromised in confidentiality, integrity, or availability, you may have a personal data breach.
Common breach scenarios (not just cyberattacks)
Many reportable incidents are operational mistakes rather than sophisticated attacks. Examples include:
- Confidentiality breaches: misdirected emails containing customer data, an exposed database, stolen laptop with unencrypted files, inappropriate internal access.
- Integrity breaches: unauthorized changes to HR records, malware altering customer contact details, data corruption that changes the content of personal data.
- Availability breaches: ransomware encrypting files, accidental deletion without backups, a cloud outage that permanently loses data needed to provide a service.
Not every security incident is a personal data breach. For example, malware on a machine that contains no personal data may be a security issue but not a GDPR personal data breach.
Article 33 in practice: When notification is required
Article 33 requires controllers to notify the relevant supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. You can read the legal text in the text of GDPR Article 33 on EUR-Lex.
That “risk to rights and freedoms” threshold is the key. The decision is not based on embarrassment, media interest, or whether an attacker was “sophisticated.” It is based on likely impact to individuals.
How to assess “risk to rights and freedoms”
A practical risk assessment usually considers:
- Type of data: IDs, financial data, health data, location data, credentials, special category data.
- Volume and scope: number of people affected, data breadth per person, and whether vulnerable individuals are involved.
- Ease of identification: fully identifiable data vs. pseudonymized or strongly encrypted.
- Potential harm: identity theft, fraud, discrimination, physical harm, distress, loss of confidentiality (e.g., sensitive communications).
- Who obtained it: trusted recipient under NDA vs. unknown actor; evidence of exfiltration or misuse.
- Mitigation steps: rapid containment, revoking access, resets/rotation of credentials, confirmed deletion by recipient.
Document your reasoning either way. Under GDPR data breach notification requirements, the “why” matters as much as the “what.”
The GDPR 72-hour rule: What it really means
The 72-hour window is not “72 hours from the incident.” It is 72 hours from when the controller becomes aware that a personal data breach has occurred.
When are you “aware” of a breach?
You are generally considered aware when you have a reasonable degree of certainty that a security incident has compromised personal data. You do not need perfect information, a completed forensic report, or a confirmed attacker identity.
Examples:
- Awareness likely starts: you confirm a database was publicly accessible and contained customer records; an employee reports sending sensitive data to the wrong external recipient; logs show unauthorized access to a system holding personal data.
- Awareness may not start yet: you receive a vague alert with no evidence personal data was involved and you have not confirmed impact despite reasonable checks.
Can you submit an initial notification and follow up later?
Yes. If you cannot provide all details within 72 hours, you should still notify within the deadline with the information available and then provide additional details in phases as your investigation progresses.
If you notify after 72 hours, you must explain the reasons for the delay. Treat the deadline as an operational requirement: build an incident workflow that can produce a defensible initial report quickly.
What must be included in a notification to the supervisory authority?
In a typical Article 33 notification, you should be ready to communicate:
- What happened: the nature of the breach (confidentiality/integrity/availability), affected systems, and high-level timeline.
- Who is affected: categories of individuals and approximate number of data subjects.
- What data is involved: categories and approximate number of personal data records.
- Likely consequences: anticipated risks and potential harms to individuals.
- Measures taken or proposed: containment, remediation, and steps to reduce adverse effects.
- Point of contact: DPO or another contact for follow-up questions.
Even when information is incomplete, stating what is known, what is unknown, and what you are doing to find out is usually better than waiting.
Article 34: When you must notify affected individuals
Notifying the regulator and notifying individuals are different obligations. Article 34 generally requires you to inform affected individuals without undue delay when a breach is likely to result in a high risk to their rights and freedoms. The legal wording is available in the text of GDPR Article 34 on EUR-Lex.
What “high risk” looks like
High risk typically involves a meaningful chance of real-world harm. Common triggers include exposed login credentials, financial data, identity documents, sensitive health details, intimate communications, location data, or data about children.
High risk can also arise when the breach affects a large number of people, when the data enables easy impersonation, or when the attacker is likely to misuse the data.
What your notice to individuals should contain
A good individual notice is clear, actionable, and honest. It commonly includes:
- What happened and when you found out (in plain language).
- What information was involved (categories, not unnecessary technical detail).
- What you have done to secure systems and reduce risk.
- What they can do to protect themselves (password reset, monitoring accounts, phishing awareness, contacting banks, etc.).
- How to contact you (DPO/privacy contact and support channels).
If contacting each individual would involve disproportionate effort, a public communication may be acceptable in some cases, but you should treat that as a last resort and document why direct notice is not feasible.
What you must document (even if you don’t notify)
One of the most overlooked GDPR data breach notification requirements is the record-keeping duty. You must document personal data breaches regardless of whether they are reported to the authority.
In practice, your breach register (or incident record) should capture:
- Incident summary: what occurred, how it was detected, and key dates/times (detection, awareness, containment).
- Systems and data: affected assets, data categories, number of individuals/records (estimated if necessary).
- Risk assessment: rationale for “risk” vs. “unlikely risk,” and “high risk” vs. “not high risk.”
- Notification decisions: whether/when you notified the authority and individuals; what you submitted; reasons for any delay.
- Mitigation actions: containment, patching, credential resets, recipient deletion confirmation, monitoring steps.
- Lessons learned: root cause, control gaps, and preventive measures with owners and deadlines.
This documentation should be detailed enough that your organization can justify its decisions later to a regulator, auditors, or internal stakeholders.
Controllers vs. processors: Who notifies whom?
Controllers hold the legal obligation to notify the supervisory authority and (when required) affected individuals. Processors generally must notify the controller without undue delay after becoming aware of a breach.
To make that workable, your contracts and incident response playbooks should specify:
- Processor reporting timelines (often much shorter than 72 hours).
- Information the processor must provide (impact scope, logs, remediation steps).
- Support obligations for investigation, containment, and communications.
A practical 72-hour workflow you can actually execute
The biggest operational mistake is treating breach notification as a purely legal task. It is an incident-response process with legal outputs. A simple workflow:
0–12 hours: Triage and containment
- Confirm whether personal data is involved and secure evidence.
- Stop ongoing access/exfiltration (disable accounts, rotate credentials, isolate systems).
- Start a breach log with timestamps and decision owners.
12–36 hours: Scope and risk assessment
- Identify affected systems, data categories, and likely number of people/records.
- Assess risk to individuals (including special category data and credential exposure).
- Decide whether Article 33 notification is required; draft an initial report.
36–72 hours: Notify (if required) and prepare follow-ups
- Submit the initial notification to the supervisory authority with available facts.
- Prepare phased updates as investigation continues.
- If high risk, draft and send the communication to affected individuals without undue delay.
Assign clear roles (security, privacy/legal, comms, customer support) so decisions can be made quickly and consistently.
Examples: Is this likely reportable?
Example 1: Misdirected email with payroll attachment
If an employee emails an unencrypted payroll file to an unintended external recipient, this is a personal data breach. Notification depends on risk: if the file includes national IDs, bank details, or salary information, risk is often more than “unlikely,” making Article 33 notification more likely. If the recipient confirms secure deletion immediately and the file was encrypted with a separate channel for the password, risk may be reduced, but you should still document the incident thoroughly.
Example 2: Lost laptop with full-disk encryption
A lost device containing personal data can be a breach, but strong encryption may mean the breach is unlikely to result in risk (depending on key management and whether the device was actually accessed). In that case, you may not need to notify the authority, but you still need a documented risk assessment and incident record.
Example 3: Credential stuffing exposes customer accounts
If attackers take over accounts and access order history, addresses, or saved payment tokens, the confidentiality breach can present risk to individuals. Regulators often expect rapid containment (forced password resets, MFA rollout) and careful consideration of notifying both the authority and impacted customers, especially if phishing or fraud is likely.
Common pitfalls that cause late or incomplete notifications
- Waiting for certainty: the 72-hour window expects imperfect early information and phased updates.
- No clear “awareness” trigger: establish who can declare a personal data breach and start the clock.
- Missing processor escalation paths: late processor notice can consume your entire deadline.
- Poor data mapping: if you cannot quickly identify what data is in a system, scoping takes too long.
- Not documenting non-notification decisions: regulators can ask why you didn’t report.
FAQs
Does the 72-hour rule include weekends and holidays?
Yes. The GDPR refers to hours, not business days. Plan for weekend coverage, on-call rotations, and pre-approved decision pathways.
What if we don’t know the number of affected people within 72 hours?
Notify with estimates and clearly state that figures are provisional. Continue investigating and provide updated numbers as soon as practicable.
If data was encrypted, do we still need to notify individuals?
Strong encryption that is not compromised can significantly reduce risk, which may mean individual notification is not required. The answer depends on whether the encryption is robust, keys are protected, and there is any evidence of misuse.
Do we have to notify every incident to the supervisory authority?
No. Notification is required when the breach is likely to result in risk to individuals. However, you must keep internal documentation for every personal data breach, including those you decide not to report.
Can a processor notify the supervisory authority instead of the controller?
In general, the controller is responsible for notifying the authority and affected individuals. A processor’s primary duty is to inform the controller without undue delay and provide the information needed for the controller’s notification.
Quick checklist: Meeting GDPR data breach notification requirements
- Define what qualifies as a personal data breach for your organization.
- Set an “awareness” trigger and an escalation path that starts the 72-hour clock.
- Maintain a breach register with risk assessments and decisions.
- Prepare templates for Article 33 regulator notices and Article 34 customer/employee notices.
- Test the process with tabletop exercises and update it after real incidents.
When your process is built around fast triage, documented risk assessment, and phased reporting, the 72-hour requirement becomes manageable—and your communications become clearer for regulators and the people you serve.
