The moment a WordPress site admin notices a suspicious export of the wp_users table, or an ecommerce team spots unauthorized database queries pulling customer records, the GDPR data breach notification clock is already running – whether anyone has hit “report” yet or not. Article 33 of the GDPR gives controllers 72 hours from the point of awareness to notify their supervisory authority, and getting that window wrong – either by missing it or by misjudging when it started – is one of the more expensive mistakes a website operator can make.
The 72-Hour Clock: When It Actually Starts
The clock does not start when the breach happened. It starts when the controller becomes “aware” of it, which the European Data Protection Board (EDPB) defines as having a reasonable degree of certainty that a security incident occurred and personal data was compromised. That distinction trips up a lot of teams.
If a SOC analyst sees anomalous outbound traffic at 2am but it takes the incident response team until 11am to confirm customer records were actually exfiltrated, the 72 hours generally starts at the point of reasonable confirmation – not at the first alert. Regulators like Ireland’s DPC and the UK’s ICO have both pushed back on organizations that tried to stretch this definition to buy extra time. Documentation matters here: timestamped logs showing exactly when suspicion turned into confirmation are what hold up if a regulator later asks why notification took 68 hours instead of 24.
What Article 33 Requires You to Report
The notification to the supervisory authority isn’t a one-line email. Article 33(3) requires, at minimum: the nature of the breach including categories and approximate number of data subjects and records affected, the name and contact details of the data protection officer or another contact point, the likely consequences of the breach, and the measures taken or proposed to address it and mitigate harm.
If you don’t have all of that within 72 hours – which is common, since forensic scoping takes time – Article 33(4) explicitly allows phased reporting. You notify with what you know, then follow up “without undue further delay.” Regulators consistently say they’d rather receive an incomplete but timely notification than a complete one that’s late. A CNIL enforcement case against a mid-sized French retailer in 2022 turned partly on the fact that the company waited for a full forensic report before notifying at all, missing the 72-hour window by 11 days.
When Affected Individuals Must Be Told Too
Article 34 sets a separate, higher bar. You only need to notify the individuals themselves when the breach is likely to result in a “high risk” to their rights and freedoms – think exposed passwords, financial data, health records, or government ID numbers, not a leaked marketing newsletter list. There’s no fixed 72-hour deadline for this step, but the standard is “without undue delay,” and regulators interpret that narrowly when the risk is severe.
Exemptions exist. If the exposed data was properly encrypted with keys that weren’t compromised, or if you’ve taken subsequent measures that eliminate the high risk, you may not need to notify individuals directly. A public communication can also substitute for individual notices when direct contact “would involve disproportionate effort” – for example, a breach affecting millions of anonymous newsletter subscribers with no reliable contact method.
A Realistic Timeline From Detection to Notification
Picture a mid-sized ecommerce site running WooCommerce. At 09:14 on a Tuesday, automated monitoring flags unusual admin-ajax.php requests. By 10:30, the security team confirms a plugin vulnerability allowed unauthenticated access to an export endpoint, and logs show roughly 14,000 customer records – names, emails, hashed passwords, partial payment tokens – were pulled between Sunday night and Tuesday morning.
That 10:30 confirmation is the awareness point. The 72-hour deadline to notify the supervisory authority lands Friday at 10:30. Internally, the team should be doing containment (patching the plugin, rotating admin credentials, invalidating sessions) in parallel with drafting the regulator notification, not sequentially. Because payment tokens and password hashes were involved, this clears the bar for Article 34 individual notification as well, typically sent within a few days of the regulatory filing once the scope is confirmed. Teams that have a documented runbook – covering who owns detection, who drafts the DPA notification, and who signs off – consistently hit these windows; teams improvising under pressure usually don’t.
Common Mistakes That Blow the Deadline
Three patterns show up repeatedly in post-incident reviews. First, waiting for a complete forensic picture before filing anything, when partial notification with a follow-up commitment is exactly what Article 33(4) anticipates. Second, treating “awareness” as the date the breach technically occurred rather than the date it was reasonably confirmed, which either wastes time arguing the point later or causes teams to file too early on unconfirmed suspicion. Third, no one owning the decision – security finds the issue, legal wants more certainty, and by the time there’s agreement on wording, day four has already passed.
A fourth, quieter mistake: assuming a scanner or monitoring tool will surface a breach in time to matter. Detection speed is the whole game here, since the 72 hours starts counting the moment you know, and a vulnerability sitting unpatched and unnoticed for months does nothing but delay that awareness date while data keeps leaking. Continuous scanning and a documented incident response runbook shrink the gap between “something happened” and “we know exactly what happened,” which is the gap that actually determines whether you make the deadline.
Busting the Myth That GDPR Fines Are Automatic
A persistent misconception is that missing the 72-hour window triggers an automatic fine. It doesn’t. Supervisory authorities weigh the delay against mitigating factors: how quickly you contained the breach, whether you cooperated fully once you did notify, and whether the delay caused additional harm. A company that self-reports at hour 90 with full transparency and a clear remediation plan is treated very differently from one that only notifies after a journalist or the regulator itself finds out. The fines that make headlines – up to €20 million or 4% of global annual turnover – tend to follow cases with willful concealment or repeated negligence, not a good-faith 6-hour overshoot on a complex incident.
Frequently Asked Questions
Does the 72-hour deadline include weekends and holidays?
Yes. The GDPR gives no exception for non-business days, so a breach confirmed at 4pm Friday still has a notification deadline of 4pm Monday, regardless of office hours or bank holidays in between.
What happens if my breach involves users in multiple EU countries?
You notify the supervisory authority in the member state of your main establishment under the one-stop-shop mechanism, which then coordinates with other affected authorities. If you have no main EU establishment, you may need to notify each relevant authority separately.
Do breaches of hashed or encrypted data still need reporting?
Often to the regulator, yes, since Article 33 covers any breach of personal data regardless of encryption status. Whether you also need to notify individuals under Article 34 depends on whether the encryption meaningfully prevented the data from being usable by an attacker.
Getting breach notification right starts long before an incident – with logging good enough to establish an accurate awareness timestamp, a clear internal owner for the notification decision, and monitoring that keeps site vulnerabilities from turning into confirmed breaches in the first place. Reviewing your current GDPR security requirements and pairing them with reliable alerting for incident response is the practical starting point for making sure the 72 hours are actually usable, not eaten up by confusion about what happened.