The 72-Hour Rule: How to Report a GDPR Data Breach Without Triggering Additional Penalties

A personal data breach is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Under GDPR Articles 33 and 34, how your organisation responds to a breach can be as consequential as the breach itself. Late or inadequate notification is treated as a separate infringement, often attracting its own penalty.

Understanding the 72-Hour Timeline

Article 33(1) requires the controller to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of a personal data breach. The clock starts not when the breach occurs, but when the organisation becomes aware of it. This distinction matters: a breach that occurred weeks ago but was only discovered today triggers the 72-hour obligation from the moment of discovery.

If notification is not made within 72 hours, the controller must provide reasons for the delay. Supervisory authorities have shown limited tolerance for unsubstantiated delays. The Dutch DPA (Autoriteit Persoonsgegevens) has imposed fines specifically for late notification, treating it as a distinct violation under Article 83(4)(a).

What Constitutes a Reportable Breach?

Not every security incident requires notification to the supervisory authority. Article 33(1) qualifies the obligation: notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. This risk-based threshold means you must assess each breach individually.

The EDPB Guidelines 01/2021 on examples regarding personal data breach notification provide a useful taxonomy of reportable and non-reportable scenarios:

Likely reportable:

• Ransomware attack encrypting patient records at a hospital
• Unauthorised access to a customer database containing financial information
• Misdirected email containing employee salary data sent to an external recipient
• Stolen laptop containing unencrypted personal data
• Exfiltration of personal data by a malicious insider

Likely not reportable:

• Encrypted laptop lost or stolen where the encryption key was not compromised
• Brief power outage causing temporary inaccessibility of data with no permanent loss
• Internal misdirected email where the recipient is bound by confidentiality obligations and confirms deletion

When in doubt, err on the side of notification. Supervisory authorities are far more understanding of organisations that report a breach that turns out to be low-risk than those that fail to report a breach that later proves significant.

Notification Content Requirements

Article 33(3) specifies the minimum information that must be included in a supervisory authority notification:

1. A description of the nature of the breach, including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned.
2. The name and contact details of the Data Protection Officer or other contact point.
3. A description of the likely consequences of the breach.
4. A description of the measures taken or proposed to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

Where it is not possible to provide all information at the same time, information may be provided in phases (Article 33(4)). Many supervisory authorities accept an initial notification followed by supplementary reports as the investigation progresses.

When Must Data Subjects Be Notified?

Article 34 imposes an additional obligation to notify affected individuals directly when the breach is likely to result in a high risk to their rights and freedoms. The threshold is higher than for supervisory authority notification: high risk rather than merely risk.

Communication to data subjects must be in clear and plain language and must describe the nature of the breach, the DPO contact details, the likely consequences, and the measures taken to address the breach. Direct notification is not required where:

• The controller has implemented appropriate technical measures (such as encryption) that render the data unintelligible to unauthorised persons.
• The controller has taken subsequent measures that ensure the high risk is no longer likely to materialise.
• Individual notification would involve disproportionate effort, in which case a public communication or similar measure is permitted.

Building Your Breach Response Capability

Effective breach response is not improvised. It requires preparation, documentation, and regular testing. The following framework will help your organisation respond effectively when a breach occurs:

Step 1: Detection and Escalation

Implement technical controls (intrusion detection, log monitoring, endpoint detection) and establish clear escalation paths. Every employee should know how to report a suspected breach internally. Define a breach response team with representatives from IT, legal, communications, and senior management.

Step 2: Initial Assessment

Within hours of detection, assess the nature and scope of the breach. Determine what data was affected, how many individuals are involved, whether the breach is ongoing, and the likely impact. This assessment drives your notification decisions.

Step 3: Containment

Take immediate action to contain the breach. This may include isolating affected systems, revoking compromised credentials, blocking malicious IP addresses, or activating backup systems. Document all containment actions and their timing.

Step 4: Notification

Based on your risk assessment, prepare and submit your supervisory authority notification within 72 hours. If the breach triggers Article 34, prepare data subject communications in parallel. Use pre-prepared templates to accelerate this process.

Step 5: Investigation and Remediation

Conduct a thorough root cause analysis. Identify the vulnerability that was exploited, the controls that failed, and the measures needed to prevent recurrence. Document findings and implement remediation actions promptly.

Step 6: Post-Incident Review

After the immediate response, conduct a formal post-incident review with all stakeholders. Update your breach response procedures based on lessons learned. Submit your final report to the supervisory authority within the required timeframe.

Common Mistakes to Avoid

• Failing to recognise a security incident as a personal data breach
• Waiting for the investigation to complete before notifying the supervisory authority
• Providing incomplete or inaccurate information in the initial notification
• Neglecting to document breaches that are assessed as low-risk (Article 33(5) requires a breach register for all breaches)
• Underestimating the risk to data subjects to avoid notification obligations
• Failing to notify data subjects when the high-risk threshold under Article 34 is met

The 72-hour notification window is tight, but organisations that prepare in advance (with documented procedures, template notifications, and a trained breach response team) can meet this obligation consistently. The cost of preparation is negligible compared to the penalties and reputational damage that follow a poorly managed breach response.