The 72-hour GDPR breach notification clock, and why AI-built tools miss it

Say a database behind one of your apps gets exposed. Personal data is involved. GDPR gives you 72 hours to report it to your regulator, and the clock started the moment you became “aware.” Now the awkward part: for an app somebody built on an AI platform in an afternoon, there’s often no monitoring, no logging, and no named person watching, so “aware” can arrive days late, or never.

That gap is where the 72-hour rule quietly turns into a problem. Not because the deadline is unfair, but because AI-built tools are frequently missing the exact things you’d need to notice a breach in the first place. Here’s how the rule actually works and what to check.

How the 72-hour rule actually works

The rule comes from Article 33 of GDPR. If a personal-data breach happens, and it’s likely to create a risk to people’s rights, you have to notify your supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it.”

A few details matter more than people expect:

• The clock starts at awareness, not at the breach. If your system is compromised on Monday but nobody notices until Thursday, the 72 hours run from Thursday. That sounds forgiving, but regulators expect you to have reasonable means of noticing. “We had no monitoring so we never became aware” is not the safe answer it sounds like. A regulator can treat a failure to detect as its own shortcoming.

• 72 hours is calendar hours, not business hours. Weekends and holidays are included. A breach you spot Friday evening has a Monday-evening deadline.

• Not every breach needs reporting. If the breach is “unlikely to result in a risk to the rights and freedoms” of people, you don’t have to tell the regulator, but you still have to document it internally. Encrypted data that leaked but stays unreadable is the classic example of lower risk.

• High-risk breaches also require telling the affected people, under Article 34, in clear language, without undue delay. That’s a separate obligation on top of the regulator notice.

• A breach isn’t only a hack. Losing a laptop, emailing data to the wrong person, or accidentally making a database public all count. “Breach” means any unauthorized access, loss, or disclosure of personal data.

Why AI-built tools miss the deadline

The 72-hour clock assumes you can tell when something went wrong. AI-built apps often can’t, for structural reasons:

1. No monitoring. The app was built to work, not to watch itself. There’s no uptime monitor, no error alerting, no unusual-activity detection. If the database gets scraped, nothing pings anyone.

2. No logging. When you finally suspect a breach, the first question is “what was accessed, and when?” Without logs, you can’t answer it. That turns a manageable incident into a guess, and regulators dislike guesses.

3. No named owner. The person who built the tool may have moved teams or left. Nobody’s job is to notice, so the 72 hours can burn while the tool sits unwatched.

4. Public-by-default mistakes. A very common AI-app breach is a database left open to the internet, or an exposed API key. These don’t announce themselves. Someone has to be looking, or a security researcher has to email you, before you “become aware.”

5. Backups and blast radius are unknown. Part of a breach notification is describing the likely consequences. If nobody knows what data the tool holds or how far a leak spreads, that description is impossible to write well inside three days.

Put those together and you get the failure mode: the breach is real, the clock is running, and the team spends the first two days just working out what happened, because the tool was never built to tell them.

What to check before you ever need this

You don’t want to design your breach response during the breach. A short checklist, done in advance, per AI-built tool:

1. Can you detect a breach at all? Is there any monitoring or alerting on this app? If not, that’s the first gap, because detection is what starts the clock in your favour.

2. Do you have logs, and how long do they go back? You want a record of access and changes. Confirm logs exist and are retained long enough to reconstruct an incident.

3. Who is the named owner? One person who is responsible for this tool and would be told first. If you can’t name them, see our post on giving every tool a named, accountable owner.

4. Do you know what personal data the tool holds? You can’t describe a breach’s impact without knowing the data. Write down the categories: names, emails, health data, payment details.

5. Do you know your supervisory authority and how to notify them? For a UK organization that’s the ICO; in the EU it’s your national data protection authority. Know the reporting form and where it lives before you need it.

6. Is there a simple written procedure? Even one page: who declares an incident, who assesses risk, who notifies, in what order. A one-person team still benefits from having decided this while calm.

Or, we do it for you

Monitoring, logging, and a named human who’ll actually notice when something breaks are the parts of breach readiness that AI-built tools almost always lack. That’s the core of what we run for the apps we host: detection and logs so the 72-hour clock works for you, not against you. See our for-SME page.

FAQ

Does the 72 hours start when the breach happens or when I find out?

When you become aware of it. But regulators expect you to have reasonable means of becoming aware, so a total lack of monitoring can itself be treated as a failing. The safest reading: build the detection so that “aware” happens fast, then the deadline works in your favour.

What if I’m not sure whether an incident is really a breach?

Investigate quickly, because the clock may already be running. If after assessment it’s genuinely unlikely to risk anyone’s rights, you may not need to notify the regulator, but you must still document the incident and your reasoning internally. When in doubt, many teams notify rather than risk a late report.

Do I have to tell the people affected, not just the regulator?

Only if the breach is likely to result in a high risk to them, under Article 34. Then you tell them directly, in plain language, without undue delay. Lower-risk breaches still get reported to the regulator (or documented) but may not need individual notices.

We’re a tiny team with no security staff. Does the rule still apply?

Yes. GDPR doesn’t scale the notification duty to your headcount. A two-person startup and a large company have the same 72-hour obligation. What changes is how you meet it, which for a small team usually means outsourcing the monitoring and having a simple written plan ready.