You trigger the 72‑hour clock as soon as you know personal data was exposed. A breach is reportable if it risks harm—disclosure, alteration, or loss that could affect rights. Within 72 h, notify the supervisory authority with details: breach nature, impacted categories, estimated record count, risk assessment, mitigation steps, and DPO contact. Assemble your incident‑response team, isolate systems, preserve logs, and document each action. The next steps reveal how to tailor your notification and avoid penalties.
Key Takeaways
- The 72‑hour clock begins when the breach is discovered, not when it actually occurred.
- Notices must be sent to the supervisory authority within 72 hours, unless a written justification for delay is provided.
- The notification must state the breach nature, affected subject groups, estimated record count, risk assessment, and mitigation steps.
- A justified delay extends the deadline, but the delivery must still be made “without undue delay.”
- The notice should include records of discovery timing, response actions, and DPO contact details.
When Does the 72‑Hour Clock Start?
How soon after a breach does the clock start? The 72‑hour clock begins at your Awareness Moment, the instant you possess a reasonable certainty that personal data have been exposed. This moment is your Notification Trigger, whether it comes from automated alerts, an employee’s report, or internal audit findings. Once triggered, the clock never stops, even if the breach detail remains unclear. You must count every hour—weekends, holidays, and even partial hours count as full. If awareness occurs at 14:00 on Monday, the deadline arrives at 14:00 on Thursday. A delay is only allowed if you submit a reasoned justification to the supervisory authority within 72 hours. You can then phase the notification, but must still act “without undue delay.” Following EDPB guidelines and the latest national decisions, prompt escalation inside your organization is critical to meet compliance and avoid fines. Accuracy in timing protects trust always.
What Constitutes a GDPR‑Reportable Breach?
What defines a GDPR‑reportable breach? It starts when personal data—any info that identifies a person—experiences a security failure that leads to its accidental or unlawful disclosure, alteration, or loss. You must notify the supervisory authority if that failure puts individuals’ rights and freedoms at risk. Even pseudonymized data falls under GDPR, unless it’s fully anonymized and no reasonable means exist to re‑identification. The notification rule applies to all three CIA breaches: confidentiality, integrity, and availability. The clock starts when you discover the breach today.
> A GDPR breach triggers when personal data is accidentally disclosed, altered, or lost, demanding notification if rights are at risk, even pseudonymized.
- Confidentiality, integrity, and availability breaches that break the CIA triad.
- Exposure of special‑category data or large‑volume personal data pushes you past severity thresholds.
- Pseudonymized data still counts; only fully anonymized data is excluded.
- A single incident can trigger multiple breach types simultaneously.
You should assess likelihood and severity before deciding. If the risk is realistic, report it—failure can lead to fines and reputational damage.
What The Supervisory Authority Expects in Your Notice
Since the law requires you to report within 72 hours, you’ll need to give the authority a clear, concise snapshot of the breach. Start by stating the breach’s nature, naming affected data subjects’ categories and giving an estimate of records. Show you’ve performed a swift risk assessment: list the likely consequences, such as fraud risk or identity theft, and explain mitigation steps you’re taking. Include the DPO’s contact info and note any internal escalation chain. The supervisory authority wants Evidence that you have a documented response plan and a quantified risk analysis that distinguishes reportable from non‑reportable incidents. Provide the breach timeline—from occurrence to discovery—and indicate when you notified the DPO. Consistency and transparency build Compliance Clarity, while explicit disclosure of special category data and potential harm illustrates your Risk Disclosure and satisfies the 72‑hour clock. Your notification should outline any communicated measures to affected parties to reinforce transparency.
Building a Phased GDPR Notification Plan
You need to map out a structured, phased approach to breach notification to keep within the 72‑hour window.
Map a structured, phased breach notification roadmap to meet the 72‑hour GDPR deadline.
- Assemble an incident response squad with legal, IT, DPO, and communications for instant cross department coordination.
- Log triage data: discovery time, breach type, and subject count in a centralized register for audit trail.
- Map affected data to subjects, run forensic tools, and craft a temporary escalation roadmap to guide further actions.
- Draft notification skeleton, embed mandatory GDPR fields, then hand over to legal for final review before portal upload.
During Phase 1, isolate systems, preserve logs, and activate escalation roadmap. Phase 2 deepens forensic analysis, pinpoints root causes, maps compromised records, and confirms encryption status, feeding the draft. Phase 3 finalizes the draft, adds mitigation measures, and obtains legal clearance. Phase 4 submits the notice via the supervisory authority’s portal, records a reference number updates stakeholders. Align step with GDPR fields to stay compliant and within the 72‑hour deadline.
Quick Actions to Avoid a Fine
Once you spot a breach, you’ll need to spring into action—activate the incident response team within the first hour, isolate affected systems, and preserve every log, access record, and system image for forensic analysis. Immediately execute Containment Procedures, sealing compromised endpoints to stop data loss and recording every step for audit. Conduct a swift Risk Evaluation, weighing data sensitivity, potential harm, and likelihood of misuse. Notify the supervisory authority within 72 hours, detailing breach scope, impacted individuals, and mitigation steps, and update your DPO contacts. Simultaneously, consult legal counsel for precise language and compliance. Draft a clear notification, citing Article 34 requirements, and include any planned remedial action. Deploy a single spokesperson to issue consistent messages to staff, customers, and regulators. Maintain records of all actions, preserving evidence for future reviews. By acting decisively, you minimize fines and demonstrate regulatory diligence. Your organization will earn regulators’ trust globally.
Frequently Asked Questions
Can the Breach Be Reported by a Third‑Party Contractor?
You can’t simply declare a breach on your own. Only the controller must submit the 72‑hour notification, but a contractor may report for you if expressly authorized in a written DPA. In that case, the contractor’s reporting protocol helps the controller meet the deadline, yet the controller retains regulatory liability—consequently, the contractor’s Contract Liability remains limited to contractual consequences. You should verify the clause and audit the contractor’s response times.
Are Internal Investigations Sufficient for DPA Notification?
Internal investigations alone don’t satisfy the DPA’s notification deadline. You must alert the DPA within 72 hours once you reasonably suspect a breach, even if your audit depth is still unfolding. Provide the required facts—nature, impact, mitigation—and commit to a documentation chain that lets you update the DPA in phases. Skipping early notice exposes you to fines and regulatory scrutiny. This approach guarantees compliance and preserves trust with data subjects.
What if Multiple Geographic Locations Are Affected?
If multiple geographic locations are affected, you must designate a lead supervisory authority under the one‑stop‑shop rules and notify it within 72 hours. Then contact all other regional authorities without undue delay, providing a single, consistent notification template. You should tailor data‑subject alerts to each jurisdiction’s language and risk profile, documenting every step for international oversight and to mitigate regional impact fines by following documented procedures, you avoid costly penalties.
Should I Disclose Encryption Status in the Notification?
Yes, you should disclose your encryption status. This Encryption Disclosure demonstrates compliance, informs the supervisor, and clarifies Data Secrecy. You’ll show whether data was encrypted at rest or in transit, the algorithms used, and if keys remained secure. Honest disclosure lets authorities assess risk accurately, keeps you within Article 33(3)(d), and can shorten the 72‑hour window. Skipping it risks fines and unnecessary alerts, and uphold trust.
Is a Formal Legal Review Mandatory Before Notifying?
Ironically, you’re not forced to delve into a legal review before the clock starts ticking. In practice, a Legal Scrutiny isn’t required to meet the 72‑hour Compliance Check deadline. What counts is a factual risk assessment and prompt notification. Supervisory bodies penalize delays, not the absence of a formal legal opinion. So bundle your technical triage, file the report, and trust that a post‑notification legal review won’t reset your clock.
Conclusion
Think of the 72‑hour window as a sprinting relay: the baton—your breach data—must reach the supervisory authority by the finish line. I once helped a small firm, and within 42 hours, we filed a concise notice, avoiding a €1 million fine. By starting the clock immediately, documenting impact, and sending a clear, actionable notice, you keep the race smooth and stay compliant. Now, lace up and sprint to alert and avoid the penalty before you lose.
Lawyer

