GDPR Breach Notification: Running the 72-Hour Clock
How security and IR teams handle GDPR Articles 33 and 34: when the 72-hour clock starts, risk assessment, phased notification, and the breach register.
Most incident response plans were written to contain attackers and restore services. The GDPR adds a second track that runs in parallel: deciding, often within hours, whether a security incident is a personal data breach, whether it must be reported to a supervisory authority, and whether affected individuals must be told. Articles 33 and 34 set the rules, and the 72-hour deadline in Article 33(1) is the one everyone remembers. This guide explains how the clock works, what the regulation actually requires in each notification, and how to build the privacy track into your existing IR playbook without slowing containment.
What counts as 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".
Three points follow for security teams:
- It must be a breach of security. A lawful but questionable use of data is a compliance issue, not a breach under Article 4(12).
- Accidental counts. A misdirected email, a public cloud bucket or a lost unencrypted laptop are breaches even with no attacker.
- It covers more than theft. Guidance from the Article 29 Working Party (WP250 rev.01, endorsed by the EDPB) classifies breaches into three types, mirroring the CIA triad.
| Breach type | Definition | Examples |
|---|---|---|
| Confidentiality | Unauthorised or accidental disclosure of, or access to, personal data | Exfiltration, misconfigured storage exposed publicly, email sent to wrong recipients |
| Integrity | Unauthorised or accidental alteration of personal data | Tampering with records, corrupted data from a faulty deployment |
| Availability | Accidental or unauthorised loss of access to, or destruction of, personal data | Ransomware with no usable backup, deletion without recovery, prolonged outage of a critical system |
An incident can fall into several types at once. Ransomware that encrypts a file server and exfiltrates data first is both a confidentiality and an availability breach.
When the 72-hour clock starts
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 it". The key word is aware.
WP250 and EDPB guidance treat a controller as aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. In practice:
- A SOC alert on its own is usually not awareness. It triggers a short initial investigation.
- Once that investigation establishes, with reasonable certainty, that personal data has been affected, the clock is running.
- The investigation period must be short and conducted promptly. Leaving an alert in a queue over a weekend does not postpone awareness.
The 72 hours are calendar hours, not business hours. Document the exact timestamp at which awareness was reached and who decided it; that timestamp will anchor every later question from the authority.
Processors: notify the controller without undue delay
Under Article 33(2), a processor must notify the controller without undue delay after becoming aware of a breach. The processor does not notify the supervisory authority on the controller's behalf unless the contract arranges it, and the controller remains responsible. Your processor contracts under Article 28 should specify a notification window, a contact point and the information the processor must provide.
Risk assessment: notify, communicate, or record only
Not every breach is notified. The decision is based on risk to the rights and freedoms of individuals, not on risk to the organisation.
| Risk to individuals | Supervisory authority (Art. 33) | Data subjects (Art. 34) | Breach register (Art. 33(5)) |
|---|---|---|---|
| Unlikely to result in a risk | Not required | Not required | Required |
| Risk | Required | Not required | Required |
| High risk | Required | Required, unless an Art. 34(3) exception applies | Required |
Factors worth assessing and documenting:
- Type of breach (confidentiality, integrity, availability).
- Nature and sensitivity of the data: special categories under Article 9, criminal data under Article 10, financial data, credentials, identity documents.
- Volume of records and number of individuals.
- Ease of identification of individuals from the data.
- Severity of consequences: identity fraud, discrimination, financial loss, distress, physical harm.
- Special characteristics of individuals, such as children or other vulnerable persons.
- Mitigating factors: strong encryption with uncompromised keys, confirmed deletion by a trusted recipient, fast recovery from backup.
EDPB Guidelines 01/2021 on examples regarding personal data breach notification walk through many realistic scenarios and are worth reading with your IR team.
What goes into the notification
Article 33(3) sets the minimum content:
- (a) the nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned;
- (b) the name and contact details of the data protection officer or another contact point;
- (c) the likely consequences of the breach;
- (d) the measures taken or proposed, including, where appropriate, measures to mitigate possible adverse effects.
Article 33(4) accepts that you will not have everything on day one: information may be provided in phases without undue further delay. A sound approach is an initial notification within 72 hours with what is known, clearly flagged as preliminary, followed by updates as forensics progresses. If the initial notification itself is late, Article 33(1) requires you to give the reasons for the delay.
For controllers with establishments in several Member States, the lead authority mechanism generally applies. EDPB Guidelines 9/2022 clarify that a controller not established in the EU does not benefit from the one-stop-shop merely by appointing an Article 27 representative, and must notify each relevant authority. Check your national supervisory authority's guidance for its notification portal and forms.
Communicating with data subjects
When a breach is likely to result in a high risk, Article 34(1) requires communication to the data subjects without undue delay. Article 34(2) requires clear and plain language describing the nature of the breach and at least the information in Article 33(3)(b), (c) and (d): a contact point, likely consequences and the measures taken. Good communications also tell people what they can do: reset passwords, watch for phishing that uses the leaked data, contact their bank.
Article 34(3) provides three exceptions:
- (a) appropriate technical and organisational protection measures were applied to the affected data, in particular measures that render it unintelligible to unauthorised persons, such as encryption;
- (b) subsequent measures ensure the high risk is no longer likely to materialise;
- (c) it would involve disproportionate effort, in which case a public communication or similar equally effective measure is required instead.
The supervisory authority can require you to communicate if it considers the high risk likely (Article 34(4)). The encryption exception only helps if the keys were not compromised in the same incident, which is one of many reasons key management belongs in your Article 32 programme.
The breach register: every breach, not just notified ones
Article 33(5) requires the controller to document any personal data breach, comprising the facts, its effects and the remedial action taken, so that the authority can verify compliance. This includes breaches you decided not to notify. The reasoning behind that decision is exactly what an authority will want to see.
# Example breach register entry (Art. 33(5)) - adapt fields to your tooling
breach_id: PDB-2026-017
linked_incident: IR-2026-0412
detected_at: "2026-09-14T08:12:00Z"
aware_at: "2026-09-14T13:40:00Z" # reasonable certainty personal data affected
aware_decided_by: "IR lead + DPO"
breach_types: [confidentiality]
description: "Support mailbox rule forwarded customer tickets to an external address after account compromise"
data_categories: [contact_details, order_history]
special_categories: false
data_subjects_approx: 1350
records_approx: 2900
likely_consequences: "Targeted phishing using order details"
risk_level: risk # none | risk | high
sa_notified: true
sa_notified_at: "2026-09-16T10:05:00Z"
sa_reference: "<reference from authority portal>"
phased_updates: ["2026-09-23T09:00:00Z"]
data_subjects_informed: false
art34_rationale: "Risk assessed as not high: no credentials or financial data exposed"
remedial_actions:
- "Forwarding rule removed, account reset, MFA enforced on shared mailboxes"
- "Mail flow rule alerting for external auto-forwarding"
closed_at: null
Example hour-by-hour playbook
The table below is an example internal playbook, not a legal requirement. Adapt the timings to your organisation; the only regulatory anchor is the 72-hour limit from awareness, and "without undue delay" applies throughout.
| Time from awareness | Security / IR track | Privacy track (DPO, legal) |
|---|---|---|
| Before T0 | Triage alert, short initial investigation | DPO on standby if personal data may be involved |
| T0 | Confirm personal data affected; record timestamp | Open breach register entry, start the clock |
| T0 to T+4h | Contain, preserve evidence, scope systems | Identify controller/processor roles, data categories |
| T+4h to T+24h | Establish attack path, estimate affected records | Preliminary risk assessment; decide on Art. 33 notification |
| T+24h to T+48h | Continue forensics, eradicate | Draft notification with Art. 33(3) content; prepare Art. 34 message if high risk |
| T+48h to T+72h | Validate scope figures for the notification | Submit initial notification, flag as phased if incomplete |
| After T+72h | Recovery, lessons learned | Follow-up submissions, communications to data subjects, close register entry |
If your organisation is also in scope of NIS2, the same incident may trigger a separate report to a CSIRT or competent authority on a different timeline. See GDPR and NIS2 for how to run one process with two outputs.
Common pitfalls
- Waiting for complete forensics before notifying instead of using phased notification.
- Recording only notified breaches in the register.
- Assessing risk to the company rather than to individuals.
- Processor contracts with no defined breach notification window.
- Relying on the encryption exception when the keys were on the compromised host.
Scope of this guide
This article is technical guidance for security and incident response teams on GDPR breach handling. It is not legal advice. Confirm notification decisions, risk assessments and communications with your data protection officer or legal counsel.