Data breach notification templates: authority and customer messages
Use two messages and one log. The authority notification covers what Article 33(3) requires: the nature of the breach, a contact point, likely consequences and measures taken. The message to people, needed for high-risk breaches, covers the same points in plain language, plus advice on what they can do.
When a breach happens, the hardest part is often the first sentence of the message. This guide gives you three starting points: a notification to the supervisory authority, a message to the people affected, and an internal log. They follow the content the GDPR requires, so you can fill in the blanks instead of starting from a white page.
They are templates to adapt, not legal advice. Every breach is different, and serious ones deserve a lawyer or a specialist.
#Who must be told, and when?
The rules are in Articles 33 and 34 of the GDPR. For the full process, read our guide to the 72-hour rule.
| Who | When | Condition | Article |
|---|---|---|---|
| Supervisory authority | Without undue delay and, where feasible, within 72 hours of becoming aware | Unless the breach is unlikely to result in a risk to people's rights and freedoms. Give reasons if you are late | 33(1) |
| You, from your processor | Without undue delay after the processor becomes aware | Always, when the breach affects data the processor handles for you | 33(2) |
| The people affected | Without undue delay | When the breach is likely to result in a high risk to them | 34(1) |
| Your own records | At the time | Every breach, whether or not you notify | 33(5) |
You may skip the message to individuals if the data was unintelligible to others (for example strongly encrypted), if you took follow-up measures that make the high risk unlikely to materialise, or if contacting each person would take disproportionate effort. In that last case you must communicate publicly or in a similarly effective way (Article 34(3)). The authority can also require you to tell people (Article 34(4)).
#What must the authority notification contain?
Article 33(3) lists four items as a minimum:
- The nature of the breach, including, where possible, the categories and approximate number of people and of records concerned.
- The name and contact details of your data protection officer or another contact point.
- The likely consequences of the breach.
- The measures taken or proposed to deal with it, including to reduce its possible harm.
If you cannot provide everything at once, Article 33(4) lets you provide the information in phases without undue further delay. The EDPB's guidelines say approximations are acceptable and should not delay the notification, and that you should tell the authority when information will follow.
Most authorities provide their own online form. Use the template below to prepare your answers, then copy them into the form.
#Template A: notification to the supervisory authority
Subject: Personal data breach notification, [Company name], reference [internal reference]
1. Who we are. [Company name], [registered address], [registration number if any]. Controller or processor: [controller / processor].
2. Contact point (Article 33(3)(b)). [Name, role], [email], [phone]. Data protection officer, if appointed: [name and contact].
3. Dates. The breach occurred or began on [date and time, or "unknown"]. We became aware of it on [date and time]. This notification is sent on [date and time]. If more than 72 hours have passed, the reasons for the delay are: [reasons].
4. Nature of the breach (Article 33(3)(a)). Type: [loss of confidentiality / loss of integrity / loss of availability]. What happened: [short factual description: for example, an email containing a customer list was sent to the wrong recipient]. Cause, if known: [cause]. Is it still ongoing: [yes / no].
5. People and data concerned. Categories of people: [customers / employees / website visitors / other]. Approximate number of people: [number or range]. Categories of data: [names, email addresses, passwords, payment details, health data, other]. Approximate number of records: [number or range]. Was the data encrypted or otherwise protected: [details].
6. Likely consequences (Article 33(3)(c)). [For example: risk of phishing, identity theft, financial loss, loss of confidentiality, distress.] Our assessment of the risk to the people concerned is [risk / high risk], because [reasons].
7. Measures taken or proposed (Article 33(3)(d)). Taken: [for example, password reset, access revoked, recipient asked to delete the email and confirm]. Proposed: [next steps and dates].
8. Communication to the people concerned. [They have been informed on [date] / they will be informed by [date] / we have decided not to inform them because [reason under Article 34(3)].]
9. Other parties. Processors or vendors involved: [names]. Other authorities notified: [names]. Other countries concerned: [countries].
10. Further information. We have not yet established [missing information] and will send an update by [date] (Article 33(4)).
#Template B: message to the people affected
Article 34(2) requires the message to describe the nature of the breach in clear and plain language, and to include at least the contact point, the likely consequences and the measures taken or proposed. The EDPB adds that you should give specific advice on how people can protect themselves, send the message on its own and not inside a newsletter, and avoid using a channel that the breach may have compromised.
Subject: Important: a security incident affecting your personal data
Dear [First name],
We are writing to tell you about a security incident that affects some of the personal data we hold about you.
What happened. On [date], [plain description: for example, "an unauthorised person gained access to our customer database" or "an email was sent to the wrong recipients"]. We found out on [date] and acted immediately.
What information was involved. [List: for example, your name, email address and order history.] [State clearly what was not involved: for example, "Payment card details and passwords were not affected."]
What this could mean for you. [Plain description of the likely consequences: for example, "You may receive emails that pretend to come from us and ask for your password or a payment. We will never ask for these by email."]
What we have done. [Measures: for example, closed the access, reset passwords, informed the authority, asked the recipient to delete the email, added extra checks.]
What you can do. [Specific steps: for example, change your password on our service and anywhere you reuse it, turn on two-factor authentication, be careful with unexpected messages, check your bank statements.]
Who to contact. If you have questions, contact [name, role] at [email] or [phone]. We are sorry this happened and will keep you informed if we learn anything that affects you.
[Company name]
Write in the language your customers use. Keep it short, factual and free of legal terms, and do not minimise the problem. Do not write "we take your privacy seriously" in place of the facts.
#Template C: internal incident log
Article 33(5) requires you to document every breach, including the facts, the effects and the remedial action, in a way that lets the authority verify your decisions. Copy these fields into a spreadsheet or your incident register.
| Field | What to write |
|---|---|
| Reference | A unique number, such as 2026-001 |
| Date and time the breach occurred | Or "unknown", with the period if known |
| Date and time you became aware | Starts the 72-hour clock |
| Who found it, and how | Name, role, how it was detected |
| What happened | Facts only, in plain words |
| Type | Confidentiality, integrity, availability, or a mix |
| Data concerned | Categories, and whether any are sensitive |
| People concerned | Categories and approximate number |
| Processors or vendors involved | Names, and the date each told you |
| Containment actions | What you did, who did it, when |
| Risk assessment | No risk, risk or high risk, with the reasons |
| Decision on the authority | Notified (date and time) or not notified (reason) |
| Decision on the people affected | Informed (date and method) or not informed (reason) |
| Likely consequences | For the people concerned |
| Remedial measures | Short-term fixes and lasting changes |
| Lessons learned | What will change, owner and date |
| Closed on | Date, and who approved |
Privacyboard's incident register records similar details and shows the notification deadline of each country you serve. A spreadsheet works too, as long as you fill it in at the time and not weeks later.
#Mistakes to avoid
- Waiting for a complete picture. The law allows phased information. A partial notification on time is better than a complete one late.
- Guessing and presenting it as fact. Say "we believe" or "approximately" and update later.
- Hiding the practical advice. People need to know what to do, such as changing a password, more than they need the history.
- Using the breached system to send the message. If email accounts were compromised, use another route.
- Forgetting the processor. If a vendor caused the breach, its notice to you starts your own clock when you become aware, and your contract should set a short delay for it.
- Not recording the "no". If you decide not to notify, write down why. The register must be able to show that decision.
#A note on the proposed rule changes
In November 2025 the European Commission proposed changes to the GDPR in its Digital Omnibus package (COM(2025) 837). For breaches, it would raise the notification deadline from 72 to 96 hours and limit notifications to the authority to breaches likely to result in a high risk, with a single entry point for reporting. According to the European Parliament's legislative tracker, it is still a proposal and has not been adopted. Until it is and takes effect, the rules in Article 33 above apply. Check the current text before you rely on any change.
#FAQ
#What should a data breach notification to the authority include?
At least the nature of the breach with the approximate number of people and records, the contact point, the likely consequences and the measures taken or proposed (Article 33(3)). Add the dates you became aware and notified.
#What should I tell customers after a data breach?
Describe what happened in plain language, what data was involved, what it could mean for them, what you have done, what they can do and who to contact (Article 34(2) and the EDPB guidelines). Send it directly and promptly.
#Can I send the notification before I know everything?
Yes. Article 33(4) allows the information to be provided in phases without undue further delay. Say what you do not yet know and when you will update.
#Do I need to notify if I only have a suspicion?
The 72 hours run from when you are aware, meaning you have a reasonable degree of certainty that a security incident has compromised personal data. You should investigate straight away, and a short initial investigation is accepted.
#Who sends the notification if a vendor caused the breach?
The vendor, as processor, must tell you without undue delay (Article 33(2)). You, as controller, remain responsible for notifying the authority, although the processor can do it on your behalf if you authorise it.
#Sources
- Regulation (EU) 2016/679 (GDPR), Articles 33 and 34, EUR-Lex
- EDPB Guidelines 9/2022 on personal data breach notification under the GDPR, version 2.0
- EDPB: Data breaches, guidance for small businesses
- European Parliament Legislative Train: Digital Omnibus Regulation proposal
- EDPB-EDPS Joint Opinion 2/2026 on the Digital Omnibus proposal
Privacyboard is a guidance tool, not legal advice. This article explains general rules in plain language and was accurate on the date above; laws and guidance change. For an unusual situation, ask a qualified professional. Spotted a mistake? Write to antoine@unmake.io.