How to Respond to a Data Breach: A Cheat Sheet For Scale-ups

When a data breach hits, the damage isn't decided by the breach alone. It's decided by what happens in the hours afterwards.

Trust Keith’s Head of Privacy, Kayleigh Logan-Cleghorn, and Account Executive, Lauren MacEwan, recently sat down to talk through everything you need to get right before, during and after a data breach. This guide pulls together their advice into a practical breach response playbook, and you can watch the full session here.

Free Download | Data Breach Policy Template

The worst time to write your breach plan is mid-breach.

Who to tell, who investigates, when the ICO needs to know and how to log every incident. Written for scale-ups and ready to make your own.

Download the free template

What we'll cover:

• What counts as a personal data breach?
• What to do in the first hours after a data breach
• When to report a data breach to the ICO
• What to do if you're a processor
• When to tell the people affected
• How to communicate during a breach: lessons from ASOS
• Who should own breach response if you don't have a DPO?
• How to prepare for a data breach before it happens
• How to review a breach without turning it into a witch hunt
• Common questions about data breach response
• Key takeaways

What counts as a personal data breach?

You can't respond properly until you know what you're dealing with. Under UK GDPR, a personal data breach is a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

A quick way to test it is the CIA triad: has the confidentiality, integrity or availability of personal data been compromised? If any one has, you're likely looking at a personal data breach.

That catches more than people expect:

• A curious employee looking up records they have no reason to see. A clinic receptionist checking a famous patient's medical file is a breach, even if they never share it.
• An accidentally deleted mailing list. Nobody stole anything, but the data is lost, so availability has been compromised.
• A spreadsheet with the names removed. Job titles and salaries can still point to real people.

"You might have 12 administrative officers, but you've almost definitely only got one CFO, or one data protection lead, or one CEO. That means you are immediately going to be able to identify who that individual is and match their salary to them."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Removing names makes data de-identified, not anonymous. If a unique role, staff number or unusual detail points back to someone, it's still personal data.

Security incident vs personal data breach

Not every incident is a personal data breach. If attackers steal product designs and technical plans with no personal data involved, that's a serious security incident, but your UK GDPR breach obligations don't apply.

"Not every security incident is a personal data breach, but every personal data breach is a breach of security in some way."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Kayleigh's favourite example: when Princess Leia steals the Death Star plans, that's a major security incident for the Empire. But if those files also held stormtrooper personnel records or an open HR investigation, it's a personal data breach too, and the Empire suddenly has notification decisions to make.

What to do: Make "was any personal data involved, and could it identify someone?" the first question in your breach process. The answer decides which route you follow.

What to do in the first hours after a data breach

The clock starts the moment your organisation becomes aware of a breach. Here's how to use that time well.

1. Trigger your breach process

Get your named breach coordinator involved straight away, along with IT and anyone else your plan says needs to know. Don't wait until you're certain it's a breach. Suspected breaches go through the process too.

2. Contain it

Stop the damage spreading. Revoke access, reset compromised credentials, recall misdirected emails, restrict affected systems. If data can be recovered, recover it.

3. Gather as much information as you can

You won't have a complete picture quickly, and that's normal. Focus on what you need to judge severity: what data was involved, how many people, how sensitive it is, and what could happen to them as a result.

4. Assess the risk to the people affected

This is the question that drives every decision after it.

"The assessment you need to be doing is: based on the information that I have, are the rights and freedoms of that individual going to be impacted? And if they are, or if you think they're likely to be, then you should report to the regulator."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

5. Decide who needs to know

The ICO, your customers (if you're a processor), the individuals affected, or nobody outside the business. More on each of these below.

6. Record everything

What happened, what you found, what you decided and why. This applies whether or not you report.

The ICO has a useful 72-hour guide for small businesses that follows the same logic if you want a second reference point.

Free Monthly Session | Trust Keith Office Hours

Not sure if it's a breach? Ask someone who's handled hundreds.

Bring your trickiest data protection questions to a privacy expert, live and for free. No sales pitch, just straight answers.

Save your spot

When to report a data breach to the ICO

You must report a personal data breach to the ICO if it's likely to result in a risk to people's rights and freedoms. The deadline is without undue delay and, where feasible, within 72 hours of becoming aware of it, under Article 33 of UK GDPR.

Three things teams often get wrong:

1. It's 72 real hours, not working hours. Find out on Friday afternoon and your deadline is Monday afternoon.

2. The clock starts when the organisation becomes aware. Not when your DPO hears about it, and not when the breach happened. If a supplier tells you about a breach from weeks ago, your clock starts when they tell you.

3. You don't need the full picture before you report.

"It's important to take the proactive step of reporting if you believe there's a good chance that rights and freedoms are going to be impacted, rather than holding it. You can always update the regulator."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

The ICO's breach guidance supports this: report what you know, then follow up as your investigation develops.

What about the borderline calls?

Some incidents genuinely sit on a 50/50. The answer there is documentation.

"Whatever your decision, make sure that it is recorded and that it is justified. Don't just say this is 50-50, don't think we need to report, so we're not going to."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

The final call usually sits with leadership and reflects your risk appetite. Whoever makes it, write down the reasoning and keep it under review as new facts come in.

What to do: Even when you decide not to report, you still need to investigate, record the outcome and put fixes in place. Every breach belongs in your breach log.

What to do if you're a processor

If you're a SaaS company, a third-party logistics provider or any business handling personal data on behalf of customers, you're usually their processor. Your breach response looks different.

The rule is simple: tell your customer (the controller) without undue delay. Every time. Even if you think the risk is low.

"You don't get to decide that the risk is low enough that they don't need to know. You can share your view that the risk is low, but ultimately it's the controller's responsibility to assess the impact on individuals."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

You might see five exposed records. Your customer might know those five people are vulnerable, or were caught up in another incident last month. They need your facts plus their context to make the right call.

What to do: Check your data processing agreements for notification timescales, and make sure your team knows "low risk" never means "don't tell the customer". Don't contact the affected individuals yourself either. That's the controller's decision, and going around them will cause contractual headaches.

When to tell the people affected

The bar for telling individuals is higher than the bar for telling the ICO.

• Report to the ICO when a breach is likely to result in a risk to people's rights and freedoms.
• Tell the individuals when it's likely to result in a high risk, under Article 34 of UK GDPR.

There's no fixed 72-hour deadline for telling individuals. The law says without undue delay, and the urgency should match the risk. Leaked card details are the classic example: people need to know fast so they can cancel cards and watch for fraud.

You can also choose to tell people when the law doesn't require it, for transparency or to manage the situation well. That's a business decision, and often a sensible one.

How to communicate during a breach: lessons from ASOS

On 6 October 2026, ASOS app users received a push notification titled "ASOS HACKED", sent by attackers through the retailer's own app. The NCSC's advisory noted ASOS said names and contact details may have been accessed, but it didn't believe payment card information or passwords were affected.

ASOS got several things right. It restricted access, brought in external specialists, told customers to ignore the rogue link and kept updating them as the picture developed.

It also shows how quickly a breach turns into a communications crisis.

"If your attackers are communicating directly with your customers, they have taken control of that situation and of the narrative, and you want to get it back. Part of your containment is not just containing the breach, it's containing the narrative."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Two lessons for your own breach response:

Get a holding statement out fast. Even if it only says "this message wasn't from us, we're investigating, don't click the link." Hours of silence is a long time for customers to worry and for your brand to take a hit.

Be careful with early reassurances. First assessments are rarely complete, and the picture at ASOS widened as the investigation went on.

"I would always recommend being really cautious about telling people what definitely hasn't been affected until I'm really confident. Use words to the effect of 'our current investigation indicates', and say you will update people as the picture changes."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

There's a longer-term cost too. The breach damaged trust in a channel customers relied on, and phishing that mimics it becomes more convincing. It's also a reminder that many major breaches start with something unglamorous: M&S's 2025 incident reportedly began with someone talking a help desk into resetting a password. Staff awareness training is one of your strongest controls.

Who should own breach response if you don't have a DPO?

You don't need a formally appointed data protection officer to handle a breach well. You do need one named person coordinating the response, and everyone else needs to know who that is.

That person pulls in IT, operations and leadership when needed. In a scale-up they'll probably wear several hats, and that's fine. What matters is knowing who investigates, who decides and who communicates.

Coordinating the response isn't the same as being accountable for it, though.

"Accountability sits with the organisation and with the leadership of your organisation, not with the person who is responsible for your breach process. They are the person who's going to be coordinating the response."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

If you're weighing up whether you need dedicated support, our guide to outsourced vs in-house DPOs walks through the options.

How to prepare for a data breach before it happens

"The worst time to work out how you're going to respond to a data breach is when you're in the middle of one."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Your breach response plan doesn't need to be 40 pages long. It needs:

• Clear responsibilities: who coordinates, investigates, decides and communicates.
• A practical response process: what happens in the first hour, the first day and before the 72-hour deadline.
• Supplier notification arrangements: how your processors will tell you, and how you'll tell your customers if you're a processor.
• A way to record incidents: one log for everything.

Keep your procedure current

People change roles and leave. Check your breach procedure regularly so names and contact details are right, and make sure everyone listed knows they're on it. Finding out you're the breach contact during a breach is nobody's idea of a good day.

Run a tabletop exercise

Pick a scenario, get the right people in a room and talk it through. Does everyone know their role? Where does the process stall? Kayleigh's advice is to treat it like a fire drill, and ideally don't warn people it's coming.

Log everything, including the near misses

Keep a single incident log for every security incident and suspected breach: what happened, what you investigated and what you concluded. Not every incident will be a personal data breach, but each one tells you something about your controls. A well-kept breach log is also one of the first things investors ask about during due diligence.

For more on the incidents that crop up most often, read the most common data protection incidents and how to prevent them.

How to review a breach without turning it into a witch hunt

The final stage of breach response is learning from it. A good review asks why something happened, not who to blame.

"Someone clicked that link, they shouldn't have. But that tells us almost nothing, and it certainly doesn't help us prevent it in the future."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Better questions to ask:

• Was the phishing email particularly convincing?
• Had the person been trained? Were they under pressure, overworked or working at an odd hour?
• Why was one person's mistake enough to compromise the organisation?
• What controls could have stopped it spreading, or spotted it sooner?

The same goes for the most common breach of all: personal data sent to the wrong recipient. Rather than telling everyone to "be more careful", check whether the process makes that mistake too easy.

"Human error is very often the starting point of an investigation, but it shouldn't automatically be the conclusion."

Kayleigh Logan-Cleghorn, Head of Privacy, Trust Keith

Ask what went well, too. Fast comms, a clean escalation, someone who knew exactly what to do. Those are worth capturing and building on.

There's still a place for individual accountability, particularly for deliberate misconduct like snooping on records. But if people think reporting a mistake will get them in trouble, they'll stop reporting, and you'll lose the early warning that keeps small incidents small.

Free Newsletter | Keith's Monthly Hot Takes 🔥

The breaches, fines and phishing scams worth knowing about, once a month.

A quick monthly roundup of what's happening in data protection, what it means for your business and the free resources to help you act on it.

Subscribe for free

Common questions about data breach response

What should you do first after a data breach?

Trigger your breach process, get your named coordinator involved and contain the breach. Then gather enough information to assess the risk to the people affected.

Does the 72-hour deadline include weekends?

Yes. The 72 hours run from when your organisation becomes aware of the breach, regardless of weekends or bank holidays.

What if we can't get all the details within 72 hours?

Report what you know and tell the ICO more information will follow. If you report late, you'll need to explain why.

Do we have to report every data breach to the ICO?

No. Only breaches likely to result in a risk to people's rights and freedoms. You must still record every breach internally, along with your reasoning.

As a processor, do we report breaches to the ICO?

Your obligation is to tell the controller without undue delay. The controller decides whether to report to the ICO and whether to tell the individuals affected.

Do we need a DPO to handle a data breach?

No. You need one named person to coordinate the response, with clear responsibilities agreed in advance. Accountability stays with your leadership.

Key takeaways

• Know what you're dealing with. A personal data breach affects the confidentiality, integrity or availability of personal data, and removing names doesn't make data anonymous.
• Contain first, then assess the risk to the people affected. That assessment drives every decision after it.
• 72 hours means 72 real hours, from when your organisation becomes aware. Report early and update as you learn more.
• Processors always tell the controller, even when they think the risk is low.
• The bar for telling individuals is higher than the bar for telling the ICO.
• Control the narrative. A fast holding statement beats hours of silence, and early reassurances should be cautious.
• Write your plan before you need it, name one coordinator, test it and review breaches to fix the process rather than blame the person.

Curious how Trust Keith can help take breach response off your plate?

Trust Keith pairs a dedicated privacy expert embedded in your business with an intelligent platform that keeps your policies, processes and incident records live and audit-ready. That includes 24/7 breach response, something a SaaS tool alone can't give you. Your compliance, handled, without hiring a team.

Talk to an expert