Incident response

Incident response checklist: the first hour, the 72-hour ICO deadline, and everything after

A phishing link clicked. A laptop left on a train. A supplier breached. Ransomware on a server. When it happens, the first hour decides how bad it gets, and the next 72 decide what you tell the regulator. This is the checklist to work through, in order, with the UK GDPR rules set out plainly.

Updated 21 October 2026Read 12 minutesFor UK organisations of every size

The short version

  • If a breach affects personal data and is likely to put people at risk, you must tell the ICO without undue delay and within 72 hours of becoming aware of it.
  • The clock starts when you are reasonably sure personal data has been affected, not when your investigation ends, and it runs through weekends and bank holidays.
  • You can report what you know now and send the rest later.
  • If the risk to people is high, you must tell them too, without undue delay.
  • Every personal data breach goes in your breach log, including the ones you decide not to report.
  • Failing to report a breach you should have can cost up to £8.7 million or 2% of worldwide turnover.

The first hour: stop the damage, keep the evidence

The instinct is to start investigating. Don't, not yet. In the first hour your two jobs are to stop things getting worse and to make sure you can still prove what happened later.

  1. Write down the time. When it was found, who found it and how. That is the first line of your timeline, and it may be the moment your 72 hours begin.
  2. Contain it. Disconnect affected devices from the network: unplug the cable, turn off Wi-Fi. Don't switch them off. A machine that is powered down loses what was in its memory, which can be the only record of what an attacker did.
  3. Lock the doors. From a device you trust, reset the passwords of affected accounts, sign them out of every session and remove any app passwords or tokens. If an email account was taken over, check its forwarding and inbox rules. Attackers often add a rule that quietly copies mail out, or hides replies from the real owner.
  4. Keep the evidence. Don't wipe, rebuild or restore anything yet. Export the logs, take screenshots, and keep the suspicious email as an attachment rather than deleting it.
  5. Get the right people in. One person leads, one keeps the timeline. Bring in whoever runs your IT, whoever is responsible for data protection (your DPO if you have one), and someone who can make decisions and spend money.
  6. Start the timeline, and keep it going. Every discovery, action and decision, with the time and who made it. It is what the ICO, your insurer and any auditor will ask for, and it is how you will justify a decision not to report.

Is it a personal data breach?

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. It is much wider than hacking. All of these count:

  • An email with customer details sent to the wrong person.
  • A spreadsheet shared with "anyone with the link".
  • An unencrypted laptop or phone that is lost or stolen.
  • Ransomware that locks records so nobody can use them. Losing access is a breach too, even if nothing was copied.
  • A former employee who can still sign in to a system holding customer data.

Not every security incident is a personal data breach. A website outage, or a phishing email that was reported and never clicked, involves no personal data. Record it anyway: a log of the near misses is what shows your controls are working.

When the 72-hour clock starts

The 72 hours run from when you become aware of the breach. You become aware when you have a reasonable degree of certainty that a security incident has led to personal data being compromised. You are allowed a short initial investigation to establish that, but it has to start straight away. Leaving an alert unread for a week does not delay the clock.

  • It is 72 real hours. Weekends and bank holidays count. Found at 4pm on a Friday means reported by 4pm on the Monday.
  • If you handle data for a client (you are their processor), you must tell them without undue delay. It is then their decision, and their clock, to report to the ICO.
  • If a supplier tells you they have been breached and your data was involved, your awareness, and your clock, usually starts when they tell you.

Record the moment you decided. Write down when you became reasonably sure personal data was affected, and why. If anyone later asks why you reported on day three, that line in the timeline is your answer.

Do you have to report it?

You must report to the ICO if the breach is likely to result in a risk to people's rights and freedoms. If it is unlikely to, you don't have to report it, but you must record it and your reasons. The question is always about the people, not about you: could this lead to fraud or identity theft, financial loss, discrimination, damage to their reputation, loss of confidentiality, or real distress?

What raises the risk

  • The kind of data. Health, ethnicity, religion, sexual orientation, biometrics, criminal records, financial details, passwords and anything about children all raise it sharply.
  • How many people. More people, more risk, though one person's medical record can be serious on its own.
  • Whether it could be read. Data that was strongly encrypted, with the key kept safe, is usually low risk.
  • Who has it now. A trusted recipient who confirmed they deleted it is very different from a criminal group or a public website.
  • Whether it can be undone. Recovered, deleted or restored from backup, or gone for good.
What happenedUsually
A fully encrypted laptop is lost, and the password was not with itRecord it in the breach log. Reporting is not usually needed.
One client's contact details emailed to another trusted client, who deletes it on requestRecord it. Usually not reportable, but weigh what the email held.
A spreadsheet of staff salaries and bank details emailed to someone outside the organisationReport to the ICO, and consider telling the staff affected.
Ransomware encrypts customer records, with signs that data was copied outReport to the ICO. Tell the people affected if the risk to them is high.
HR files with health information left open to the public internetReport to the ICO, and tell the people affected.

The ICO has a short self-assessment that helps with the decision. If you have weighed all of this and are still genuinely unsure, reporting and explaining your reasoning is usually the safer course.

How to report a breach to the ICO

Breaches are reported online, through the ICO's personal data breach form. It takes around half an hour and cannot be saved part-way, so gather these before you start:

  • What happened, when, and how you found out.
  • The kinds of personal data involved, and roughly how many people and records.
  • The likely consequences for those people.
  • What you have done to contain it, and what you will do next.
  • Whether you have told, or will tell, the people affected.
  • A contact for the ICO: your DPO, or whoever is leading the response.

You don't need every answer. UK GDPR lets you report in phases: send what you know within the 72 hours and follow up with the rest. If you report after 72 hours, include the reasons for the delay.

Keep the receipt. Save a copy of what you submitted and the ICO's reference number in your timeline. Every follow-up will quote it.

Telling the people affected

If the breach is likely to result in a high risk to people, you must tell them directly, without undue delay. Tell them in plain language:

  • what happened, and what of theirs was involved;
  • the likely consequences;
  • what you have done and are doing about it;
  • what they should do: change a password, watch for suspicious emails or calls, talk to their bank;
  • who to contact with questions.

You don't have to contact people individually if the data was unintelligible to whoever got it (properly encrypted, for example), if you have since taken steps that mean the high risk is no longer likely, or if it would take disproportionate effort. In that last case you make a public announcement instead.

Expect copycat phishing. Criminals follow news of breaches with emails that pretend to be your apology. Tell people you will never ask for a password or a payment by email, and give them one place to check what is genuine.

Who else to tell

  • Your insurer. Most cyber policies require prompt notice, and many include a response line staffed by specialists. Call them early, before you spend money they might have covered.
  • The police. Ransomware, extortion and fraud are crimes. Report them, and keep the crime reference with your timeline.
  • The National Cyber Security Centre. Significant cyber incidents can be reported to the NCSC, which can sometimes help directly.
  • Your bank. Straight away, if payments, card details or bank details are involved.
  • Clients and partners. Contracts and data processing agreements often set their own deadline for telling them, sometimes 24 or 48 hours. Check yours.
  • Sector regulators. Some organisations have extra duties: providers of public telecoms and internet services must tell the ICO within 24 hours under PECR, and operators of essential services and digital service providers have duties under the NIS Regulations.
  • Your own staff. Tell them what has happened, what to say to customers who ask, and who handles the press.

The incidents that actually happen, and what to do

Someone clicked a phishing link and typed their password

  • Reset the password and sign the account out everywhere.
  • Check multi-factor authentication wasn't changed, and no new device was added.
  • Check forwarding and inbox rules, and the sent folder for phishing sent on.
  • Look at what the mailbox holds to judge whether personal data was reached.

A laptop or phone is lost or stolen

  • Lock or wipe it remotely if you can, and sign it out of every account.
  • Record whether it was encrypted and locked. That usually decides the risk.
  • Report a theft to the police and keep the reference for your insurer.

An email went to the wrong person

  • Ask the recipient to delete it and confirm in writing.
  • Work out exactly what it contained, and about whom.
  • Decide on the risk, record the decision, and fix the cause: autocomplete is the usual culprit.

Ransomware

  • Disconnect affected machines from the network, but leave them on.
  • Call your insurer before anything else, and don't pay without specialist advice.
  • Check your backups are intact and were out of reach of the attack.
  • Assume data may have been copied out as well as locked.

A supplier tells you they've been breached

  • Ask exactly which of your data was involved, and when they found out.
  • Your 72 hours usually start when they tell you.
  • Record it, and check what your contract with them says.

A leaver can still sign in

  • Remove the access everywhere at once, not system by system.
  • Check the sign-in history for use after they left.
  • If they used it, treat it as a breach and assess the risk.

The checklist

Work down it in order. Ticks are kept in this browser, so you can come back to it, and it prints cleanly for the wall or the incident folder.

Incident response checklist 0 done

In the first hour

Within 24 hours

Within 72 hours

Recovery

Afterwards

Run the next one in Incidents

Every incident gets this checklist, a timeline of who did what and when, and the 72-hour ICO clock with the deadline and the hours left the moment personal data is involved. Closing one keeps the root cause and the lessons learned, so the next response starts better than the last.

Get started See Incidents From £9.99 a month. 14-day trial.

Afterwards: make the next one smaller

Within a couple of weeks, while memories are fresh, sit down with everyone involved. What happened, what went well, what didn't, and what changes. Keep it about the process, not the person who clicked: people who fear blame report late, and late is what turns an incident into a breach.

  • Update the breach log. UK GDPR requires you to record every personal data breach, the facts, its effects and what you did about it, whether you reported it or not.
  • Update the risk register. The incident proved a risk was real; its score should say so.
  • Fix the cause, not the symptom. Multi-factor authentication on the account that was taken over, an update installed, a leaver process that actually removes access.
  • Train for what happened. A short session on the exact trick that worked is worth more than a generic course.

Walters Sentinel keeps those pieces together: Comply holds the breach log, your record of processing and your policies; Risks keeps the register with an owner and a review date for every risk; and Access reviews runs the leaver check that finds one person across every system at once.

Questions people ask

Is the ICO deadline 72 working hours?

No. It is 72 hours from when you become aware of the breach, and weekends and bank holidays count. A breach found at 4pm on a Friday has to be reported by 4pm on the Monday.

What if we don't know everything within 72 hours?

Report what you know, say what you are still finding out, and send the rest when you have it. UK GDPR allows a report to be made in phases. If you report after 72 hours, you must give the reasons for the delay.

Do we have to report a lost laptop to the ICO?

Not usually, if the laptop was fully encrypted and locked with a strong password that wasn't lost with it, because the data cannot be read. Record it in your breach log either way. An unencrypted laptop holding personal data is a different matter and usually needs reporting.

Do we have to report an email sent to the wrong person?

Only if it is likely to result in a risk to the people whose data it contained. Weigh how sensitive the data was, who received it, and whether they have confirmed they deleted it. Record it in your breach log either way.

What happens if we report late, or not at all?

A late report must explain the delay. Failing to report a breach you should have reported can lead to a fine of up to £8.7 million or 2% of worldwide annual turnover, whichever is higher, separate from anything for the breach itself.

Who reports the breach, us or our IT provider?

The controller, the organisation that decides why and how the personal data is used, reports to the ICO. A processor, such as an IT provider or software supplier, must tell the controller without undue delay once it knows.

Should we pay a ransom?

Speak to your insurer and specialist advisers first. The ICO has said that paying a ransom does not reduce the risk to the people whose data was taken, and will not reduce any penalty. Paying also doesn't remove your duty to report.

Cyber Essentials checklistThe five controls that stop most attacks before they become incidents. SPF, DKIM and DMARC explainedStop criminals sending email that looks like it came from you.

Where this comes from

This guide explains the UK rules in plain English, and it is not legal advice. For a serious breach, speak to a data protection specialist or a solicitor.