Personal Data Breach: The 72-Hour Rule in Practice
By CodexierPublished 6 min read
A personal data breach is not only a hack. It is the laptop left on the train, the email with the wrong attachment, the customer list synced to the wrong folder, the backup that turns out to have been public for a year. GDPR gives you 72 hours from becoming aware to report it to IMY if it poses a risk to people, and the clock starts when you become aware, not when you have understood what happened. This guide sets out what to do in those hours, in the order that works.
What counts as a personal data breach
The definition is broad on purpose. It covers confidentiality breaches such as leaks and unauthorised access, integrity breaches such as data being changed, and availability breaches such as ransomware or a lost backup, even if nobody outside saw the data. A misdirected email with one customer's invoice is a breach. Whether it must be reported is the next question, but it is a breach and belongs in the log.
Assessing the risk
The reporting decision turns on risk to the people whose data is involved, not risk to your company. Assess it in writing, quickly, with the facts you have; you can update the assessment later. The factors that matter are the kind of data, how many people, who has it now and what they could do with it.
| Factor | Lower risk | Higher risk |
|---|---|---|
| Type of data | Business contact details, names and emails | Personal numbers, health, finances, login credentials, children's data |
| Who received it | A known, trusted party who confirms deletion | Unknown attacker, public internet, a competitor |
| Protection | Encrypted with keys not exposed | Plain text, or encryption keys also taken |
| Scale and duration | One record, discovered within hours | Whole database, exposed for months |
| Possible harm | Minor annoyance | Fraud, identity theft, discrimination, physical safety |
If the honest answer to any row is the right-hand column, assume you must report to IMY, and consider whether the people affected must be told.
Reporting to IMY within 72 hours
IMY takes reports through an online form, and it accepts a preliminary report that is completed later. That matters, because the most common mistake is waiting for certainty and missing the deadline. Report what you know, say what you do not yet know, and state when you will update. A late report needs a written justification, and a missing one is itself a violation.
- Hour zero: note the exact time and how you became aware. This is the start of the 72 hours.
- First hours: contain the breach. Revoke access, take the system offline, recall the email, change the credentials. Preserve logs before wiping anything.
- Same day: write the risk assessment from the table above and decide whether to report. If in doubt, report.
- Within 72 hours: submit the IMY form with the nature of the breach, categories and approximate number of people and records, likely consequences, measures taken, and a contact person.
- After: update the report as facts arrive, and finish the internal investigation on its own timeline.
Informing affected people
When the breach is likely to result in a high risk to the people affected, you must tell them without undue delay, in plain language, so they can protect themselves. This is separate from the IMY report and is judged on a higher threshold. The exceptions are narrow: the data was unreadable to whoever took it, you have since made the risk unlikely, or individual contact would be disproportionate and a public notice reaches them instead.
What the message must say
What happened, in one paragraph. What data was involved. What could happen as a result. What you have done. What they should do, such as change a password or watch for fraud. Who to contact.
How to send it
Directly, by the channel you normally use with them, from a named person. Not a marketing email template, not buried in a newsletter, and not only a post on the website unless direct contact is impossible.
What to avoid
Legal boilerplate, minimising language, and delay while communications are polished. A clear message sent the same day is worth more than a perfect one a week later.
Your internal breach log
Every breach must be documented internally, including those you decided not to report and why. IMY can ask to see the log, and it is the evidence that you assessed the situation properly. Keep it simple: one entry per incident, in a place the responsible person can find under stress, with no personal data in the log itself beyond what is necessary.
- Date and time of the breach and of discovery, and how it was discovered.
- What happened, which systems and which categories of data and people were affected.
- The risk assessment and the decision on reporting and on informing people, with reasons.
- Actions taken to contain and to prevent recurrence, with dates.
- Who was involved and who signed off.
When you do not need help with this: for a misdirected email or a single lost document, the steps above are a few hours of one person's time, and the template log is enough. Where help matters is the technical incident: a compromised website, credentials in the wrong hands, or a system you cannot tell whether an attacker still has access to. Then the containment and the evidence preservation decide both the outcome and what you can truthfully tell IMY, and that is the work our performance and security optimisation covers, before an incident or during one. It is priced on the pricing page; if something has already happened, book a call today rather than after the investigation.
Frequently asked questions
Does the 72-hour deadline include weekends?
Yes. It is 72 hours from the moment you become aware, whenever that is. A breach discovered on Friday afternoon must be reported by Monday afternoon, which is why the decision process should be written down before it is needed.
What if we are the processor, not the controller?
A processor must inform the controller without undue delay, and the controller reports to IMY. Your data processing agreement usually sets a shorter internal deadline. Notify the controller immediately with what you know; do not wait for your own investigation.
Do we have to report a ransomware attack if no data was stolen?
Loss of availability is a breach, and if you cannot restore data or cannot prove it was not exfiltrated, the risk to people may not be unlikely. Most ransomware incidents affecting personal data are reportable, and the assessment should be documented either way.
What are the consequences of not reporting?
Failure to report, or reporting late without justification, is a violation in its own right that IMY can fine separately from the breach itself. In practice, a timely and honest report with a documented assessment is treated far more favourably than a breach discovered by IMY through a complaint.
Facing an incident, or want to be ready before one?
Fifteen minutes: tell us what happened or what you are worried about, and we will tell you what to contain first, what to log and whether the 72-hour report applies.
Book a free 15-minute call