Three in the Morning, Seventy-Two Hours Left: A Breach Runbook for Teams With No Legal Department

It's 3:12am on a Tuesday. Your operations manager is on the phone, sounding like they've aged five years. A member of staff says their laptop "went weird", a folder on the shared drive is suddenly full of files with strange extensions, and there's a note inside it asking for money.

Nobody in your organisation is a lawyer. Nobody is a security analyst. And somewhere at the back of your mind a number is ticking — 72 hours — without anyone being entirely sure when it started or who is supposed to be doing the counting.

That gap is what a runbook fills. Not the technical recovery, which your IT provider may or may not handle well. The decisions. Who makes them, in what order, and what gets written down while it's all still happening.

The 72 hours is not what most people assume

Under UK GDPR (that's the UK version of the regulation, sitting alongside the Data Protection Act 2018), a controller has to notify the ICO of a personal data breach within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to people's rights and freedoms. Two things trip small teams up here.

First, the clock starts when you become aware, not when the attacker got in and not when your investigation concludes. If you find out on Friday afternoon, the countdown starts on Friday afternoon. Sitting on it to see whether it "blows over" is itself the problem.

Second, notification isn't an all-or-nothing exam answer. You can report in phases. The ICO's own guidance is clear that if you don't have everything, you report what you have and follow up. In practice, a short, honest first notification with the phrase "investigation ongoing" in it is worth far more than a perfect one submitted on day five.

And a third point that gets missed constantly: every breach needs recording, reportable or not. Article 33(5) requires an internal register of the facts, the effects and the remedial action taken. If the ICO ever asks how you handled something, that register is your defence.

So what actually counts?

A personal data breach is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Notice that it's not just "someone hacked us". It covers:

• A laptop left on a train, unencrypted
• An email to the wrong client with a spreadsheet attached
• Ransomware that locks staff out of HR records
• A leaver who still had access to the case management system for six weeks
• A misconfigured shared folder that was briefly open to the internet

The test for reporting is risk. Special category data, financial details, large volumes, vulnerable individuals, or anything that could enable identity fraud will almost always push you over the line. Encrypted, properly backed-up and quickly contained incidents often won't. If people are at high risk, you also need to tell them without undue delay — that's a separate duty from telling the ICO.

Who decides at 3am?

This is the single most useful thing to settle in advance. Not a committee. A person, plus a deputy, plus a written statement that they are allowed to make the call.

Name an incident lead. Give them explicit authority to decide "we are notifying", to instruct the MSP, to approve holding statements, and to spend money up to a stated limit without a board meeting. Then name the person who takes over when they're on a beach in Cornwall with no signal.

Also decide, now, whether anyone else has to agree. A two-person rule is workable. A five-person consensus at 3am is how you lose 36 hours. Put the names, mobile numbers and the deputy arrangement on one sheet of paper. Print it. The paper version matters more than you'd think when the network is down.

Write it down as you go

During an incident, memory degrades fast and everyone remembers a different version by Thursday. Appoint someone — anyone sensible, not necessarily technical — as scribe. Their job is a plain timeline with real timestamps, in UTC to avoid the British Summer Time muddle, recording:

• What we knew, and when we knew it
• What we decided, who decided it, and why
• What we told whom, and when
• What we still don't know

The decision log is not bureaucracy. It's the difference between "we responded thoughtfully" and "we can't account for the gap between Tuesday and Friday".

The one-page runbook

Fill this in during a quiet afternoon. It takes about ninety minutes and it is the highest-value ninety minutes in your diary this quarter.

1. Incident lead and deputy — names, mobiles, home numbers if needed.
2. Who else gets woken up — MD, insurer, MSP escalation contact, comms person, any outsourced HR or legal retainer.
3. Insurer's 24/7 incident line and policy number — most cyber policies require notification within a set period, often far tighter than 72 hours. Dig the certificate out. Don't discover the number at 4am.
4. MSP out-of-hours number — and the contract clause promising they'll tell you about a breach "without undue delay".
5. ICO reporting route — the online personal data breach reporting form on ico.org.uk, plus the helpline number for the morning.
6. Evidence rule — do not wipe, rebuild or "just get people working again" on an affected machine until someone has captured logs and images. Say this out loud to whoever handles IT.
7. Holding statement — three sentences you can send to staff, written in advance, promising an update by a set time.
8. Decision tree — one line: is personal data involved? Is there a risk? If yes or unsure, notify. Log the reasoning either way.
9. Breach register — one spreadsheet, columns: date/time aware, description, data involved, people affected, risk assessment, decision, ICO reference, remedial action, closure date.
10. Review date — diarise a check every six months. Phone numbers rot.

The mistakes that turn a small incident into a big one

• Waiting for certainty. You will not have full facts inside 72 hours. Report and update.
• Outsourcing the decision to your MSP. They can tell you what they saw. They cannot decide whether you notify the ICO — that's a controller's call, and it stays with you.
• Assuming your provider will report it. If they're a processor, their duty is to notify you, not the regulator.
• Forgetting non-reportable incidents. The register exists for a reason.
• Deleting the evidence. Rebuilding a machine to get someone back to work destroys your ability to say what was actually accessed.
• Telling everyone nothing. Silence, followed by a vague email three weeks later, is how trust goes.
• Confusing clocks. The 72 hours is not the one-month DSAR deadline, and it isn't your insurer's notification window either. Read the policy. It's often 24 or 48 hours.

Rehearse it in 45 minutes

Pick a quiet Wednesday. Get four people in a room — incident lead, deputy, MSP contact on speaker, someone from operations. Give them this scenario: a staff member's mailbox has been forwarding invoices to an external address for eleven days, and the finance team paid one of them on Monday.

Run three phases, ten minutes each. First: what do we know and who's in charge? Second: is it reportable, and what's our reasoning? Third: what do we write down, who do we tell, and who signs it off?

Then read back the runbook and see which line everyone stumbled over. That line is your homework. Fix it while the stakes are imaginary — it's considerably cheaper than learning it live at 3am.