Here's a situation that happens to small teams more often than you'd think. On a Tuesday afternoon, a user emails to say they could see someone else's invoice. Or a researcher sends a polite note that your database is readable. Or you notice it yourself while testing.
If any of the people affected are in the EU, a deadline started the moment you found out. The GDPR gives you 72 hours to tell your data protection authority, and it doesn't pause while you work out what happened.
This isn't legal advice, and if it happens to you, talk to a lawyer. But the rules are short and readable, and they're much easier to take in on a calm day than during an incident.
What counts as a breach
The GDPR defines a personal data breach as a security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
That's broader than "we got hacked". An open storage bucket, a database table anyone could query, an admin page without a login, an email sent to the wrong list: if personal data was reachable by people who shouldn't have had it, that's a breach. You don't need proof that anyone actually downloaded it. Exposure itself is the disclosure.
The 72 hours
Article 33 says that when a breach happens, the controller (you, if it's your app and your users) must notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it".
There's one exception. You don't have to notify if the breach is "unlikely to result in a risk to the rights and freedoms" of the people affected. A leaked list of newsletter signups with no other data might fall there. Exposed ID photos, passwords, health or financial information won't.
Two details founders miss:
The clock starts when you become aware, meaning when you have a reasonable degree of certainty that a breach has occurred. The European Data Protection Board's guidance allows a short initial investigation to establish that, but not an open-ended one.
You can notify in phases. If you don't have the full picture at hour 70, send what you know and follow up. A late notification must come with the reasons for the delay.
When you must tell users too
Article 34 raises the bar. If a breach is likely to result in a high risk to people, you must also tell them directly, in clear and plain language, without undue delay.
There are exceptions: for example, if the data was encrypted in a way that makes it unreadable, or you've taken steps that mean the high risk is no longer likely to materialise. But for most small apps where real personal data sat in the open, expect to email your users.
What you have to document, always
Article 33(5) requires you to document every personal data breach: the facts, the effects and what you did about it. That includes the ones you decide not to report. If the regulator asks later, "we decided it was low risk" needs to exist in writing, with your reasoning, dated.
What happens if you get it wrong
Failing the notification obligations falls under Article 83(4), which allows fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Regulators consider many factors, including how you behaved once you knew. Prompt, honest notification is treated very differently from silence.
For an early-stage startup the fine is rarely the biggest cost. The emails to users, the customer who pauses a contract, and two weeks of the founding team doing nothing else usually cost more.
The one-page plan to write now
You don't need a security team. You need a page, written today, that answers:
- Who decides whether something is a breach? (Probably you.)
- Which data protection authority is yours? Find its breach notification form and bookmark it. It depends on where your company is established.
- What personal data do you hold, and where? Database tables, storage buckets, email tool, analytics, support inbox.
- How would you contact every user quickly? Make sure you can export emails and send a plain message.
- Who is your lawyer, or who would you call?
- Where will you log what happened, with timestamps?
Then reduce the odds of needing it. Most of the breaches small apps have are the ones in our pre-launch security checklist: database rules, file storage, secrets in the frontend. The Tea app leak is a good example of the storage one, and of what happens when old data you no longer need is still sitting there.
GDPR has one more rule that helps here. You're supposed to keep personal data only as long as you need it. Every table you clean up is data that can't leak.