A data breach happens at 11 PM on a Friday. Do you know exactly what to do in the next 72 hours? If not, you're not alone — and you're exposed to fines of up to €20 million or 4% of global annual turnover under GDPR.
This guide covers everything SaaS founders and CTOs need to know about GDPR breach notification: when the clock starts, who you must notify, what to say, and how to avoid the most common mistakes that turn an incident into a fine.
What is a Personal Data Breach Under GDPR?
GDPR 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."
The three types of breach are:
- Confidentiality breach: unauthorised access to or disclosure of personal data (e.g., a database is exposed to the internet, an employee emails personal data to the wrong recipient)
- Integrity breach: unauthorised or accidental alteration of personal data (e.g., a bug corrupts user records)
- Availability breach: accidental or unauthorised loss of access to, or destruction of, personal data (e.g., ransomware encrypts your database, accidental deletion of production data)
Note: all three types can trigger notification obligations — not just the stereotypical "hacker stole our data" scenario. A ransomware attack that destroys data without exfiltrating it can still be a notifiable breach.
Who Must Notify — Controller vs Processor
GDPR draws a critical distinction:
| Role | Obligation | Deadline |
|---|---|---|
| Data Controller (you, if you collect and use data) | Notify supervisory authority (DPA) and, if high risk, notify affected individuals | 72 hours of becoming aware |
| Data Processor (your SaaS customers if they process data via your platform) | Notify the controller — no direct DPA notification obligation | "Without undue delay" — typically 24–36 hours to give the controller time to notify within 72h |
If your SaaS is a processor (you process data on behalf of your B2B customers), your primary obligation under Article 33(2) is to notify your customer (the controller) without undue delay. Your GDPR DPA should specify the exact notification window — typically 24–36 hours to give the controller enough runway to notify their DPA within 72 hours.
If your SaaS is a controller (you collect and use end-user data directly — e.g., a B2C SaaS), you must notify the relevant supervisory authority within 72 hours and, where the breach is likely to result in high risk to individuals, also notify the affected individuals directly under Article 34.
The 72-Hour Clock: When Does It Start?
The clock starts when you become "aware" of the breach. This is where it gets complicated — the EDPB's guidance is that you become aware when you have "a reasonable degree of certainty that a security incident has occurred that has led to the exposure of personal data."
In practice:
- A junior engineer spots something suspicious at 11 PM → the clock doesn't necessarily start until a responsible person in the organisation has assessed it
- You receive a report from a security researcher that your database is exposed → clock starts when you can confirm personal data is involved
- Your monitoring system alerts on an anomaly → investigation time is allowed, but you can't deliberately delay investigation to push back the clock
Critical point: You don't need absolute certainty before notifying. If you're investigating and it becomes clear a breach has occurred, you should notify even if you don't yet know the full scope. You can submit an initial notification and update it within Article 33(4).
Article 33: Notifying Your Supervisory Authority
Under GDPR Article 33(1), you must notify the competent supervisory authority (DPA) without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. If you notify after 72 hours, you must explain the reasons for the delay.
Which DPA do you notify?
Notify the DPA of the EU member state where your main establishment (primary EU business presence) is located. For Estonian companies, that's the Andmekaitse Inspektsioon (AKI). For UK companies post-Brexit, it's the ICO. If you have no EU establishment but offer services to EU residents, notify the DPA of the member state where your affected data subjects are located.
What to include in your notification
Article 33(3) requires the following information (which you can supply in phases if not all information is available immediately):
- Nature of the breach: Describe what happened — confidentiality, integrity, or availability breach; how it occurred; and the systems/data involved
- Categories and approximate number of data subjects affected: e.g., "approximately 2,400 registered users whose email addresses and hashed passwords may have been exposed"
- Categories and approximate number of personal data records affected: e.g., "email addresses, names, and bcrypt-hashed passwords"
- Name and contact details of your DPO or other contact: Who the DPA can call for more information
- Likely consequences of the breach: What harm could result — phishing attacks, account takeover, identity theft, financial loss
- Measures taken or proposed: What you've done to contain the breach and prevent recurrence — forced password resets, patched the vulnerability, revoked API keys, etc.
You can notify in phases. Submit what you know within 72 hours, then follow up with additional information as your investigation progresses. The EDPB explicitly allows this — failing to notify at all is far worse than notifying partially and following up.
Article 34: Notifying Affected Individuals
In addition to notifying the DPA, GDPR Article 34 requires you to notify affected individuals directly "without undue delay" when the breach is likely to result in a high risk to the rights and freedoms of natural persons.
High risk factors include:
- Exposure of special category data (health, financial, political opinions, biometric data)
- Data that could enable identity theft or fraud (passwords, payment card numbers, national ID numbers)
- Exposure affecting vulnerable groups (children, patients)
- Large-scale breaches affecting many individuals
Individual notification is not required if:
- The data was encrypted and the key was not compromised (making the data unintelligible to the attacker)
- You've subsequently taken measures that ensure the high risk is no longer likely to materialise (e.g., you've verified the exposed data was not accessed)
- Individual notification would involve disproportionate effort, in which case a public communication may substitute (Article 34(3)(c))
Individual notification must include at minimum: the nature of the breach, the name and contact details of the DPO or other contact, the likely consequences, and the measures taken or proposed.
When You Don't Need to Notify the DPA
Article 33(1) contains a significant exception: notification is not required if "the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons."
Examples where you might not need to notify:
- An employee laptop is lost but was encrypted and remotely wiped immediately
- An email with non-sensitive customer data was accidentally sent to the wrong person but you've confirmed it was not forwarded or acted upon
- A brief accidental exposure of non-sensitive data to a small number of users
Critically: you must document your reasoning for not notifying. Article 33(5) requires you to document all personal data breaches, including those where you decide notification is not required. This documentation must include the facts, effects, and remedial actions — it's what the DPA will ask for if they ever investigate.
Building a Breach Response Playbook
The worst time to figure out your breach response procedure is when a breach is actually happening. Build this playbook in advance:
Step 1: Detect and contain (0–6 hours)
- Assign a breach response lead immediately (typically CISO, CTO, or engineering lead)
- Isolate affected systems — revoke credentials, disable vulnerable endpoints, take snapshots for forensics
- Preserve logs — do not delete anything until after the investigation
- Assess: is this actually a personal data breach within GDPR's definition?
Step 2: Assess scope (6–24 hours)
- Identify what data was affected and how many individuals
- Determine likely consequences — what harm could this cause to individuals?
- Notify processors/sub-processors if they need to take action
- If you're a processor: notify your controller customers now (to give them time within their 72-hour window)
Step 3: Notify (within 72 hours of awareness)
- Submit notification to your supervisory authority via their online portal
- If high risk: draft individual notifications and send to affected users
- Keep a log of all notifications sent, to whom, and when
Step 4: Remediate and document
- Patch the vulnerability, implement additional controls
- Document everything in your breach register (required by Article 33(5))
- Conduct post-incident review and update your security policies
- Consider whether affected individuals need further support
DPA Notification Portals by Country
| Country | DPA | Notification Method |
|---|---|---|
| Estonia | Andmekaitse Inspektsioon (AKI) | aki.ee — online form |
| Germany | State DPAs (LfDI per Bundesland) | Varies by state |
| France | CNIL | notifications.cnil.fr |
| Netherlands | Autoriteit Persoonsgegevens (AP) | meldportaaldatabeschermingsautoriteit.nl |
| Ireland | Data Protection Commission (DPC) | forms.dataprotection.ie |
| United Kingdom | ICO | ico.org.uk/report-a-breach |
| United States (CCPA) | California AG | No 72h rule — varies by state breach law |
Most Common Breach Notification Mistakes
- Waiting until the investigation is complete before notifying. You can notify in phases — failing to notify within 72 hours is a separate violation from the breach itself.
- Only notifying for "hacker" breaches. Accidental deletion, ransomware, and accidental disclosure all trigger the same rules.
- Not keeping a breach register. Article 33(5) requires you to document all breaches, including those you decided didn't require DPA notification. This is what auditors ask for.
- Notifying individually when encryption exempts you. Over-notifying users can cause unnecessary panic. If the data was properly encrypted and keys uncompromised, you may not need individual notification — but document why.
- Failing to notify your processor customers promptly. If you're a B2B SaaS processing data on behalf of customers, they have a 72-hour deadline that depends on your prompt notification. Slow processor notification has triggered enforcement action.
👉 Generate your GDPR Privacy Policy with proper breach notification contact details and data subject rights disclosures — free, no account required.
👉 Generate a GDPR Data Processing Agreement that specifies your breach notification timelines as a processor — required for all B2B SaaS with EU customers.
Key Takeaways
- The 72-hour clock starts when you become aware of the breach — not when you confirm all the details.
- Notify in phases: submit what you know, then update as your investigation progresses.
- Controllers notify the DPA; processors notify the controller. Both obligations are real.
- Individual notification (Article 34) is required only when the breach is likely to result in high risk to individuals — not for every breach.
- Document everything, including breaches you decide don't require notification.
- Build your breach response playbook before you need it.