5.2 Personal Data Breach Notification

The Two Thresholds You Must Not Confuse

Breach notification is one of the most reliably tested topics on the CIPP/E, and almost every question hinges on two different risk thresholds. Mixing them up is the most common mistake:

• Article 33 — notify the supervisory authority when a breach is likely to result in a risk to rights and freedoms.
• Article 34 — notify the affected data subjects when a breach is likely to result in a high risk to rights and freedoms.

In short: a risk triggers the regulator notification; a high risk additionally triggers the individual notification. A personal data breach is defined in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The EDPB groups breaches into three classic types: a confidentiality breach (unauthorised disclosure/access), an integrity breach (unauthorised alteration), and an availability breach (loss or destruction of, or loss of access to, data).

Ransomware that merely locks data is still an availability breach even if nothing is exfiltrated.

Article 33: Notifying the Supervisory Authority

The controller must notify the competent supervisory authority (DPA) without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach.

Key rules:

• The 72-hour clock starts when the controller has a reasonable degree of certainty that a security incident has compromised personal data — i.e., when it becomes aware, not when the incident first happened.
• The deadline is 72 hours, not 72 working hours — weekends and public holidays count.
• If notification is not made within 72 hours, it must be accompanied by reasons for the delay (Article 33(1)).
• Notification is not required if the breach is unlikely to result in a risk to natural persons.
• Notification may be done in phases when all information is not available at once (Article 33(4)).

The notification must, under Article 33(3), describe: the nature of the breach including categories and approximate numbers of data subjects and records affected; the name and contact details of the DPO or other contact point; the likely consequences; and the measures taken or proposed to address it and mitigate possible adverse effects.

Article 34: Communicating to Data Subjects

When a breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must communicate the breach to the affected data subjects without undue delay. Note there is no fixed 72-hour deadline for individuals — "without undue delay" is the only standard, and the regulator can order a controller to notify individuals if it disagrees with a no-notification decision (Article 34(4)).

The communication must use clear and plain language and describe the nature of the breach, the DPO/contact point, the likely consequences, and the measures taken or proposed.

Article 34(3) provides three exceptions — communication to individuals is not required if any one applies:

Processor Duties and the Breach Register

Processor obligation (Article 33(2)): A processor must notify its controller without undue delay after becoming aware of a breach. The processor does not notify the supervisory authority or data subjects directly — that responsibility stays with the controller. This is a frequent trap on the exam, and there is no 72-hour figure attached to the processor's duty; "without undue delay" governs, and the controller's 72-hour clock effectively begins when the processor tells it.

Internal breach register (Article 33(5)): The controller must document any personal data breach, including the facts relating to it, its effects, and the remedial action taken. This documentation duty applies to all breaches — even ones that are not notifiable — so the supervisory authority can verify compliance. Failing to keep this register is itself a lower-tier infringement.

Quick Decision Flow

1. Is there a personal data breach (Article 4(12))? If no, stop.
2. Is there a risk to individuals? If yes, notify the DPA within 72 hours (Article 33).
3. Is there a high risk? If yes, also notify data subjects without undue delay (Article 34), unless an exception applies.
4. Always log it in the breach register (Article 33(5)).

Assessing the Severity of a Breach

The EDPB and the predecessor WP29 Guidelines direct controllers to weigh several factors when deciding whether a breach poses a risk (Article 33) or a high risk (Article 34): the type of breach (confidentiality, integrity, availability); the nature, sensitivity, and volume of the data; the ease of identifying affected individuals; the severity of consequences such as identity theft, fraud, financial loss, or discrimination; special characteristics of the data subjects (e.g., children or vulnerable people); the number of individuals affected; and the controller's own special characteristics (e.g.,

a medical organisation).

A breach of a single email address is low risk; a breach of health records or full payment-card data linked to names is typically high risk and triggers both Article 33 and Article 34. Documenting this severity reasoning in the breach register is what lets a controller defend a decision not to notify.