AI Data Breach Notification Template

72-hour GDPR breach notification template for AI data incidents

Generate a GDPR Article 33 supervisory-authority breach notification for AI-related data incidents — covering the nature of the breach, categories and approximate number of data subjects, likely consequences, and the measures taken to address it. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the GDPR 72-hour rule?

Under Article 33, a controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. If notification is later than 72 hours it must be accompanied by reasons for the delay.

AI data breach notification template

When an AI system leaks or mishandles personal data, the GDPR clock starts the moment you become aware. Article 33 requires controllers to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours. This tool assembles a complete notification covering every element the regulation asks for — the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken — so you can move fast under pressure.

How it works

You describe the incident, the data categories involved, an estimate of how many people are affected, and the steps you have already taken to contain it. The tool maps your answers onto the structure of an Article 33 notification: identification of the controller and DPO, a factual description of the breach and its timeline, the data categories and approximate counts, the likely consequences for individuals, and the mitigation measures. Everything runs in your browser — no incident details are sent anywhere.

What Article 33 actually requires you to state

The regulation is specific about what a notification must contain. Working from that list is faster and safer than writing from a blank page during an incident:

a) The nature of the breach — what type of incident it was (unauthorised access, accidental disclosure, ransomware, misconfiguration, etc.), how it occurred, and the systems or data sets affected. For AI-specific incidents this might be prompt-log exposure, a retrieval system returning another user’s data, a model trained on data it should not have been.

b) The categories and approximate number of data subjects — who was affected (customers, employees, prospective users) and roughly how many. Article 33 asks for approximates; you do not need an exact count to notify.

c) The categories and approximate number of personal data records — what types of data were involved. Health data, financial data, login credentials, and special-category data each carry different risk profiles and affect whether Article 34 (individual notification) is also triggered.

d) Contact details of the DPO — or another point of contact where the authority can request further information.

e) Likely consequences — your assessment of what could happen to the affected individuals: identity theft risk, financial harm, reputational damage, distress. Speculative worst-case scenarios are not needed; a realistic assessment is.

f) Measures taken or proposed — containment steps already done (for example, revoked access, taken a system offline, patched a misconfiguration) and what remediation is planned. This section demonstrates that you acted promptly.

The two-track notification decision

There are two separate notification duties in GDPR that arise from different thresholds:

Article 33 (supervisory authority) — notify if the breach is likely to result in a risk to individuals’ rights and freedoms. The threshold is relatively low — if there is any realistic risk, notify. Use phased reporting if you do not have all the facts yet; send what you know and supplement.

Article 34 (individuals) — notify affected people directly only if the breach is likely to result in a high risk — a higher bar, typically triggered by exposure of sensitive data categories such as health information, financial account details, or authentication credentials.

If you decide not to notify the authority, you must still document the breach internally under Article 33(5), including your reasoning for not notifying.

Tips and notes

  • Notify even if details are incomplete. Article 33 explicitly allows phased reporting; send what you know within 72 hours and supplement later with a follow-up notification.
  • Document the “no-notify” decision. If you conclude the breach is low risk, your reasoning must be recorded — Article 33(5) requires an internal record of every breach, including those you decide not to report.
  • Treat the 72 hours as starting when you have reasonable grounds, not certainty. Waiting to investigate fully before notifying is a common and expensive mistake.
  • Have it reviewed. This is a structured drafting aid — your DPO or legal counsel must approve the final notification before it is sent.