A breach notification is not a press release, and it is not an apology. It is a document with a legal audience, a fixed deadline, and a specific job: to give a regulator or an affected person enough information to act. Drafted badly, it invites fines and follow-up questions. Drafted well, it is short, factual, and quietly reassuring. Here is how to get there, step by step.
Two letters, two audiences, two legal bases
The most common drafting mistake is treating "the breach notification" as one document. Under the GDPR it is two, and they do different work.
The supervisory authority notification comes from Article 33. It is required unless the breach is unlikely to result in a risk to people's rights and freedoms. Its reader is a case handler who wants to assess risk, verify that you have a lawful process, and decide whether to open a file.
The data subject notification comes from Article 34. It is required only when the breach is likely to result in a high risk — a higher threshold than the regulator notification. Its reader is a person who may be about to be defrauded, impersonated, or embarrassed, and who needs to know what to do next.
You can owe one without the other. A ransomware attack on an encrypted, well-keyed database might be reportable to the authority but not to individuals. A misdirected email containing a customer's medical note might be reportable to the individual and, depending on scale and sensitivity, to the authority. Decide which letters you owe before you start writing either.
The 72-hour clock, and when it actually starts
The clock starts when you become aware of the breach — not when the forensic report lands. In practice, that means the point at which you have a reasonable degree of certainty that a security incident has led to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of personal data. A vague tip from a third party is not awareness. A confirmed exfiltration is.
You then have 72 hours to notify the supervisory authority. Processors must notify their controller "without undue delay," which in most cases should be considerably faster, because the controller is the one carrying the deadline.
Three practical points:
- Late notification is permitted, but you must explain the delay. A short, honest reason beats a fabricated timestamp.
- You do not need the full picture. Notify with what you know, flag the gaps, and supplement later. Regulators generally prefer a partial notification on time to a complete one on day twelve.
- Document every breach, including ones you decide not to report. Article 33(5) requires an internal breach register, and it is the first thing an investigator asks for.
If you operate in several EU countries, check whether you file with a lead supervisory authority under the one-stop-shop or with each national regulator. That decision belongs with your data protection officer or outside counsel, not with whoever happens to be on call.
What the supervisory authority notification must contain
Article 33(3) sets out four content requirements. Write them as headings in your own document so nothing gets missed:
- Nature of the breach. What happened, when it was discovered, and the categories and approximate numbers of data subjects and records involved. Approximate is acceptable; "we don't know yet" is not, unless accompanied by a range and a date for the update.
- Contact point. Name and details of your data protection officer or another person who can answer follow-up questions.
- Likely consequences. What harm could realistically follow — identity fraud, account takeover, reputational damage, discrimination.
- Measures taken or proposed. Containment, password resets, key rotation, notifying police, and any steps offered to affected individuals.
Add a brief description of your organisation and, if relevant, the cross-border dimension. Keep the tone neutral. Anything you write here can be read back to you later, so avoid speculation dressed up as fact.
Writing the Article 34 letter to individuals
Article 34 requires "clear and plain language." That rules out phrases like "as a result of an unauthorised access event affecting a subset of our data environment." You are writing to someone who may be worried, so lead with the substance.
"We are writing to tell you about a data breach at [Company] that affected some of your personal information. We are sorry this happened. Below is what we know, what we are doing, and what you can do."
A workable structure
- A subject line that says plainly what the email is. Avoid cryptic internal codes and avoid wording that looks like phishing.
- What happened, in one short paragraph. Date of the incident, date of discovery, what kind of attack or error.
- What data was involved. Be specific. "Your name, email address and hashed password" is useful; "some of your information" is not.
- What this could mean for them. Honest, proportionate, and without catastrophe.
- What you have already done. Containment, notification to the regulator, security changes.
- What they can do. Concrete, checkable steps: change this password, watch for these emails, contact this bank.
- Who to contact. A named function, a working email address, a phone line, and the hours it is staffed.
- Where to find updates. A stable page or helpline, so they do not need to re-read the letter later.
Remember the exemptions. You need not write to individuals if encryption or another measure has made the data unintelligible, if subsequent steps mean the high risk is no longer likely to materialise, or if individual notice would involve disproportionate effort — in which case a public communication may be required instead. Those judgments are worth recording in writing, with reasons.
Tone, timing, and the mistakes that cause trouble
Send the data subject letter without undue delay. Waiting for a polished final version while people remain exposed is worse than sending a clear early one and following up.
Frequent faults: blaming the attacker rather than explaining your own response; burying the contact details on page three; promising that "no harm will come of this"; using legal boilerplate in a letter meant for the public; and copying the regulator filing into a customer email. Avoid all five. Also avoid the sentence "we take your privacy seriously" as a substitute for an actual explanation.
Before you hit send
Read the letter aloud. If you stumble, rewrite the sentence. Then check four things: the deadline, the contact details, the accuracy of every factual claim, and whether anyone named in the letter has consented to being named. Save the draft, the reasoning behind it, and the version you sent — the breach register should tell the same story a year from now.
This is a technical and legal area where the details matter, and thresholds such as "risk" and "high risk" are often arguable. For a serious incident, involve your data protection officer or a qualified privacy lawyer before you file. Getting the letter right is far cheaper than explaining it afterwards.
Photo: hudsoncrafted / Pixabay
