TL;DR: GDPR Article 33 gives you 72 hours to report a personal data breach. The clock starts when you become aware of it, not when you finish investigating. Your report has to name the categories of data involved. It has to give a rough count of the people affected. It has to state the likely harm, and what you did about it. That is the part most AI-built apps fail. Not the legal writing. The detection. If your app has no error tracking, no record of who read what, and no alerts, you will not know a breach happened. And if you do find out, you will not be able to say what was taken. You can file in stages under Article 33(4). You still have to file something in 72 hours. This guide covers what the law asks for. It also covers the logging you need first.

A founder ships a SaaS built with an AI coding tool. Signup works. Payments work. Six months on, a stranger emails. Your customer table is for sale on a forum. Now you have 72 hours. You open your dashboard and find you have no idea who read that table, when, or how many rows they took. The law does not accept that as an answer.

QuestionAnswer
When does the 72-hour clock start?
When you become aware a breach has likely happened. Not when you confirm the details. Reasonable certainty is enough to start it.
What has to be in the report?
The nature of the breach, the categories and rough number of people affected, the likely consequences, and the steps you took. Article 33(3).
What if we don't know everything yet?
File in stages. Article 33(4) lets you send what you have, then follow up. It does not let you skip the deadline.
Do we have to tell our users too?
Only if the breach is likely to be a high risk to them. That is Article 34. Leaked passwords or payment data usually clear that bar.
Why do AI-built apps struggle here?
They ship without audit logs, error tracking, or alerting. So the breach is found late, and the report cannot be filled in.
Where should we start?
Run a free scan on your live app. Then work through the checklist below.

The 72 hours are a detection problem

Most guides treat this as a legal task. Learn the rule. Write the notice. Send it.

That is the easy half. The hard half is technical. Article 33 asks you to describe a breach. To describe one, you have to spot it. Then you have to piece it back together. Both need data your app was already saving.

You cannot go back and add logs after the fact. Say nobody logged who read the users table last Tuesday. That record does not exist. It is gone. You will write "unknown" in the boxes a regulator cares most about.

This is why the 72-hour rule bites small teams harder than it looks. The deadline is short. But the real work happened months back. It happened when the app was built.

44
Average Launch Readiness Score across the 700+ AI-built apps we've audited. Missing error tracking, no uptime checks, and no alerting are among the most common reasons apps land in that range. They are the same gaps that hide a breach.

What "becoming aware" actually means

The clock starts when you are fairly sure a security incident has hit personal data. It does not wait for a full probe.

In practice, that moment usually arrives one of four ways:

Only the first one gives you the full 72 hours to work with. The other three mean the breach already ran for a while. You start the clock late. You also start it blind.

You do not get extra time for being slow to notice. Regulators treat weak monitoring as your problem. It is not an excuse. Not knowing is not a defence.

What Article 33(3) makes you write down

The notice is not one line saying you got hacked. Article 33(3) lists what goes in it:

Look at the second one again. Categories and rough numbers. That is a query against your own data. First you need to know what personal data you hold. Then you need to know where it sits. Only then can you say which parts leaked.

Most AI-built apps cannot answer that quickly. Personal data ends up spread across auth tables, webhook payloads, analytics events, email tools, and support tickets. Nothing ties them together. We wrote a full walkthrough of that problem in our guide to GDPR data mapping for AI apps.

The same gap shows up when someone asks for their own data. If you have not read it yet, our DSAR checklist for AI-built apps covers the access-request side of this. A breach report is the same discovery job on a much shorter clock.

Filing in stages under Article 33(4)

You will rarely have every fact in 72 hours. The law knows this.

Article 33(4) lets you file in phases. Send what you have by the deadline. Say plainly that the work is open. Then send the rest as you learn it.

This is the single most useful part of the rule for a small team. Founders miss the deadline for one reason. They wait for a clean, full story. There is no such thing on day three.

Two things it does not let you do. It does not let you file on day ten. It does not let you file an empty form and go quiet. You have to keep digging. You have to keep updating.

Miss the 72 hours and you owe the regulator a reason for the delay. It goes in with the notice. "We had no logs" is a bad explanation to be writing.

The internal register in Article 33(5)

Not every incident goes to a regulator. Say a breach is unlikely to be a risk to anyone. Then you may not have to file.

You still have to write it down. Article 33(5) says you must log every personal data breach: the facts, the effects, and what you did about it.

This log is the first thing a regulator asks for in an audit. It is also the thing almost no solo founder keeps. A bug gets fixed. The team moves on.

Your log does not need special software. A spreadsheet works. What matters is that you write it at the time. Not a year later, from memory.

When Article 34 makes you tell your users

Article 33 is about telling the regulator. Article 34 is about telling the people affected.

That duty kicks in when the breach is likely to be a high risk to their rights and freedoms. Leaked passwords clear that bar. So do payment details, private messages, and health data. A list of first names probably does not.

When it applies, you tell them without undue delay, in clear and plain words. What happened, what data was involved, what you are doing, and what they should do now.

There is one exception worth knowing. Say the data was encrypted, and is useless to whoever took it. Then you may not need to tell the people affected. That only helps if the encryption was already there.

Why AI-built apps fail this test

AI coding tools are good at the parts you can see: screens, forms, routes, auth flows. They are fast at all of it.

They are much weaker at the parts nobody sees in a demo. Audit logging. Error tracking. Rate limiting. Alerting. Nobody prompts for those. So they do not get built.

The result is an app that works and cannot explain itself. Say someone scripts their way through your database with a valid key. There may be no trace at all in your app logs.

Two failure patterns come up again and again in our audits:

Both leak data through what looks like normal traffic. With no access logging, there is nothing to notice. There is nothing to report. If a key has already gone public, our guide on what to do when an API key is exposed covers the containment steps.

This is not a thought experiment. We broke down a real case in our writeup of the Quittr Firebase breach. A setup mistake exposed user records. No attack was needed.

What to put in place before the clock starts

This is the part you can do this month. None of it takes long.

  1. Turn on error tracking. Say your app throws a wall of database errors at 3am. Someone should be told. Our error monitoring basics for founders guide walks through the setup.
  2. Log data access, not just errors. Record who read which records, and when. Keep it long enough to be useful. Ninety days is a sane floor.
  3. Set alerts on volume. One user reads ten thousand rows in a minute. That is not normal use. It should page someone.
  4. Write the data map. One page. Every place personal data lives, third-party tools included. You need it to fill in Article 33(3).
  5. Find your regulator now. Know which one you file with. Bookmark their form. Do not learn this at hour 60.
  6. Write a one-page runbook. Who to call, how to kill keys, where the log lives, and who drafts the notice.
  7. Start the log today. Write up the next incident, however small.

Steps one to three turn the 72 hours from a panic into a process. The rest is paperwork. You can do it in an afternoon.

Scanning is how you find the gaps

First you need to know where the risky paths are. That is a discovery job. It is the same one a scanner does when it maps an app's attack surface.

Founders comparing options often start with the enterprise names. We wrote plain comparisons for two of them. There is a Checkmarx alternative, for teams who want source-level analysis without an enterprise contract. There is an OWASP ZAP alternative, for teams who want the scan run and read for them.

Both point at the same thing. You cannot protect, log, or report on data paths you have never mapped.

Find out what a breach report would have to say

Run a free scan on your live URL. You get a Launch Readiness Score out of 100. You also get the exposed paths and missing controls that would show up in an Article 33 notice.

Run a free scan

Where this sits in the wider picture

Breach reporting is one duty among several. It sits next to lawful basis, data mapping, access requests, and vendor deals.

If you are starting from zero, our GDPR compliance guide for vibe-coded apps is the better first read. Our compliance checklist covers the full sweep across frameworks.

We do not certify anyone for GDPR. We are not lawyers. What we do is find the technical gaps that make these duties impossible to meet. Our Compliance Wing runs automated checks and a human implementation pass. The plans are on our pricing page.

FAQ

When exactly does the GDPR 72-hour breach notification clock start?

It starts when you become aware that a personal data breach has likely happened. Aware means you are fairly sure a security incident has hit personal data. It does not mean you have finished the probe. It does not mean you have every detail. Say a user reports something odd on Monday. You confirm a leak on Tuesday. The clock started on Tuesday. Waiting to be sure of the full scope first is a common and costly mistake.

What happens if we miss the 72-hour deadline?

You still have to file. You must also say why the notice is late. A late notice with a clear reason beats no notice. Regulators look at whether the delay could have been avoided. Say the delay came from missing logs. That is treated as your fault. The law expects you to spot incidents in your own systems.

Do we have to report every incident, or only serious ones?

You report a breach to your regulator unless it is unlikely to be a risk to people's rights and freedoms. So low-risk incidents may not need a filing. But Article 33(5) still makes you log every personal data breach in-house. That includes the ones you never file. The log must cover the facts, the effects, and the action you took. It is the first thing a regulator asks to see.

Why do apps built with AI coding tools struggle with breach notification?

Because these tools build the visible parts of an app well and skip the rest. Audit logs, error tracking, rate limiting, and alerting rarely get built unless someone asks. That leaves an app that works but cannot explain itself. When a breach hits, the team finds out late. They cannot say which data was touched. They cannot say how many people were hit. Those are the exact fields Article 33(3) asks for.

What is the difference between Article 33 and Article 34?

Article 33 is your duty to tell the regulator, normally within 72 hours. Article 34 is your duty to tell the people whose data was breached. Article 34 only applies when the breach is likely to be a high risk to their rights and freedoms. Leaked passwords, payment details, and health data all clear that bar. The message to them must be in clear, plain words. It must go out without undue delay.

Can a free security scan tell us whether we could meet a 72-hour deadline?

A free URL-based scan is a fast first read on your app. It takes under two minutes. It can surface exposed data paths, missing access controls, and absent monitoring. Those are the gaps that make a breach hard to spot and hard to describe. It does not write your notice. It does not build your data map. It is not legal advice. Use it to find the technical holes. Then close them, and get the paperwork ready before anything happens.

Research sources