Five things to do in the first 72 hours after a data breach

Something has gone wrong. Maybe a laptop has been stolen. Maybe someone sent a spreadsheet containing customer data to the wrong email address. Maybe you've found evidence that an attacker was in your systems. Whatever happened, you're now in the window that GDPR calls a "personal data breach". And the clock is ticking.

The 72-hour reporting requirement is one of the most anxiety-inducing aspects of data protection law for small organisations. It feels very short when you're also trying to work out what happened, contain the damage, and keep the business running.

This is what to do.

1. Contain first, investigate second

Before anything else, stop the breach from getting worse. This might mean:

Revoking access credentials that may be compromised
Taking a system offline temporarily
Recalling an email (if possible) or contacting the recipient
Physically securing a device that's been left unsecured

Containment is more important than understanding what happened. You can investigate thoroughly once the immediate risk is addressed. Spending the first three hours on forensics while the breach is still ongoing is the wrong order.

Document what you did and when. You will need this record later, for the ICO if you report, and for your own review process afterwards. It helps to nominate a dedicated person responsible for documenting your actions.

2. Establish what data was involved

Once the immediate situation is contained, work out what personal data was actually affected. This is the question the ICO will want answered, and it's the question that determines whether you need to report.

Ask yourself:

Whose data is this? (Customers, staff, beneficiaries, members of the public?)
What categories of data? (Names and email addresses are less serious than health records, financial data, or data about vulnerable people)
How many people are affected?
Could this data be used to harm those people?

The last question is the critical one. The test for whether a breach is notifiable is whether it's "likely to result in a risk to the rights and freedoms of natural persons." Not every breach clears that bar. A misdirected email containing a single person's name and phone number, sent to a wrong address within the same organisation, probably doesn't. A database of customer financial details posted publicly almost certainly does.

3. Assess whether you need to report

There are two separate reporting obligations. One is to the ICO, one to the individuals. Both have different thresholds.

Report to the ICO within 72 hours if the breach is likely to result in a risk to individuals' rights and freedoms. If you're unsure, the ICO's guidance says to err on the side of reporting. An unnecessary report does you no harm. A missed mandatory report that comes to light later is significantly more damaging.

The 72-hour clock starts when you "become aware" of the breach, which the ICO interprets as when you have reasonable certainty that a breach has occurred, not when you've completed your investigation. You can report with incomplete information and update the ICO later.

Report to individuals if the breach is likely to result in a high risk to their rights and freedoms. The bar here is higher. If you do need to notify individuals, do it clearly and promptly, tell them what happened, what data was involved, and what they can do to protect themselves.

4. Notify the ICO if required — and do it now

The ICO's online reporting tool is at ico.org.uk. You'll need to provide:

A description of what happened
The categories and approximate number of individuals affected
The categories and approximate volume of records involved
The likely consequences of the breach
The measures you've taken or propose to take

You can submit an initial report with incomplete information and update it. Submitting a partial report within 72 hours is much better than a comprehensive report on day 4.

Keep a record of everything: when you became aware, when you reported, what you said, and what actions you took. This record demonstrates good faith if the ICO investigates further.

5. Review and learn

Once the immediate crisis has passed, do a proper post-mortem. How did this happen? What would have prevented it? What would have made you aware of it sooner?

Data breaches are almost always the result of systems or processes that weren't designed with security in mind, rather than individual malice or stupidity. A stolen laptop matters less if the disk was encrypted. A misdirected email matters less if sensitive data was never put in an email in the first place.

The review process is also evidence of good practice. If the ICO does investigate, being able to show that you took the breach seriously, reported promptly, and made genuine changes as a result puts you in a much better position than an organisation that shrugged and moved on.

If you find yourself in this situation and want a second opinion on whether you need to report, or help drafting your ICO notification, get in touch. We're used to working quickly when it matters.