Freelancers, GDPR, Virtual Assistant

What To Do If You Have a Data Breach

Annabel Kaye
data breach picture of coffee with the words data breach

A data breach can feel like your biggest nightmare. When something goes wrong with client data, it’s easy to imagine the worst. But not every incident is a disaster — and very few need to be reported to the ICO.

Let’s look at what actually counts as a reportable data breach under UK GDPR and what to do, calmly and professionally, if it happens to you.

What is a “data breach”?

A personal data breach is any security incident that leads to the loss, alteration, unauthorised disclosure or access to personal data — whether accidental or deliberate.

That could mean:

  • Sending an email to the wrong person.
  • Losing a USB stick or laptop containing client information.
  • Forgetting to BCC a mailing list.
  • An online system being hacked.

The key question isn’t “Did something go wrong?” but “Could this incident harm someone whose data was involved?”

When you must report a data breach to the ICO

Under UK GDPR, you only have to report a breach if it’s likely to result in a risk to people’s rights and freedoms — for example, identity theft, financial loss, discrimination, or serious distress.

You must report to the ICO within 72 hours if:

  • Sensitive or financial data has been exposed.
  • There’s a realistic chance of harm to anyone affected.
  • You can’t contain the incident quickly or completely.

You’ll also need to tell the people affected if the risk to them is high.
If you’re unsure whether your situation qualifies, that’s when a short, calm assessment makes all the difference.

How to assess the risk from a data breach

Working out whether a breach is serious enough to report isn’t always simple.
The ICO expects you to assess how likely it is that the incident could harm anyone’s rights or freedoms — not just whether a mistake occurred.

When you’re assessing risk, think about three things:

  1. What personal data was involved?
    • Names and contact details are usually low risk.
    • Financial or special category (health, children’s) data increase risk fast.
    • Partial information — like the last four digits of a card number — rarely allows fraud on its own, but might make phishing easier.
  2. Who could access it — and for how long?
    • Was it one person by accident, or could many people see it?
    • Was it behind a login, or public on the web?
    • How quickly did you contain the problem?
  3. What could realistically happen next?
    • Could the data be used to impersonate or target someone?
    • Might it cause embarrassment or distress?
    • Or is the risk limited to minor inconvenience?

Example: a caching glitch in an online store

Imagine a shopping cart system that, for a single day, showed each new purchaser the previous customer’s order summary — name, email, address, and the last four digits of their card.
No full payment details were exposed, and the site was taken offline within hours.

That incident sounds alarming, but it’s a low-risk breach.
The data was limited, the number of people affected was tiny, and the likelihood of harm (such as identity theft or fraud) was minimal.
It should be logged and fixed — but doesn’t need to be reported to the ICO.


Example: an email sent without using BCC

Now compare that with an all-too-common mistake: sending a client update or newsletter and forgetting to use BCC.
Suddenly every recipient can see everyone else’s email address.

If that’s a small business network, risk is low.
But if the list includes vulnerable individuals — for example, clients in therapy, education, or health — it could be reportable, because it might expose someone’s identity or situation in a harmful way.

The key is to look beyond the error itself and ask, “What could actually happen because of this?”
That’s the heart of GDPR’s “risk to rights and freedoms” test — and it’s what turns panic into professionalism.

When you don’t need to report a breach

If the data involved was low-risk — for example, internal contact details or information that was already public — you don’t need to report it.
You still need to record what happened and how you handled it, but there’s no need to contact the ICO.

Typical non-reportable examples include:

  • An email sent to the wrong person who immediately confirms deletion.
  • Access to a password-protected document by a trusted associate who shouldn’t have seen it but didn’t copy or share it.
  • A file briefly shared to the wrong folder but removed within minutes.

The ICO actually encourages you not to report trivial incidents — over-reporting only slows down genuine investigations.

What to do immediately after a data breach

Even if it’s minor, take these steps as soon as you realise something’s gone wrong:

  1. Contain it. Stop the data from spreading or being accessed further.
  2. Assess it. Identify what data was involved and who might be affected.
  3. Record it. Log what happened, when, and what you did next — even if you don’t report it.
  4. Decide if it’s reportable. Use the ICO’s self-assessment tool if you’re unsure.
  5. Learn from it. Update passwords, tighten procedures, and train your team or associates.

A quick, documented response shows professionalism — and can make the difference between a minor hiccup and a reputational problem.

When in doubt, don’t panic — check it out

If you’re unsure whether what happened in your business counts as a reportable data breach, you’re not alone.
Many freelancers and small-business owners over-report to the ICO simply because they want to do the right thing — but that’s not always necessary.

If you’d like to talk it through before you lose sleep over it, you can book a quick GDPR chat here:
Book a chat