Listen to this post: How to Handle Data Breaches and Communicate With Users (UK Playbook)
A data breach doesn’t arrive like a calendar invite. One minute, your service feels normal, the next your users are staring at a locked account, a password reset they didn’t request, or a bank alert that makes their stomach drop. For them, it’s personal. It’s sleep lost, money worry, and that nagging thought: “What else do they know about me?”
A data breach is when personal data is accessed, changed, lost, or shared without authorisation.
This guide gives you a calm, step-by-step plan: stop the damage, keep a clean record (even when you’re stressed), meet UK GDPR duties including the ICO’s 72-hour window, and communicate in a way that protects trust rather than burning it.
First hour actions: stop the leak and start a clean record
In the first hour, you’re not writing the user email yet. You’re trying to stop the bleeding and get your facts straight. Two things can be true at once: you must move fast, and you must not trample evidence.
Also, remember this: the reporting clock starts when you become aware of the breach, not when the breach began. That moment of awareness should be logged like a timestamp in wet cement.
Start a simple incident record immediately (a shared doc works). Capture: who spotted it, when, what systems, what you did, and why. Even if you later decide it’s not reportable, UK GDPR expects you to keep a breach log. The ICO also stresses breach response and monitoring as part of accountability, see the ICO’s breach response and monitoring guidance.
Contain and preserve evidence without making it worse
Think of containment like closing doors in a smoky building. You don’t smash every wall; you control where the fire can go.
Practical first steps for a small to mid-size team:
Isolate what’s affected: take the compromised server, database, or cloud resource off the network segment where it can do harm. If you can, quarantine rather than power off.
Rotate access fast: reset admin passwords, rotate API keys, revoke active sessions, and rotate database credentials. If you use SSO or IAM roles, tighten them now.
Disable risky pathways: pause compromised integrations, disable suspicious accounts, and temporarily block unusual geographies or IP ranges if you have a clear signal.
Protect logs: make read-only copies of key logs (auth logs, audit trails, WAF logs, cloud activity logs). Store them somewhere restricted.
Common mistakes to avoid:
- Wiping servers “to be safe”, then realising you’ve destroyed the timeline.
- Applying lots of changes without noting them, then later you can’t explain what happened.
- Letting everyone “help” in production without one owner controlling actions.
Assign clear roles, even if it’s just three people: one technical lead, one comms lead, one decision maker. If you don’t have in-house expertise, call your incident response vendor early. Waiting doesn’t make the hourly rate cheaper.
Quick impact check: what data, how many people, what harm is realistic
This is the early risk picture. It won’t be perfect, but it must be honest.
Ask three plain questions:
What data was involved? Names, emails, phone numbers, addresses, password hashes, payment data, support tickets, ID documents, health info.
How many people might be affected? Use ranges if you must (for example, “up to 12,000”). Don’t invent precision.
What harm is realistic? Put yourself in a user’s shoes. Could this lead to:
- Account takeover (especially if passwords or session tokens are exposed)?
- Identity fraud (address, date of birth, ID scans)?
- Financial loss (bank details, payment cards, invoice fraud risk)?
- Safety risks (location data, domestic abuse contexts, stalking concerns)?
Call out high-risk data types early: passwords, payment data, and health data tend to raise urgency because the harm is clearer and faster.
Check third-party involvement straight away. If the incident touches a processor (email provider, CRM, analytics, payment platform), it affects speed and clarity. You may need their logs, their scope, and their timeline to avoid sending users vague or wrong claims.
Legal and policy duties in the UK and EU: who to notify and when
This section is not legal advice, but it’s a reliable map of the decision path.
Under UK GDPR, you’re balancing two duties: protect people from harm, and show accountability. If the breach is likely to risk people’s rights and freedoms, you usually need to notify the ICO within 72 hours of becoming aware. If the risk to individuals is high, you must notify affected users without undue delay.
You also need to keep a breach log for all incidents, even the ones you don’t report. The ICO maintains and updates guidance, and you can track what’s changing via the ICO’s plans for new and updated guidance.
As of January 2026, there’s public discussion about UK reforms that could move reporting to 96 hours and raise the reporting threshold, but these changes are not confirmed. For a current overview of proposals and direction, see Osborne Clarke’s UK data law outlook (Jan 2026).
When you must tell the ICO, and what details they expect
If you need to report, the ICO generally expects a clear set of basics. You can send details in phases if facts are still emerging, as long as you don’t stall.
A simple checklist of what to prepare:
| ICO report field | What “good” looks like |
|---|---|
| What happened | Brief timeline, how you detected it, suspected entry point |
| Data categories | Types of personal data, sensitivity level |
| Approx number affected | Best estimate, with ranges if needed |
| Likely impact | Real harms, not abstract “risk” language |
| Actions taken | Containment, resets, monitoring, user protections |
| Contact point | DPO or incident contact, monitored inbox/phone |
Don’t wait for a perfect story. Send what you know, label what you don’t, and commit to an update date.
When you must tell users, and when you might not need to
User notification is triggered when the breach is likely to result in a high risk to individuals. Put simply: if a reasonable person could be seriously harmed, they should hear it from you quickly, not from social media.
There are exceptions in some cases. Strong encryption, properly implemented, can reduce risk enough that user notification may not be required. But “not required” is not the same as “say nothing”. Silence without a clear reason often breaks trust more than the breach itself.
If you’re unsure, document your reasoning. If the ICO asks later, a clean decision trail is your best friend.
How to communicate a breach to users without losing trust
A breach message is not marketing copy. It’s closer to a fire alarm: clear, loud enough, and focused on what people must do next.
The tone that works is calm and direct. You can be human without being casual. Avoid panic, but don’t polish it until it feels unreal.
Timing matters. Users judge you on how long they felt exposed without knowing. If you wait until you have every detail, you’ll often wait too long. If you rush and guess, you’ll have to correct yourself, and corrections feel like cover-ups even when they’re not.
Set up one reliable place for updates (a public incident page) and keep it current. Then push affected users to it from direct channels. People want one point of truth, not five different versions.
Also, don’t blame users. Even if password reuse played a part, your job is to reduce harm, not score points.
For practical consumer-facing steps that align with good breach messaging (clear actions, account protection), the UK’s National Cyber Security Centre has widely used advice in the “stop the spread” style guidance, and legal firms also publish comms lessons after major incidents. For a UK 2026 view on incident lessons and patterns, see Slaughter and May’s cyber lessons for 2026.
Write the first message: what to say, what to avoid, and a simple structure
Users read breach emails like they read a medical test result. Fast, tense, scanning for danger.
Use this structure:
- What happened, in one or two sentences, and when you found out (not a long technical story).
- What information was involved, or what you are still checking, with a realistic time for confirmation.
- What you’ve done to secure systems (session resets, key rotation, forced password resets).
- What users should do now, in plain steps (change password, enable MFA, watch for phishing).
- How to get help (a dedicated email, phone line, and support hours).
- When the next update is coming (a date and time window).
A few words and phrases to avoid because they create anger or confusion:
- “We take your privacy seriously” (it reads like a template)
- “May have been affected” with no context (explain what is known and unknown)
- Heavy legal language that hides meaning (people want clarity, not clauses)
- “No evidence of misuse” as a comfort blanket (say what monitoring you’re doing)
If you need to apologise, do it once, plainly. Then move to actions. Action is what reduces fear.
Choose channels and timing: email, in-app, SMS, public page, and support lines
Match the channel to the risk and urgency.
Email works for most breaches, but only if users can trust it’s real. Expect phishing copycats within hours. Tell users what you will never ask for (for example, “we won’t ask for your password”).
In-app banners help when users are already logged in and you need them to take a step, like enabling MFA.
SMS is for urgent account takeover risk, but keep it short and avoid links if possible. If you must use a link, keep it consistent and predictable.
A public incident page is your running log. It should include timestamps, what changed, what users need to do, and what you’re investigating.
Prepare your support lines before you notify. Brief your team with a simple script: what happened, what to tell users to do, what you can’t yet confirm, and where to escalate vulnerable cases (for example, users facing stalking risk, or those locked out of accounts tied to income).
Other regions are pushing faster notice rules (California is often cited), but for UK teams the key is still meeting UK GDPR expectations while protecting users quickly.
After the dust settles: reduce repeat risk and rebuild confidence
When the breach quietens down, the real work starts. Attackers often come back, either because the same weakness remains or because stolen data is now being used for follow-on fraud.
Start with the uncomfortable question: what made this easy for them?
Recent breach patterns often involve stolen credentials and third-party access, so don’t limit fixes to one server. Look at identity, suppliers, and monitoring.
A strong recovery plan has two outputs: better security and visible proof for users.
Fix the root cause, then prove it with simple changes users can see
Security work that helps straight away:
- Force password resets where credentials or hashes may be exposed, and force logouts across devices.
- Roll out MFA (prioritise admins and high-risk users first).
- Rotate signing keys, API keys, and secrets, then audit who can create or read them.
- Patch the exploited weakness, then confirm with scanning and targeted tests.
- Tighten least privilege, especially for support tools and vendor accounts.
- Review supplier controls and incident clauses. If they were part of the chain, your users won’t care whose fault it was.
User-facing proof points matter more than most teams think:
- A refreshed security page that lists what changed.
- Clear account activity alerts (new device login, password change, payout change).
- A simple timeline of improvements, written in plain English.
If enforcement risk is part of your planning, keep an eye on how the ICO approaches investigations and procedure. For context on the direction of travel, see ICO enforcement procedure consultation coverage.
Run a blameless review and update your breach plan for next time
A breach is already expensive. Don’t waste it by learning nothing.
Keep the review blameless and specific. Focus on decisions and systems, not personal blame.
Capture:
- What detection caught, and what it missed
- The slow points (approvals, access, missing contacts)
- The comms timeline, including user confusion themes from support tickets
- Which templates worked, and which created more questions
- Training needs for on-call, support, and leadership
Then run a short tabletop exercise within the next quarter. It’s the cheapest way to get faster and calmer next time, because there will be a next time.
Conclusion
A breach is a trust test under pressure. Users won’t judge you on perfect systems, they’ll judge you on what you did when things went wrong.
The promise to keep is simple: contain quickly, assess real risk, notify the ICO when required, tell users clearly and with care, keep updating as facts change, then fix the gaps so it doesn’t repeat. If your team can do those things, the incident becomes a hard day at work, not a lasting scar on your reputation. What would your current breach message sound like if you had to send it tonight?
