Data Breach Response: The GDPR 72-Hour Playbook

1. What counts as a personal data breach

Article 4(12) GDPR 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. The definition is deliberately broad — it covers three classes of compromise that you should be able to name out loud:

• Confidentiality breach — unauthorised or accidental disclosure or access. The classic stolen laptop, the misdirected email, the leaked database export.
• Integrity breach — unauthorised or accidental alteration of data. A defaced record, a tampered backup, a malicious migration that overwrote correct values.
• Availability breach — accidental or unlawful loss of access to or destruction of data. A ransomware lock-out, a backup that turned out to be unrestorable, a dropped database with no recovery path.

The point of memorising the three classes is that incidents frequently land in more than one — ransomware is both an availability breach (you cannot read your data) and almost always a confidentiality breach (modern strains exfiltrate before they encrypt). Recognising this early changes your assessment.

2. The 72-hour clock and what "awareness" means

Article 33(1) gives controllers 72 hours from the moment they become aware of a personal data breach to notify the supervisory authority — when the breach is likely to result in a risk to the rights and freedoms of natural persons. Two phrases in that sentence do most of the work, and missing the meaning of either is the most common procedural mistake we see:

What "become aware" actually means

EDPB Guidelines 9/2022 frame awareness as the point at which the controller has a reasonable degree of certainty that a security incident has occurred and that personal data is involved. A short triage window — minutes to hours — to confirm the basic facts is permitted and expected; the supervisory authority does not want you filing on rumour. But the moment that confirmation lands, even informally over Slack to the response team, the clock is running.

What "likely to result in a risk" means

This is the gating threshold for whether you notify at all. It is not a high bar — it is the absence of the inverse, that the breach is "unlikely to result in a risk". In practice this means: if you cannot confidently rule out harm to the affected individuals, you notify. The 3-band decision rule below operationalises this directly.

Detection channels feed the clock

Most SMB breaches are detected via one of four channels: automated security monitoring, employee reports, third-party reports (customers, security researchers, sub-processors), or supervisory-authority notification. Document which channel triggered each incident in the register — it is part of the Art. 33(5) record and it surfaces detection blind spots over time.

3. The first 24 hours: contain, preserve, scope

The procedural goal in the first day is not to file with the authority — it is to put the response team in a position where the Art. 33 assessment can be done with real information. Three actions, in this order:

1. Contain. Isolate affected systems, revoke compromised credentials, force session expiry, block ongoing exfiltration paths. Containment is rarely complete on day one; the goal is to stop the harm from growing while the assessment proceeds.
2. Preserve evidence. Capture logs, system snapshots, communications. Resist the temptation to wipe and redeploy the affected system before the response team has a forensic copy — once it is gone, the assessment becomes guesswork and the authority will notice.
3. Scope the personal data involved. Which categories were exposed? Approximately how many subjects? What is the sensitivity? Are special-category or criminal data involved? These four questions are the inputs to the risk assessment in §4 and they are mandatory fields in the register.

One more day-one action that is often missed: notify your DPO (where one is appointed) and any insurers or external counsel on retainer. Cyber-insurance policies frequently require notification within 24–48 hours of awareness as a coverage condition.

4. Risk assessment & the 3-band decision rule

The risk assessment determines whether you notify the supervisory authority, the affected subjects, or neither. Recital 75 GDPR lists the damage factors you weigh, against likelihood and severity:

• discrimination
• identity theft or fraud
• financial loss
• reputational damage
• loss of confidentiality of data protected by professional secrecy
• unauthorised reversal of pseudonymisation
• loss of control over personal data, or being prevented from exercising rights
• processing reveals special categories (Art. 9) or criminal data (Art. 10)
• affects children or other vulnerable subjects
• large-scale processing or large number of affected subjects

The output of the assessment is one of three risk bands. The bands map directly to the statutory thresholds in Articles 33(1) and 34(1) — no extra translation step:

Default rule when in doubt: if you cannot robustly evidence Low, treat the incident as Medium. Late re-classification downwards is straightforward; late classification upwards after the 72-hour window has elapsed is not.

5. Notifying the supervisory authority (Art. 33)

Notification is filed with the supervisory authority of the EU member state where your controller establishment is located. For companies registered in Germany, this is the Landesdatenschutzbeauftragte of the relevant Bundesland (each Land has its own online form). For Poland it is the UODO at uodo.gov.pl. For Lithuania it is VDAI at vdai.lrv.lt.

Article 33(3) lists the four mandatory contents of the notification, which we recommend you draft into a template letter now and store with the procedure so it is ready to fill on the day:

1. The nature of the breach, including the categories and approximate number of data subjects and records concerned.
2. The name and contact details of the DPO or other contact point where more information can be obtained.
3. The likely consequences of the breach.
4. The measures taken or proposed to address the breach and mitigate its possible adverse effects.

Phased notification is allowed

Article 33(4) explicitly permits phased notifications when the facts cannot all be assembled within 72 hours. File what you know, flag what you don't, and commit to a follow-up. This is far better than waiting for full clarity and missing the window.

Late notification is permitted with a reason

If filing within 72 hours is not possible, the notification is still made "as soon as possible" and accompanied by an explanation for the delay (Art. 33(1)). The most common defensible reasons are forensic complexity (the scope was not yet ascertainable) and dependency on a sub-processor's own timeline. The least defensible reason is that nobody noticed.

6. Notifying the affected people (Art. 34)

Subject notification under Article 34(1) triggers when the breach is likely to result in a high risk to the rights and freedoms of natural persons — the High band. The communication must be in clear and plain language, sent to the affected subjects directly, and must contain at least:

• The name and contact details of the DPO or other contact point.
• The likely consequences of the breach.
• The measures taken or proposed to address the breach and mitigate its possible adverse effects.

Three exceptions where subject notification is not required

Article 34(3) lists three carve-outs. If any one of them applies, you do not need to notify subjects directly:

1. Data was rendered unintelligible to unauthorised parties — for example, strong encryption with the key uncompromised. The encryption posture must be documented in the register entry to rely on this.
2. The high risk has been mitigated by subsequent measures — for example, the credentials were rotated before any identifiable use.
3. Disproportionate effort — when individual notification would require disproportionate effort, you may use public communication (e.g. a website notice) instead.

Tone matters

The Art. 34 communication is read by people who are scared and often technically lay. Lead with what happened and what they should do; legalese damages trust without changing the legal position. The supervisory authority can require you to send the communication if you decide not to (Art. 34(4)) — better to draft it well than to be told to do it again.

7. The breach register (Art. 33(5))

Article 33(5) requires the controller to document every personal data breach — including its facts, effects, and the remedial action taken — regardless of whether notification to the supervisory authority was required. This obligation applies to every controller from the first day of processing; there is no small-business exemption. The register is the single most common artefact a supervisory authority asks to see during an audit.

The 11-field schema we use in the CookieSentry Breach Procedure:

Retention norm: at least five years from closure. The supervisory authority will look back across multiple years to spot patterns, and a complete register is your best single defence against a finding of systemic non-compliance.

9. Penalties under Article 83

Failures relating to breach notification — Articles 33 and 34 — sit in the lower fining tier under Article 83(4): up to €10 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. The higher Article 83(5) tier (€20 million or 4%) applies to failures of the lawfulness and rights provisions and is rarely the basis for breach-related cases.

For SMBs the actual fine risk on the breach itself is usually modest. The risk that compounds — and routinely does — is the absence of a documented procedure, the absence of a register, and the inability to evidence the assessment that led to a decision not to notify. Each of these is its own administrative finding and they pile up. The supervisory authority is far less interested in punishing the breach than in punishing the lack of preparation for one.