NormaKit Guide

GDPR Data Breach: What to Do in the First 72 Hours

Practical guide · GDPR Art. 33 & 34 · applies the moment anyone on your team becomes aware of a possible breach

A "personal data breach" under GDPR is broader than most people assume: it's any accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. A lost laptop, an email sent to the wrong recipient, a leaked spreadsheet, or ransomware all count — not just large-scale hacking. The moment anyone on your team becomes aware, a clock starts. Here's what actually has to happen next.

Step 0 — the 72-hour clock

The clock starts on awareness, not on the incident itself. If you find out on Tuesday about something that happened last week, your 72 hours (Art. 33) start Tuesday. Log the exact date/time you became aware immediately — you'll need it.

Step 1 — contain and assess

Contain it. Revoke access, rotate passwords, isolate affected systems, take a compromised service offline if needed.
Identify what happened. What data, roughly how many people, and — this matters most for severity — is any of it special-category data (health, etc.) or financial/ID data?
Check if it's still ongoing. Is data still being exposed right now?
Preserve evidence (logs, screenshots) before remediating, where possible — you'll need it to explain what happened later.

Do you have to notify the Garante (the supervisory authority)?

Notify within 72 hours unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons" (Art. 33(1)). Ask yourself:

Could this data be used to harm the people affected — fraud, identity theft, discrimination, reputational or financial harm?
Was the data encrypted or pseudonymised well enough that whoever accessed it can't actually use it (e.g. a stolen backup, fully encrypted, key never exposed)?
How many people, and how sensitive is the data?

If there's any real risk — the normal case for anything short of fully encrypted, unreadable data — notify. When genuinely unsure, notify anyway: the penalty for failing to report a real breach is typically worse than the friction of reporting one that turns out to be low-risk. If you can't finish your assessment within 72 hours, notify anyway with your reasons for the delay (Art. 33(1) allows a phased notification) — don't wait for a complete picture before the first report.

Do you also have to notify the people affected?

Separately, Art. 34 requires notifying affected individuals directly, without undue delay, only if the breach is likely to result in a HIGH risk to them — a higher bar than the Garante notification above. Ask:

Is this the kind of data that causes serious harm if misused — passwords, financial details, ID documents, health data, precise location?
Can the affected people protect themselves without knowing (e.g. changing a reused password, watching for fraud)?

You're exempt from notifying individuals if the data was encrypted/unintelligible to whoever accessed it, if you've since taken measures that remove the high risk, or if direct notice would take disproportionate effort — in which case a public notice (e.g. a site-wide banner) can substitute, as long as it informs people just as effectively.

Question	If yes
Any real risk to affected people?	Notify the Garante within 72h
High risk specifically (sensitive data, real harm possible)?	Also notify affected individuals directly
Data was fully encrypted, key never exposed?	Often exempt from both — document why

The one step everyone forgets: the internal log

Art. 33(5) requires you to document every breach internally — including ones you decide not to report to anyone. The Garante can ask to see this log at any time, and "we didn't think it was serious enough to write down" is not a defensible answer if they do. At minimum, record: when discovered, when it happened, how it was discovered, what data and how many people were affected, your risk assessment and reasoning, whether you notified the Garante and/or individuals (and when), and what you did to contain it and prevent it recurring.

Related reading

A breach-response plan sits alongside your other GDPR paperwork, not instead of it. If a breach happens, you'll likely also need to check your Privacy Policy covers what you told people about your security measures, and — if the breach happened at a processor working on your behalf (a developer, host, or agency) — your DPA should already specify their own breach-notification obligation back to you. Your ROPA is also the fastest way to answer "what data was affected and why did you have it" — the first questions the Garante will ask. If the breach came through a form on your site, check whether its consent clause also needs updating. For the full picture of how all these pieces fit together, see our plain-language GDPR guide.

Don't want to draft an incident log and notification letters mid-crisis?

NormaKit is a bilingual (EN/IT) GDPR document pack that includes a ready-to-use breach-notification checklist with a decision tree, an internal incident log template, and pre-written notification letter templates (to the Garante and to affected individuals) — plus a Privacy Policy, Cookie Policy, consent clauses, a full Art. 28 DPA, and a ROPA template. €29 one-time, instant download, editable .docx and .pdf.

See what's included →

Not legal advice. This guide is general information, not a substitute for advice from a qualified lawyer or data protection professional about your specific incident — especially while it's active, when you should also consider consulting a lawyer and, for significant incidents, a cybersecurity professional. NormaKit's templates are likewise informational starting points, not legal advice, and should be reviewed and adapted before use.