Clock Running, Evidence Fading: A Small Firm's Data Breach Response Plan

Most small businesses that mishandle a personal data breach do not fail on the law. They fail on the morning it happens: a laptop is wiped before anyone takes a copy, three people email three different customers, and the person who should have called the insurer is on annual leave. The legal test under the UK GDPR is short and, once the facts are known, usually not that difficult. The difficulty is the scramble.

This guide sets out what a UK business should actually do between discovering a breach and the seventy-two-hour mark, and how to keep a record that stands up afterwards.

The clock starts earlier than most people assume

Under Article 33 of the UK GDPR, a controller must notify the Information Commissioner's Office (ICO) without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach — unless the breach is unlikely to result in a risk to people's rights and freedoms.

"Becoming aware" does not mean completing your investigation. The ICO's position is that a business is aware once it has a reasonable degree of certainty that a security incident has occurred which has led to personal data being compromised. That can be the moment a member of staff reports a misdirected email, or the moment a supplier tells you its system was accessed.

Practical consequence: the 72 hours runs from suspicion with a proper basis, not from the conclusion. If you cannot complete your assessment in time, you can report in phases — an initial notification with the facts you have, followed by updates — provided you explain the delay.

Hours one to four: contain the incident, do not tidy it up

The instinct to make the problem disappear is the single most damaging instinct in breach response. Rebuilding a server, deleting a compromised mailbox or resetting an account can destroy the very evidence that determines whether you must report, and what you tell customers.

Prioritise, in this order:

• Stop the onward flow. Recall the misdirected email, contact the unintended recipient and ask for deletion in writing, suspend the compromised account, revoke access tokens and API keys.
• Isolate, do not erase. Take the affected device off the network rather than wiping it.
• Preserve. Export mailbox audit logs, access logs, email headers, screenshots of the exfiltration and the original message threads. Note who captured what, when, and where it is stored.
• Do not interview staff in a way that contaminates the record. Ask for a written account early, in their own words.

Appoint one lead, one log, one channel

A breach does not need a crisis committee, but it does need a named incident lead with authority to make calls, and a single written log. Every entry should record the time, the decision taken, who took it and the reason. That log is not bureaucracy: it is the best evidence you will have if the ICO later asks why notification was or was not made, and it is usually the difference between a regulator's inquiry closing quietly and widening.

Keep the group small — typically a director, the person closest to the systems, and whoever handles customer relationships — and route all external communications through one point of contact.

The reporting threshold: risk, not certainty of harm

The test is whether the breach is likely to result in a risk to the rights and freedoms of individuals. That is a lower bar than actual harm, and it is assessed on the facts as they stand, not as you hope they will turn out.

Factors that tend to push towards reporting include:

• special category data such as health, biometric or criminal records information;
• financial details, passwords or identity documents;
• a volume of records large enough to permit profiling or fraud;
• data relating to children or vulnerable people;
• a breach that is still ongoing, or where the recipient is unknown;
• a realistic prospect of identity fraud, phishing or reputational damage.

Factors that tend to point the other way include a single misdirected internal email recalled within minutes, where the recipient is identified and has confirmed deletion, or data that was strongly encrypted and the key was not compromised.

If the answer is genuinely borderline, report. The ICO does not penalise a controller for notifying in good faith, and a short factual notification is a far smaller problem than a complaint from an affected individual that reaches the regulator first.

Either way, record the reasoning. Article 33(5) requires you to document all breaches, including those you decide not to report, with the facts, effects and remedial action. That obligation applies to a firm of four people just as it does to a bank.

Telling individuals: the higher bar

Separate notification to affected people is required under Article 34 where the breach is likely to result in a high risk to their rights and freedoms. That is a higher threshold than for ICO reporting, but it is easily met by exposed bank details, credentials or health information.

A notification to individuals should be plain, specific and free of defensiveness. It should say what happened, when, what categories of data were involved, the likely consequences, what you have done, what they can do to protect themselves, and whom to contact. Do not bury it in a general customer newsletter, and do not describe an event as a possible incident when you know it occurred.

Exceptions exist — for example where the data was rendered unintelligible by encryption, or where individual notification would involve disproportionate effort and a public communication is used instead — but they are narrower than they look and should be recorded carefully.

Where a supplier or customer is involved

If you are a processor, Article 33(2) requires you to tell the controller without undue delay. Check the contract: many data processing agreements impose a 24- or 48-hour notice period, and breach of that clause can be a contractual problem in its own right.

If you are the controller and the breach happened at a supplier, the clock is yours. Chasing a vendor for a complete report is not a reason to delay notifying.

Communications: factual, not confessional

Staff should hear from you before they hear from a customer. They are often the route by which a breach is discovered, and they will be the ones taking calls.

For customers, a short written statement covering the four points above is usually sufficient. Resist the temptation to speculate about cause, to blame an individual, or to characterise the incident as a one-off before the investigation supports it. Equally, avoid evasive holding lines that say nothing; they tend to escalate complaints and invite press interest.

Where litigation or a regulatory investigation is a realistic prospect, take advice on privilege early, and route forensic reports through solicitors where appropriate.

A ready-to-adapt checklist

Within 4 hours

• Nominate the incident lead and start the log.
• Contain: revoke access, recall communications, isolate devices.
• Preserve logs and devices; instruct IT not to rebuild anything.
• Notify your insurer if you hold cyber cover; check the notification deadline in the policy.

Within 24 hours

• Establish the data categories, approximate volume and affected individuals.
• Assess the risk and record the reasoning.
• Identify whether a processor or controller sits elsewhere in the chain.
• Brief staff and prepare a holding statement.

Within 72 hours

• Report to the ICO if required, or record why not.
• Notify affected individuals if the high-risk threshold is met.
• Consider whether other regulators, clients or law enforcement need to be told.

Days 4 to 30

• Complete root-cause analysis and remediation.
• Update the breach register and, where relevant, your retention and security policies.
• Review the contract terms that governed the relationship and the access controls that failed.

The regulatory aftermath is slower than the deadline

The 72 hours is the urgent part, not the whole of it. Directors should expect follow-up questions about governance: whether access was role-based, whether multi-factor authentication was in place, whether staff had been trained, and whether the incident log was maintained. Under the UK GDPR, the maximum penalty remains £17.5 million or 4 per cent of annual worldwide turnover, whichever is higher, and the ICO's published approach gives weight to exactly this kind of organisational evidence.

A calm, documented, proportionate response will not make a breach disappear. It will, however, make the difference between a firm that had an incident and a firm that mishandled one — and in the months that follow, that distinction tends to matter more than the incident itself.