The Booking Platform Got Hit, Not You — What a Restaurant Still Owes Its Guests

Waiting feels sensible: the platform caused this, it is investigating, and presumably it will say what happens next. That is also where the restaurant's exposure begins. UK GDPR draws a hard line between the restaurant, which decided to collect the booking details in the first place and is the controller of that data, and the platform it pays to run the booking diary, which is only ever the processor. A processor's incident does not relieve the controller of a single one of its duties. A fine of up to £8,700,000 or 2 per cent of turnover stands behind them, and a guest whose data was caught up in someone else's ransomware attack can bring a compensation claim against the restaurant directly.

None of this is new law written for ransomware; it belongs to the same UK GDPR structure that has applied since 2018. Article 24(1) puts general accountability for compliant processing on the controller, the restaurant, regardless of who runs the system day to day. Article 28(1) adds a duty that comes earlier than any breach: a restaurant may hand guest data only to a processor offering "sufficient guarantees" of appropriate security in the first place.

That vetting duty does not end at the signature. ICO guidance on controller-processor relationships says plainly that the responsibilities last as long as the relationship does.

A restaurant that has not asked its booking platform, ordering system or EPoS vendor a security question since onboarding day is not meeting that standard, and the gap tends to surface only after something goes wrong.

Once a supplier is hit, two separate notification duties start running. Article 33(2) puts the first on the processor, meaning the platform, the ordering system or the EPoS vendor, with no numeric cap and only a general "without undue delay":

The ICO's guide gives an example that maps almost directly onto a restaurant's suppliers:

The restaurant's duty under Article 33(1) is separate, and it starts on a different clock:

That bracketed [F2the Commissioner] is legislation.gov.uk's marker for a word put in by later amendment, replacing "the supervisory authority" after the UK left the EU. The substantive point survives the footnote: the 72 hours does not begin when the supplier's systems were compromised, and it is not an unconditional deadline. The duty bites only where the breach is not "unlikely to result in a risk to the rights and freedoms" of the guests concerned, a judgement the restaurant has to make and defend rather than a box that ticks itself. The clock starts when the restaurant itself becomes aware, and in a supplier-originated incident that is normally when the platform's Article 33(2) notice lands, which can be days after the platform's systems were first compromised. A restaurant that opens a vague supplier email, assumes it will be handled because the system belongs to the platform, and does nothing for a week has not stopped its clock. It has spent several of its own 72 hours.

A second duty remains after the regulator question is settled. Article 34(1) sets a materially higher bar, "high risk" rather than plain "risk", before the restaurant has to tell its own guests directly:

Whether a given supplier incident clears that higher bar is a second, genuinely separate judgement from the regulator-notification question, and it is one the restaurant has to make about its own guests. The supplier's notice does not answer it.

Ransomware invites one particular misjudgement: that if nothing appears copied or published, there is nothing to assess. The UK GDPR definition of a personal data breach does not distinguish between data stolen and data simply made unavailable.

Loss of availability ranks alongside disclosure there, and the security duty in Article 32(1)(c) makes the point again: both controller and processor must be able to restore access to personal data after an incident:

A ransomware attack that locks a restaurant out of its own bookings diary and guest list, with no confirmed exfiltration at all, has already caused a personal data breach on the availability limb alone. NCSC guidance on ransomware is blunt about why that limb matters:

Whether that particular incident clears the Article 33(1) reporting threshold remains a separate, risk-conditional question about the likely consequences for the guests concerned. It is not something a restaurant can resolve by asking the supplier whether any files were "actually stolen." NCSC incident-response guidance treats regulatory notification as a distinct planning step, not something a cyber-incident report substitutes for:

A report to Action Fraud or through the NCSC's reporting route addresses the crime and the national cyber-security picture. Nothing found for this article states that either discharges an Article 33 notification, and Article 33 names only the Commissioner, so a restaurant that has reported the crime should not assume the regulator has been notified. That rests on the absence of authority for the comfortable reading, not on a stated regulator position.

The costliest move here is treating the supplier's failure as a complete answer to the restaurant's own exposure. ICO guidance on controller-processor liability leaves little room to misread it:

The same guidance sets out the one route off that liability, and it is a high bar rather than the default outcome of using a third-party platform:

The burden falls on the restaurant to prove zero responsibility, not on the guest to prove fault. The same ICO guidance also confirms who a guest can actually sue over a supplier-caused incident:

A diner whose data was exposed by a booking platform's ransomware incident can bring the claim against the restaurant directly, leaving the restaurant to chase the platform for its share of the fault afterwards. That is a recovery action taken after the event, not a shield that stops the original claim reaching the restaurant's door. Whether any UK restaurant or hospitality supplier has actually faced ICO enforcement over an incident of this specific kind was not established for this article, and that gap should be read as a genuine unknown rather than as evidence the exposure above is theoretical.

Anyone working from a saved PDF should know the surrounding text is not static. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and the ICO's own pages confirm the provisions affecting data protection law are now in force:

More easily missed is a separate instrument renaming the regulator itself, drafted and on the statute book but not yet operative. The Data (Use and Access) Act 2025 (Consequential Amendments and Transitional Provision) Regulations 2026 (S.I. 2026/386) would substitute "the Information Commission" for "the Commissioner" throughout Articles 28, 33 and 34. Its commencement clause is unambiguous about when that happens:

Legislation.gov.uk records that trigger as not yet met, and lists the renaming amendments under changes "yet to be applied" rather than current text. The correct name for the regulator today remains the Information Commissioner's Office, and a restaurant's Article 33 notice still goes to the Commissioner, not to "the Information Commission". That renaming is real and dated, but not yet in force.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the relevance here is structural rather than legal. Every plan holds bookings, orders and enquiries as guest records under the restaurant's own account, in one Inbox with CSV export, instead of scattering them across a separate booking platform, ordering system, EPoS vendor and loyalty tool, each its own processor relationship with its own Article 28 vetting duty and its own supplier notice to watch for. Starter, at £19 a month excluding VAT, carries that Inbox and record-keeping alongside "secure by default" handling (bot protection, roles, 2FA and SSL) with data rights built in for erasure, export and deletion. Growth, at £39 a month excluding VAT, adds direct reservations at 0% TableSpark commission and POS connections, so bookings and till run through one account rather than a separate booking-platform breach clock. Full, at £69 a month excluding VAT, adds online ordering, also at 0% TableSpark commission, and cross-site guest export for an operator running more than one site under a single login. Consolidating suppliers reduces how many separate processor relationships a restaurant has to vet and monitor under Article 28; it does not remove the restaurant's own Article 33 and 34 duties once an incident happens, wherever it originates: no such promise is made here. The same data a loyalty or birthday-offer supplier holds raises its own separate consent questions.