top of page
Search

The Case for Confidence in Defensive Breach Reporting

ree


When something goes wrong, most of us would rather over-report than under-report. It feels safer, especially in high risk domains where trust is fragile and the impact can be significant.


But the ICO is clear: defensive reporting isn’t good practice, and defensive notification to individuals can cause real harm.


This post is about staying inside the legal thresholds, and staying confident in our decisions.


A practical lens for assessing harm


Before we get into thresholds, it’s worth naming a few real-world factors that help us think clearly about potential harm. In practice, I often consider:


  • Does the data subject know the inadvertent recipient? If they do, that can increase the impact (for example where relationships are strained, there’s a safeguarding concern, or power dynamics are involved).

  • How sensitive or stigmatised is the data? The same breach can be low-risk in one context and high-risk in another. A missed appointment reminder isn’t the same as a disclosure involving mental health, sexual health, domestic abuse, or immigration status.

  • Is the inadvertent recipient acting in good faith? Someone who notifies you promptly, confirms deletion, and seems trustworthy materially reduces likelihood of harm.


These are certainly some of my go-to explorations around likely impact.


The legal thresholds are risk-based


UK GDPR requires controllers to make two separate decisions after a personal data breach.


1) Report to the ICO only if risk is likely

You report a personal data breach to the ICO when it is likely to result in a risk to individuals’ rights and freedoms.

If your assessment concludes it is unlikely to create risk, you don’t report, but you must still record the breach and your reasoning internally.


2) Tell individuals only if high risk is likely

Communication to data subjects is required only where the breach is likely to result in a high risk to them.

This is a deliberately higher bar than ICO reporting.


What does the ICO say?


ICO guidance is explicit that there are times we would report to them without telling the person affected. That can feel counter-intuitive, and in the real world it often plays out the other way around - especially when teams worry a data subject might later complain.


As the ICO puts it:

“The threshold for informing data subjects is higher than for informing the ICO.”

Across published ICO case examples, the same principle shows up again and again:


  • If your assessment finds that risk to the individual is unlikely, the breach does not need to be reported to the ICO.

  • If there is no high risk, individuals do not need to be told.

  • Your main obligation becomes documenting what happened, your rationale, and the safeguards put in place.


A common pattern looks like this:


A controller concludes risk to Patient B is unlikely (thanks to swift recovery actions and low exposure), but reports to the ICO anyway “just in case the patient complains later.”


The ICO’s stance is essentially:

Don’t report on a hypothetical future complaint. If your assessment says “unlikely,” stand by it, and log it.


Why unnecessary notification can be harmful


The ICO explicitly warns against informing individuals about low-risk breaches because:


  • it can cause unnecessary worry and distress, and

  • repeated minor notifications can lead to breach fatigue, reducing the impact of communications when something genuinely serious occurs.


In healthcare, that harm is amplified. Even a small confidentiality slip can feel frightening or shame-inducing to a patient, especially where the data is sensitive.


So we should avoid adding avoidable anxiety when the real-world risk is negligible.

Certainly, as DPO for a large number of healthcare providers, we always include the question:


Will notifying the person cause more harm than the incident itself?

That’s not an excuse to stay silent where notification is required, it’s a reminder that notification is not a neutral act. It has consequences of its own and requires context.


Documentation is what protects you, not over-reporting

The accountability duty is your safety net.


If you decide not to report, record:


  • what happened and what data was involved,

  • your likelihood/severity risk assessment,

  • why risk was unlikely,

  • mitigations already taken, and

  • what you’ll change to prevent recurrence.


Then, if a complaint arrives later, you can show the ICO that:

  • you assessed properly at the time,

  • you didn’t ignore risk, and

  • you were proportionate and evidence-based.


That is exactly what the ICO expects from a competent controller.


A quick “confidence checklist” for DPOs

Before reporting or notifying, ask:


  1. Is there personal data involved?

  2. What’s the realistic harm pathway to the person?

  3. How likely is harm, given mitigations already in place?

  4. Is this risk likely (ICO reporting) or high risk likely (patient notification)?

  5. Have we logged our decision clearly?


If the answer to #4 is “no,” don’t report defensively.

Document confidently.


In Summary


Over-reporting feels like a mitigator in the moment. But unnecessary reporting and notification can:


  • distress data subject without benefit,

  • normalise “breach alerts” until they stop landing, and

  • reduce trust in the organisation’s judgement.


The ICO’s message is not “report less.” It’s “report proportionately, and take responsibility for well-reasoned decisions.”


Emma Kitcher, Privacy Nerd
Emma Kitcher, Privacy Nerd

 
 
 

Comments


00011-2939233035.png

DID YOU FIND THIS USEFUL?

Join our mailing list to get practical insights on ISO 27001, AI, and data protection; No fluff, just useful stuff.

You can unsubscribe at any time. You are welcome to read our Privacy Policy

bottom of page