Articles 33 and 34 of GDPR impose two distinct notification obligations following a personal data breach: notification to the supervisory authority (Article 33) and, in higher-risk cases, notification to the affected individuals (Article 34). The 72-hour rule under Article 33 is one of the most operationally demanding compliance obligations in GDPR — it requires a rapid triage, assessment, and documentation process that most organisations discover they are not ready for at the moment they first need it.
Breach notification is also the compliance area most likely to bring an organisation to the attention of a DPA it has never interacted with before. A breach that is handled well — detected promptly, assessed accurately, notified within the deadline, and followed by a thorough remediation — is far less likely to generate a significant regulatory outcome than a breach that is discovered late, under-assessed, or reported with inaccurate or incomplete information.
What Is 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. It covers not only cyberattacks and data theft, but also internal errors — emails sent to the wrong recipient, unencrypted laptops left on trains, accidental deletion of data, and processing errors that expose data to unauthorised internal parties.
BREACH TYPOLOGY — CATEGORIES AND EXAMPLES
| Breach Type | Definition | Examples |
|---|---|---|
| Confidentiality breach | Unauthorised or accidental disclosure of personal data | Ransomware with data exfiltration; phishing leading to account takeover; email sent to wrong recipient; USB device left in public place; accidental public exposure of private data |
| Integrity breach | Unauthorised or accidental alteration of personal data | Data corrupted by system error; records altered by unauthorised internal user; database modification by attacker without deletion |
| Availability breach | Accidental or unauthorised loss of access to, or destruction of, personal data | Ransomware encryption without exfiltration; accidental deletion without backup; hardware failure with no recovery; DDoS preventing access to personal data system |
A breach does not need to involve external attackers or malicious intent. The most common breaches by volume are internal errors: misdirected emails, accidental data deletions, misconfigured cloud storage buckets left publicly accessible, and paper records disposed of without shredding. All of these qualify as personal data breaches under GDPR’s definition and must be assessed against the notification threshold.
The Notification Threshold: Not All Breaches Require DPA Notification
Article 33(1) requires notification to the supervisory authority unless the breach is ‘unlikely to result in a risk to the rights and freedoms of natural persons.’ This threshold assessment is the critical decision point in every breach response. It requires a genuine risk assessment — not an assumption that every breach is low risk and therefore does not require notification, and not a reflexive decision to notify every incident regardless of risk. Both errors cause problems.
BREACH RISK ASSESSMENT FACTORS
| Factor | Higher Risk | Lower Risk |
|---|---|---|
| Type of data breached | Special category data (health, biometric, racial origin, etc.); financial data; login credentials; data about children | Contact details only; publicly available data; data with no sensitive content |
| Volume of records affected | Large-scale breach affecting thousands or millions of individuals | Single individual; small number of individuals with limited data |
| Nature of breach | External attack; intentional internal disclosure; data exfiltrated and confirmed misused | Accidental internal access quickly contained; misdirected email to a known, trusted recipient who confirms deletion |
| Identifiability of individuals | Full identifiers allowing easy re-identification; data linked to other available datasets | Pseudonymised or partially anonymised data making identification difficult without additional effort |
| Sensitivity of context | Medical, financial, legal, or HR data where exposure causes disproportionate harm | Non-sensitive professional data; data not meaningful out of context |
| Nature of the recipient (if unauthorised disclosure) | Unknown external parties; parties with known hostile or commercial interest in the data; attackers | Internal colleague who already had similar access; trusted third party who immediately confirmed deletion |
| Potential for harm | Identity fraud; financial loss; physical harm; discrimination; reputational damage; impact on employment or housing | Minimal harm likely even in worst-case scenario; data not actionable by a third party |
| KEY IDEA | The EDPB’s guidelines on breach notification (WP250, rev.01) provide a useful risk categorisation framework: ‘negligible risk’ (no notification required); ‘risk’ (DPA notification required); ‘high risk’ (both DPA and individual notification required). The risk categorisation must be based on documented assessment, not assumption. A finding of ‘negligible risk’ that turns out to be wrong after facts emerge is far better defended if the assessment was thorough and documented at the time. |
The 72-Hour Clock: Understanding the Timeline
The 72-hour notification deadline begins when the controller becomes ‘aware’ of the breach. ‘Aware’ means that the controller has a reasonable degree of certainty that a breach has occurred — not that all facts are known. The EDPB has clarified that a processor that becomes aware of a breach must notify the controller without undue delay; and then the 72-hour clock for the controller’s DPA notification begins from when the controller is informed, not from when the processor first detected the incident.
72-HOUR NOTIFICATION TIMELINE
| Hour Range | Activity | Key Requirement |
|---|---|---|
| 0–12 hours | Incident detected; initial triage; security team engaged; containment measures initiated; DPO / privacy team notified | Do not delay DPO notification pending full investigation; clock starts at initial awareness, not at conclusion of investigation |
| 12–36 hours | Preliminary assessment of data affected; breach type classified (confidentiality/integrity/availability); initial risk categorisation; decision on whether notification is required | Risk assessment documented even if finding is no notification required; all-facts-not-known notification can still be submitted at this stage |
| 36–72 hours | DPA notification prepared if required; notification submitted via DPA’s official channel; breach register entry created; all available information included | If not all information available, submit what is known; indicate information to follow; do not delay notification waiting for complete picture |
| 72 hours + | Update notification with additional facts as investigation progresses; Article 34 individual notification decision; post-incident review initiated | Follow-up information sent to DPA as part of same notification reference; individual notification issued if high risk confirmed |
Article 33(1) includes an important caveat: notification should be made ‘without undue delay and, where feasible, not later than 72 hours after having become aware.’ The EDPB has clarified that ‘where feasible’ does not provide a blanket extension — it acknowledges only that in exceptional circumstances, notification may arrive after 72 hours with an explanation of the delay. Routine failure to meet the 72-hour deadline because the incident response procedure is inadequate is not ‘infeasible’ — it is a compliance failure.
DPA Notification Content Requirements
Article 33(3) specifies the minimum content of a DPA breach notification. Where all information is not available within 72 hours, the EDPB allows phased notification: submit what is known, indicate the outstanding information, and provide updates as the investigation progresses. The most important thing is to start the notification process within the deadline — not to delay notification while assembling a complete picture.
ARTICLE 33(3) — MANDATORY NOTIFICATION CONTENT
| Required Element | What to Include | Common Omission |
|---|---|---|
| Nature of the breach | Type of breach (confidentiality, integrity, availability); how it occurred; whether it was an attack or internal error | Vague description (‘security incident’) without specifics of how breach occurred |
| Categories and approximate number of data subjects | Types of individuals affected (customers, employees, children, etc.); estimated number of individuals | Underestimating scale; failing to update when further investigation increases count |
| Categories and approximate number of records | Types of personal data involved (contact data, health data, financial data, etc.); approximate number of records | Listing only obvious data types; omitting associated metadata or indirect personal data |
| Name and contact details of DPO | DPO’s name; direct contact details for DPA to use during investigation | Providing general [email protected] address rather than DPO’s direct contact |
| Likely consequences of the breach | What harm may result to data subjects; risk to rights and freedoms; potential for misuse of data | Generic ‘potential harm to individuals’ with no analysis of specific likely consequences |
| Measures taken or proposed | Containment measures already implemented; ongoing investigation steps; remediation planned or underway | Describing only technical containment; omitting individual communication plans or legal claims monitoring |
Individual Notification Under Article 34
Where a breach is likely to result in a high risk to the rights and freedoms of individuals, Article 34 requires communication to the affected data subjects. The threshold is higher than the DPA notification threshold — ‘high risk’ rather than ‘risk’. The notification must be made ‘without undue delay’ — not within a fixed deadline, but as quickly as is practicable after the high risk assessment is confirmed.
ARTICLE 34 EXEMPTIONS FROM INDIVIDUAL NOTIFICATION
| Exemption | Condition | Practical Application |
|---|---|---|
| Encryption or equivalent technical protection | Data rendered unintelligible to any person not authorised to access it (e.g. properly encrypted data; attacker has ciphertext but no key) | Stolen encrypted laptop where key is not also compromised; encrypted database credentials without decryption key |
| Subsequent protective measures | Controller has taken measures that ensure high risk to data subjects is no longer likely to materialise | Attacker’s access promptly revoked before data could be exfiltrated; stolen data recovered before it could be misused |
| Disproportionate effort | Notifying individuals would involve disproportionate effort; public communication or equivalent must be used instead | Large-scale breach with insufficient contact details to notify all individuals; public announcement required as substitute |
The Breach Register: Documenting Non-Notified Breaches
Article 33(5) requires controllers to document all personal data breaches, regardless of whether they are notified to the DPA. Non-notified breaches — those assessed as below the notification threshold — must be recorded in the breach register with sufficient detail for the DPA to verify, on inspection, that the no-notification decision was justified. The breach register is not just an administrative record; it is the accountability mechanism for breach response decisions.
BREACH REGISTER — MINIMUM FIELDS PER ENTRY
| Field | Content |
|---|---|
| Incident date and discovery date | Date of the breach event (if known); date organisation became aware |
| Breach type | Confidentiality, integrity, or availability; how the breach occurred |
| Data categories and records affected | Types of personal data; estimated number of data subjects and records |
| Risk assessment | Risk categorisation (negligible / risk / high risk); reasoning; factors assessed; conclusion |
| Notification decision | Notified to DPA (yes/no); if no, why not; date of notification if submitted |
| Individual notification | Individual notification issued (yes/no); if no, why not; date if issued; channel used |
| Containment and remediation measures | Technical and organisational measures taken to contain and remediate |
| Post-incident review | Root cause identified; lessons learned; controls updated; review completed date |
| Handler and sign-off | Who conducted the assessment; DPO sign-off; date record completed |
| BITLION INSIGHT | The most common breach notification failures are not about missed deadlines on genuinely complex incidents — they are about organisations that did not have an incident detection and response process in place, discovered a breach weeks after it occurred, and then faced both a late notification and an accountability gap. Building an incident response procedure that — at minimum — defines what constitutes a breach, identifies who must be notified internally within what timeframe, designates a breach response lead, and requires DPO involvement in every risk assessment, is the foundation that makes timely notification possible. Without that infrastructure, the 72-hour clock is always going to be missed. |