The supplier still has the guest list: what Article 28(3)(g) lets a restaurant demand on the way out

The restaurant is the controller of that list; the supplier was only ever the processor. The decision about the retained copy is therefore the restaurant's, and is easily left unmade. They do not ask for the data back, do not instruct deletion, and obtain nothing in writing. Six months on they cannot say where the list sits, how many copies exist, or who can still open one.

The consequence arrives from the guest's side. A diner asks the restaurant to erase everything it holds. The restaurant deletes its own records, answers the request and considers the matter closed — then the same diner receives marketing from a platform the restaurant stopped paying two years ago, or is named in its breach notification. The restaurant must explain, to the guest and possibly to the regulator, why a list it remained answerable for sat somewhere it had never checked. Where both parties are responsible for the same damage, the guest may pursue the restaurant for the whole of it.

The opposite failure runs the other way: an owner demands every backup be wiped by close of business, is told that is not how backups work, and concludes the supplier is lawless. The published position sits between the extremes.

The provision is Article 28(3)(g) of the UK GDPR, headed on legislation.gov.uk "Article 28 U.K." and so extending UK-wide; the Data Protection Act 2018 alongside which it operates states at section 214(1) that it extends to England and Wales, Scotland and Northern Ireland, subject to stated exceptions, so there is no separate Scottish or Northern Irish regime to check. The Regulation has applied since 25 May 2018 and has formed part of domestic law since the implementation period ended on 31 December 2020. Read on 30 August 2026 in the Latest available (Revised) version, it says:

The bracketed "domestic law" in the consolidated text, in the chapeau too, is the post-Brexit substitution for the original reference to Union or Member State law; those are the words in force. Three things in the clause are worth slowing down for, because summaries lose all three.

The choice belongs to the controller. The verb is not "deletes" but "deletes or returns", at the controller's choice. A restaurant that never expresses one has not exercised the right the clause gives it, and the data stays where it is.

The trigger is the end of the provision of services. Not a billing period, not the closing of an account, not the day the card stopped being charged. Services can end before or after a subscription does, and the clause follows the service.

The deletion of existing copies is qualified by one thing only. "unless domestic law requires storage of the personal data". Nothing else lets a supplier keep a copy — not convenience, not product research, not an assertion that the data is needed. Quoting the clause as far as "existing copies" and stopping deletes that qualifier, and it is an easy error to make.

The Information Commissioner's Office restates the clause in plainer English — at the controller's choice, delete or return, and delete existing copies unless UK law requires storage — and adds the sentence that settles who is in charge:

The ICO guidance pages consulted here carry the banner "Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change.", so read it as guidance under review rather than settled.

Article 28 itself has been stable. The Data (Use and Access) Act 2025 touched it in one place — words in Article 28(5), substituted with effect from 20 August 2025 by section 142(1) and Schedule 11 paragraph 9, commenced by S.I. 2025/904 regulation 2(y), leaving the deletion and audit limbs alone; a substitution in Article 28(8) by S.I. 2026/386 is listed as not yet applied. The principle around them did move: Article 5(1)(e) now cross-refers to Article 84B rather than Article 89(1), with effect from 5 February 2026 under sections 87(1)(a) and 142(1) of the same Act, commenced by S.I. 2026/82 regulation 2(o), its substance unchanged. The currency stamp on legislation.gov.uk varies between requests and is not a safe date of last amendment; the page was read on 30 August 2026.

Article 28(3)(g) is not a free-standing right to wave at a supplier; it is a term the contract was required to contain, under the opening words of Article 28(3):

A restaurant that signed up through a web form and never received a data processing agreement has a harder exit, and that gap is worth finding while the relationship is live — the moment described in exporting and testing before a booking system move.

Nor does the chain stop at the supplier. Under Article 28(4) the same obligations must be imposed on any sub-processor:

So the question on exit is not "have you deleted it" but "have you, and everyone you passed it to". Where those parties are registered decides a further question about the same copies: what happens when guest data leaves the UK.

This is where exit letters overreach and lose authority. The ICO is explicit:

Instant destruction of every backup is not the standard, and a supplier refusing it is not for that reason in breach. The storage-limitation guidance closes the gap that concession opens:

Together they make the enforceable position a sequence rather than an event: live systems purged now, backups beyond use and untouched for any other purpose, destruction on the supplier's ordinary cycle — something a competent supplier can agree to and date.

The moment a former supplier decides for itself what the retained list is for — its own marketing, its own research, a dataset it sells on — it changes character:

Article 82(4) then decides who a diner may pursue where more than one party is responsible for the same damage:

The defence sits in the paragraph before: under Article 82(3) a controller or processor is exempt if it proves it is not in any way responsible for the event giving rise to the damage. The ICO adds that a controller is primarily responsible for its own compliance and that of its processors, and that regardless of the contract terms it may face the corrective measures and sanctions in the UK GDPR. An indemnity recovers money afterwards; it is no shield against being answerable.

Article 5(2) is why an exit needs paperwork rather than memory:

The ICO's audit framework states the standard for third-party disposal as a control measure: "Evidence of secure disposal is obtained from third parties used to dispose of personal information." Evidence obtained, rather than a supplier's word taken on trust.

The instrument is already in the contract: Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance with the obligations laid down in that Article, and to allow for and contribute to audits, including inspections, conducted by the controller or an auditor it mandates.

A second route runs through the guest. When a diner exercises the right to erasure against the restaurant, Article 19 attaches:

A former supplier is squarely within that: the ICO's definition of a recipient includes processors and persons authorised to process personal data under the direct authority of a controller or processor. A restaurant that cannot list the platforms holding its guest data cannot answer a guest who asks who else was told — an inventory the guest list CSV export check produces.

No published ICO enforcement action — penalty, enforcement notice or reprimand — was found naming a failure at the end of a processor relationship, or citing Article 28(3)(g). The ICO has fined a software supplier directly, but for security failings during a live contract, which is not an end-of-contract deletion case. The pressure here is contractual and accountability-based: a term the restaurant may enforce, a duty it must evidence, and a guest claim for the whole of the damage.

Nothing prescribes a sequence. This is one proportionate way to discharge the duty.

Every one of these problems begins the same way: the guest list lives somewhere the restaurant does not control, so leaving becomes a negotiation instead of a decision. Keep the guest relationship on the restaurant's own site and account, and exporting, erasing and evidencing become things the restaurant does rather than asks for. That is the case for running the website, bookings, guest records and marketing on TableSpark rather than on whatever was signed up for fastest. It is the best-value and best overall choice for an independent UK restaurant. Plans start at £19 a month excluding VAT for Starter, carrying guest records under the restaurant's own account with restaurant control and CSV export, plus enquiry and newsletter forms and one Inbox for every lead. Direct reservations at 0% TableSpark commission, live availability, deposits and reminders, email campaigns to consented guest segments and a custom domain with managed SSL are on Growth at £39 a month excluding VAT. Online ordering at 0% TableSpark commission and table QR ordering are on Full at £69 a month excluding VAT. Data rights are built in — erasure, export, deletion — and technical search readiness travels with the site: crawlable restaurant content, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema and managed search-verification setup. Indexing and ranking remain decisions for Google. Stripe's standard card-processing fees apply to online payments. Records held this way sit under the restaurant's own account, exportable whenever it wants. What a departed supplier holds is another question, and no such promise is made here.

Two decisions sit on the same asset: which guests may lawfully be written to, in the wifi sign-up and guest marketing problem, and which printed links survive a supplier change, in the table QR code link lifecycle. Both fail quietly, months after the invoice was paid. The exit letter is an hour's work; the list took years to build.