A data breach is not a question of if but when for most growing online retailers. Having a written incident response plan in place before an incident happens is the difference between a controlled, defensible response and a chaotic scramble under legal and reputational pressure.
Why a written plan matters before you need one
Under UK GDPR, organisations must notify the Information Commissioner's Office (ICO) of a qualifying personal data breach within 72 hours of becoming aware of it — a deadline that is extremely difficult to meet if you're building a response process from scratch while also fighting the incident itself. A written plan, agreed and understood by relevant staff in advance, converts a crisis into a checklist.
The plan doesn't need to be lengthy or written by a lawyer to be effective; it needs to be specific about who does what, in what order, and with what authority, so that the first hour of a suspected breach is spent acting rather than debating.
Step one: detection and initial assessment
The plan should name a specific person (and a deputy) responsible for triaging any suspected breach report, whether it comes from a staff member noticing unusual account activity, a customer report, a payment processor alert, or a security tool. Their first job is establishing basic facts fast: what data may have been affected, how many customers, whether the exposure is ongoing or has been stopped, and how it was discovered.
- What type of data was potentially exposed (names, addresses, order history, payment details, passwords)?
- How many individuals are potentially affected?
- Is the vulnerability still active, or has the exposure already been contained?
- Was the breach caused by an external attack, an internal error, or a third-party supplier?
Step two: containment
Once a breach is confirmed or strongly suspected, contain it before investigating further — this might mean taking a compromised system offline, revoking access credentials, changing admin passwords, or disabling a vulnerable plugin or integration. Document every action taken and when, both because this creates a defensible record for the ICO and because it prevents duplicated or conflicting containment steps if multiple people are responding at once.
Preserve evidence rather than immediately wiping affected systems — logs, timestamps and access records are essential both for understanding the scope of the breach and for any subsequent ICO enquiry or insurance claim, so involve a specialist before deleting anything that might be evidence.
Step three: assessing whether ICO notification is required
Not every data incident is a notifiable breach. The test under UK GDPR is whether the breach is likely to result in a risk to individuals' rights and freedoms — a leaked customer order history is lower risk than exposed passwords or payment card data, which is high risk and virtually always notifiable. When in doubt, the ICO's own guidance and helpline are the right first port of call, and erring toward notification is generally safer than erring toward silence, since failing to notify a genuinely notifiable breach carries its own enforcement risk.
Step four: notifying affected customers
Where a breach poses a high risk to individuals — most clearly, exposed passwords or payment data — UK GDPR requires you to notify affected individuals directly and without undue delay, in clear language explaining what happened, what data was involved, and what steps they should take (such as changing a reused password). Avoid vague or minimising language; customers respond far better to a direct, honest explanation than to a breach they later discover was downplayed.
Prepare a holding statement and a customer notification template as part of your plan in advance, so you're not drafting sensitive external communications from a blank page under time pressure.
Step five: recovery and post-incident review
Once contained and notified, run a structured post-incident review: what allowed the breach to happen, what worked well in the response, what didn't, and what specific changes — technical, procedural or training-related — will reduce the likelihood of a repeat. Update your incident response plan itself based on this review; a plan that isn't refined after a real incident is a missed opportunity to genuinely improve your defences.
Consider whether cyber insurance (covered elsewhere in this section) applied or should be reviewed, and whether the incident needs reporting to your payment processor or acquiring bank under your merchant agreement, separately from any ICO notification.
Taking This Further
It's rarely useful to treat building a data breach incident response plan for UK online retailers as a standalone decision — the strongest results tend to come from lining it up with the rest of your operation. Many of the same principles come up again in Handling Subject Access Requests and Statutory Data Breach Notifications Under UK GDPR, which is worth bookmarking for later.
For related reading: Our companion guide, UK GDPR and Data Protection Compliance: A Practical Guide for Online Retailers, goes into this in more depth. Our companion guide, YouTube Ads for Direct Response Retail: A Practical Guide for UK Advertisers, goes into this in more depth.