Breach Notification Requirements

Personal data breaches are inevitable. No matter how robust your security measures, incidents will occur — a misdirected email, a stolen laptop, a ransomware attack, or a misconfigured database. What the GDPR demands is not perfection, but preparedness: the ability to detect breaches promptly, assess their severity, and notify the right people within strict timeframes.

What Constitutes a Personal Data Breach

Article 4(12) defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed."

This definition is deliberately broad. Breaches fall into three categories:

• Confidentiality breach — unauthorised or accidental disclosure of, or access to, personal data. Example: an employee emails a spreadsheet of customer details to the wrong recipient.
• Integrity breach — unauthorised or accidental alteration of personal data. Example: a database error corrupts medical records.
• Availability breach — accidental or unauthorised loss of access to, or destruction of, personal data. Example: a ransomware attack encrypts your HR database and you have no backup.

A breach does not require malicious intent. Accidental incidents — sending a letter to the wrong address, losing an unencrypted USB drive, or a server failure that permanently destroys records — all qualify.

The 72-Hour Rule (Article 33)

When a personal data breach occurs, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach.

What "Awareness" Means

The clock starts when your organisation has a reasonable degree of certainty that a security incident has occurred which has compromised personal data. This does not require a full forensic investigation — once you have enough information to conclude that a breach has likely happened, you are "aware."

Key guidance from the European Data Protection Board (EDPB):

• A controller is considered "aware" once any employee, officer, or agent with responsibility for data security discovers the breach — not when a senior manager is eventually informed.
• If a processor discovers the breach, they must notify the controller without undue delay (Article 33(2)). The 72-hour clock then starts for the controller from the moment the processor informs them.
• Organisations should have internal reporting procedures that ensure breaches reach the appropriate decision-maker immediately.

When Notification Is Not Required

Notification to the supervisory authority is not required if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. For example, if a lost device was fully encrypted with a strong key and there is no indication the encryption was compromised, the risk to individuals may be negligible.

However, you must still document the breach internally (see below), even if you decide notification is not required.

Late Notification

If you cannot notify within 72 hours, the notification must be accompanied by reasons for the delay. Partial notification is permitted — you can provide information in phases where details are not yet available, as long as you do so without further undue delay.

Content of the Authority Notification

Article 33(3) specifies what the notification must contain:

1. Nature of the breach — including, where possible, the categories and approximate number of data subjects affected, and the categories and approximate number of personal data records concerned.
2. DPO contact details — the name and contact details of the Data Protection Officer or other contact point for further information.
3. Likely consequences — a description of the likely consequences of the breach (e.g. identity theft, financial loss, reputational damage).
4. Measures taken or proposed — the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects.

Most supervisory authorities provide standard online forms. It is wise to prepare a notification template in advance so that you can act quickly when an incident occurs.

Notifying Data Subjects (Article 34)

In addition to notifying the supervisory authority, you must communicate the breach directly to the affected data subjects when the breach is likely to result in a high risk to their rights and freedoms.

"High risk" goes beyond ordinary risk. It typically applies where the breach could lead to significant harm — discrimination, identity theft, financial loss, damage to reputation, or other significant economic or social disadvantage.

What to Tell Data Subjects

The communication must describe, in clear and plain language:

• The nature of the breach
• The DPO's contact details
• The likely consequences
• The measures taken to address the breach and mitigate its effects

Exceptions to Data Subject Notification

You do not need to notify data subjects if:

1. Encryption or similar measures — you had implemented appropriate technical protection measures (such as encryption) that render the data unintelligible to any person not authorised to access it.
2. Subsequent mitigation — you have taken subsequent measures that ensure the high risk to individuals is no longer likely to materialise.
3. Disproportionate effort — individual notification would involve disproportionate effort. In this case, you must instead make a public communication or similar measure that informs data subjects equally effectively (e.g. a prominent notice on your website).

The Documentation Requirement (Article 33(5))

This is the obligation that applies to every breach, without exception. Regardless of whether the breach triggers notification to the supervisory authority or to data subjects, you must document:

• The facts relating to the breach
• Its effects
• The remedial action taken

This internal breach register serves two critical purposes: it enables the supervisory authority to verify your compliance, and it provides an institutional record that helps you learn from incidents and improve your security posture over time.

Practical tip: Document your decision-making process as well — why you determined that notification was or was not required, who was involved in the assessment, and what factors were considered. This demonstrates accountability.

Building a Breach Response Process

Effective breach management requires preparation before an incident occurs:

1. Detection — implement technical and organisational measures to detect breaches promptly (logging, monitoring, intrusion detection).
2. Escalation — define clear internal escalation procedures so that the person responsible for GDPR compliance is informed immediately.
3. Assessment — evaluate the nature, sensitivity, and volume of data affected, the severity of consequences, and the number of individuals impacted.
4. Containment — take immediate steps to contain the breach and limit further damage.
5. Notification — determine whether supervisory authority and/or data subject notification is required, and execute within the 72-hour window.
6. Documentation — record all details in your breach register.
7. Review — after the incident, conduct a post-mortem to identify root causes and implement preventive measures.

How GDPR4All Helps

GDPR4All's Breach Notification module is designed to support every stage of this process:

• Structured incident records capture all Article 33(3) required fields in a guided form.
• Automated 72-hour countdown tracks the notification deadline from the moment of discovery, with visual alerts as the deadline approaches.
• Severity classification helps you assess whether supervisory authority and data subject notification are required.
• Complete audit trail ensures every action, update, and decision is recorded for accountability purposes.
• Overdue alerts flag any breaches where the 72-hour window has passed without notification, so nothing falls through the cracks.

Summary

Breach notification under the GDPR is a structured, time-sensitive obligation. The 72-hour window is tight, which means preparation is everything. Maintain an internal breach register for every incident, have your notification templates ready, and ensure your team knows exactly who to contact and what to do when the inevitable occurs.