GDPR: Implementing the Data Breach Notification Process in Practice

1. What counts as a notifiable data breach

A data breach under GDPR occurs whenever personal data is unlawfully disclosed, altered, deleted, or made inaccessible, regardless of whether it was triggered by an external attack, an internal mistake, or a technical failure. A misaddressed email attachment with customer data falls under this just as much as a compromised database server or a ransomware attack that encrypts data without stealing it, making it inaccessible rather than exposed.

Under Article 33 GDPR, such a breach must be reported to the supervisory authority whenever it poses a risk to the rights and freedoms of the affected individuals. Cases where that risk can be demonstrably ruled out are not notifiable, for instance when the affected data was consistently strongly encrypted and the key was demonstrably not compromised. In practice, this exception is interpreted narrowly and must never be used as a default excuse to avoid reporting.

2. The 72-hour deadline in detail

The clock does not start once the full extent of an incident has been clarified. It starts the moment the controller becomes aware of the breach. That awareness exists as soon as there is reasonable certainty that a security-relevant event resulted in personal data being compromised, not only after a complete forensic investigation has concluded.

Since a full investigation rarely fits within three days, Article 33(4) GDPR explicitly allows notification to happen in phases. The initial notification within the deadline can contain preliminary information and must be clearly marked as such, followed by supplementary notifications as more facts become known. This provision removes the pressure to deliver every detail immediately, while still requiring a timely first notification.

3. Approaching scope assessment technically

The central question in every notification is which categories of data, and how many affected individuals, were concretely impacted. Without meaningful logs, that question can hardly be answered reliably within 72 hours, which is why the technical groundwork has to start long before an incident occurs, not during the crisis itself.

An access log that records which account accessed which tables or records and when lets you precisely narrow down, during an actual incident, what a compromised account genuinely read or modified. Without such a log, the only remaining option is often the pessimistic assumption that all data theoretically reachable by that account may have been affected, which unnecessarily widens the notification and, in the worst case, makes it less accurate rather than more.

# Example: scoping a database access incident from structured access logs
# Assumption: every application writes access events as JSON to /var/log/app/access.log

# All accesses by the compromised service account within the relevant window
jq -c 'select(.account == "svc-reporting" and
              (.timestamp >= "2026-08-01T00:00:00Z") and
              (.timestamp <= "2026-08-03T12:00:00Z"))' \
   /var/log/app/access.log > incident-scope.jsonl

# Summarize affected tables and the number of records read
jq -s 'group_by(.table) | map({table: .[0].table, records: length})' \
   incident-scope.jsonl

# The result provides the basis for the category and scope statement
# required in the notification under Art. 33(3) GDPR

4. When data subjects must additionally be notified

Article 34 GDPR requires an additional, direct notification to the affected individuals whenever the breach is likely to result in a high risk to their rights and freedoms. This threshold is deliberately set higher than the one for notifying the supervisory authority, so not every notifiable breach automatically triggers a notification to data subjects as well.

A high risk typically exists when particularly sensitive categories of data are involved, such as health data, plaintext credentials, or payment information that enables direct harm like identity theft or financial loss. Notification can be waived if the controller can demonstrate that appropriate safeguards, such as strong encryption, rendered the data unintelligible to unauthorized parties, or if individual notification would involve disproportionate effort and a public communication is issued instead.

5. Logging as a prerequisite for a fast notification

A company that only decides which systems should write logs once an incident is already underway loses valuable time within the 72-hour deadline. It is far better to determine in advance which systems process personal data, and permanently enable a baseline level of access and change logging for exactly those systems.

What matters is not just that logging happens, but that logs themselves are stored tamper-evidently and retained for a sufficient period, usually several months. An attacker who gains access to a system frequently tries to specifically erase their own traces from the log. Central log storage, kept separate from the compromised system, prevents exactly that and provides the reliable data basis needed for scope assessment when it matters most.

6. How the GDPR notification differs from general incident response

General incident response focuses primarily on technical containment: removing an attacker from the system, fixing the root cause, and restoring normal operation. Those technical steps proceed regardless of whether personal data is involved at all, and follow their own, mostly technical priorities.

The GDPR notification process is a legal compliance process that has to run in parallel with technical incident response, but carries its own deadlines, its own responsibilities, and its own documentation requirements. A company that conflates the two processes, and only starts the notification clock after technical remediation is fully complete, will almost inevitably miss the 72-hour deadline, since a complete technical investigation usually takes considerably longer.

7. Internal reporting channels and the role of the data protection officer

For the 72-hour deadline to be achievable at all, the organization needs a clear, always-reachable internal reporting channel through which any employee can immediately escalate a suspected data breach to the right people. That channel is usually the data protection officer, who performs the legal assessment and decides whether notification is required.

In practice, a well-defined escalation team consisting of the data protection officer, the IT security lead, and executive management, one that convenes within a few hours of a suspected incident becoming known, proves its worth. Without such a predefined structure, valuable time gets lost simply figuring out who is even responsible and who is authorized to formally file the notification with the supervisory authority.

8. Documentation duty applies even without notification

Even when a controller concludes that a breach poses no risk to affected individuals and therefore does not need to be reported, Article 33(5) GDPR still requires internal documentation of every breach, including the facts, its effects, and the remedial action taken.

That documentation serves as evidence to the supervisory authority that the decision not to notify was made carefully and with proper justification, rather than as a convenient excuse to avoid effort. Without that documentation, the supervisory authority cannot later verify, during an audit, whether the decision against notification was actually substantively justified.

9. Fine risk for late or omitted notification

A violation of the notification duty itself, independent of the underlying security incident, can be sanctioned under Article 83(4) GDPR with a fine of up to ten million euros or two percent of global annual turnover, whichever is higher. Supervisory authorities assess not only whether notification happened at all, but also whether it was timely and substantively adequate.

In practice, a visibly careful, timely notification with traceable documentation of the countermeasures taken tends to reduce the eventual fine, even when the underlying incident itself was serious. A company that has thought through and rehearsed its notification process ahead of time is, in the supervisory authority's assessment, generally in a far better position than one that improvises only once the crisis hits.

10. Summary

11. FAQ: GDPR Data Breach Notification: The Essentials at a Glance