You've had a data breach. Here's what the next 72 hours look like

Most small business data breaches are not hacks. They are a staff member emailing a customer list to the wrong address, a laptop left on a train, a shared folder that turned out to be public, a booking system that quietly exposed a spreadsheet, or an ex-employee whose access nobody switched off. They happen to careful businesses, and the thing that decides how badly they end is almost never the breach itself. It is what happens in the three days afterwards.

UK GDPR gives you 72 hours. That clock is shorter than it sounds, it includes weekends and bank holidays, and it starts earlier than most owners assume. Here is the sequence, in the order you actually have to do it.

First: is it even a personal data breach?

The definition is broader than people expect. A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That covers three separate failures: confidentiality (someone saw it who shouldn't), integrity (it was altered), and availability (you lost it, or you cannot get to it).

That last one catches people out. A ransomware attack that locks your customer database is a breach even if nothing was copied out. So is a backup that turns out to be corrupted when you need it. Losing access to personal data counts.

The clock starts when you become aware, not when you understand

You become "aware" once you have a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised. Not when you have finished investigating. Not when the IT contractor gets back to you on Monday. If a customer emails on Friday afternoon to say they can see somebody else's order details, and a two-minute check confirms it, the 72 hours started on Friday afternoon.

The same applies when a supplier tells you. If a system you use processes personal data on your behalf, their notification to you is the moment your own clock starts — which is why the contract with any provider holding your customer data should require them to tell you without undue delay, rather than at their convenience.

Seventy-two hours is not the deadline for solving the problem. It is the deadline for telling the regulator you have one. Those are very different jobs, and confusing them is how small businesses miss the window.

Hour zero to four: contain it

Before anything else, stop it getting worse. Recall the email if your mail system allows it. Revoke the link. Change the password and force everybody else's. Disable the account. Take the exposed page down. Ring the person who received it and ask them to delete it, and — this matters later — ask them to confirm in writing that they have.

Write down what you did and when, in a plain document with times on it. This costs ten minutes and becomes the most valuable thing you have if the ICO ever asks, because "we contained it within twenty minutes" is a materially different conversation from "we think we sorted it out at some point that afternoon".

Hour four to twenty-four: assess the risk

Now decide whether this is reportable. The legal threshold is whether the breach is likely to result in a risk to people's rights and freedoms. That is a judgement about consequences for the individuals, not about embarrassment for you.

Work through it properly. How many people are affected? What categories of data — a first name and an email address is a very different proposition from a date of birth, a bank account, health information or a home address for someone who has reason to keep it private. Was the data encrypted? Who now has it: a trusted client who has confirmed deletion, or an unknown recipient? Could it enable identity theft, financial loss, fraud attempts against those people, or distress?

If a risk is likely, you report. If it genuinely is not — an internal email misdirected to a colleague who deleted it, with nothing sensitive in it — you do not report, but you must still record it. And if you are honestly on the line, report it. The ICO is far more forgiving of a business that over-reported than one that talked itself out of a call it should have made.

Before 72 hours: report

Report through the ICO's online form, which is the route it asks you to use unless your systems are down. If you want to talk it through first, the ICO runs a personal data breach advice line on 0303 123 1113, open 9am to 5pm Monday to Friday.

You will be asked what happened and when, the categories and approximate number of people and records involved, the likely consequences, and what you have done to contain the breach and reduce the harm.

If you do not have all of it yet, report anyway. Article 33(4) of UK GDPR expressly allows phased reporting — you tell the ICO what you know inside the 72 hours and supply the rest without undue further delay. Waiting until the picture is complete is the single most common way businesses turn a manageable breach into a notification failure. The penalty for failing to notify when you should have runs to £8.7m or 2% of global turnover, and it sits alongside whatever the underlying breach attracts.

In parallel: do the affected people need to know?

A separate and higher test. If the breach is likely to result in a high risk to individuals' rights and freedoms, you must tell those individuals directly, without undue delay, in clear and plain language. Not a legalistic notice — what happened, what data, what it might mean for them, what you are doing, and who they can contact.

Tell them what to actually do, too. If passwords were exposed, say which service and tell them to change it anywhere they reused it. If it enables convincing phishing — and a leaked list of customers plus order values is a phishing kit — warn them exactly what the fake message is likely to look like.

Businesses resist this step hardest, and it is usually the one that saves the relationship. Customers forgive a mistake explained early. They do not forgive finding out three months later from somebody else.

A worked example

A salon emails a promotion to its client list and puts 340 addresses in the To: field instead of Bcc. A client replies at 2:10pm on a Saturday pointing it out.

Awareness is 2:10pm Saturday, so the 72 hours expire around 2:10pm on Tuesday. Containment is a recall attempt and a short, honest apology asking recipients to delete it. Assessment: 340 people, disclosed to each other; the data is names and email addresses with no financial or health information attached, but the list itself reveals that all 340 are clients of that salon, which for some categories of business would be sensitive in itself.

That is a risk, so it is reported — well inside the window, on Monday morning, with the timeline already written up. It is unlikely to be a high risk, so individual notification is not strictly required, but everyone on the list already knows because they received it, and a short honest note lands far better than silence. The breach goes in the log, and Bcc is replaced by proper mailing software that week, which is the fix the ICO would want to see anyway.

Whatever happens: write it in the log

Every personal data breach must be recorded, including the ones you decide not to report. The record needs the facts, the effects, and the remedial action taken — and for anything you chose not to report, the reasoning behind that decision. This is a legal obligation, and the ICO can ask to see it.

A spreadsheet with six columns does the job: date and time discovered, what happened, data and people involved, action taken, reported or not, and why. Businesses that have this take five minutes to answer a regulator's question. Businesses that do not spend a fortnight reconstructing it from memory and old emails.

The wider preparation is the same unglamorous work covered in the GDPR job we put off for two years — knowing what data you hold and where it lives is what makes the 72-hour assessment possible at all. It is the same instinct that makes a subject access request from an ex-employee an afternoon's work rather than a crisis, and the same reasoning that governs CCTV in a small business.

The half-hour that pays for itself

Do this before you need it. Write down who decides whether to report — a named person, plus a deputy for when they are on holiday. Save the ICO's report page and advice line number somewhere you can find at 6pm on a Friday. Start the breach log now, even empty. Check that your contracts with anyone processing customer data oblige them to tell you promptly. And confirm your team knows that reporting a mistake immediately is the expected behaviour, not a disciplinary matter, because a breach hidden for four days by a frightened employee is the version that becomes expensive.

Common questions

Does every data breach have to be reported to the ICO?

No. You only have to notify the ICO where the breach is likely to result in a risk to people's rights and freedoms. A misdirected internal email containing nothing sensitive, retrieved and deleted, will usually fall below that threshold. But every breach must still be recorded internally, including the ones you decide not to report and your reasons for that decision, and the ICO can ask to see those records. If you are genuinely unsure, report it. Regulators respond very differently to a business that reported a marginal case than to one that quietly decided a serious breach did not count and was later found out.

When exactly do the 72 hours start?

From the moment you become aware, meaning you have a reasonable degree of certainty that a security incident has occurred and personal data has been compromised. It is not the moment you finish investigating, and it is not the next working day. If a customer tells you on a Saturday afternoon and a quick check confirms it, the clock started on Saturday afternoon and expires around the same time on Tuesday. Weekends and bank holidays are included. If a supplier processing data for you notifies you of a breach at their end, your own clock starts when they tell you, which is why supplier contracts should require prompt notification.

What if I don't have all the facts within 72 hours?

Report anyway. Article 33(4) of UK GDPR expressly permits phased reporting: you tell the ICO what you know inside the window and provide the remaining detail without undue further delay as your investigation progresses. Nobody expects a complete forensic picture in three days. Give the essentials — what happened, roughly how many people and records, the likely consequences and what you have done to contain it — and flag clearly what is still being established. Waiting for certainty is the most common reason small businesses miss the deadline, and missing it is a separate failure from the breach itself.

Do I have to tell the customers affected?

Only where the breach is likely to result in a high risk to their rights and freedoms — a higher bar than the one for notifying the ICO. Where it applies, you must tell them directly and without undue delay, in clear plain language: what happened, what data was involved, the likely consequences, what you are doing about it and who they can contact. Give them practical instructions too, such as changing a reused password or watching for a specific phishing message. Even below the high-risk threshold, telling people early usually protects the relationship better than silence does.

What happens if I don't report a breach I should have?

Failing to notify the ICO when required is a breach in its own right, separate from the incident that caused it, and carries a fine of up to £8.7m or 2% of global annual turnover. In practice the ICO's response to a small business depends heavily on conduct: whether you had reasonable security in place, whether you contained the breach quickly, whether you kept records, and whether you were straight with the regulator. Reprimands and required improvements are far more common outcomes than large fines for small organisations. A concealed breach that surfaces later is the version that goes badly.