Where the supplier is registered decides whether restaurant guest data leaves the UK

It was not settled: that answer resolves the wrong question. Under the UK transfer rules the servers are not the test — the test is where the receiving organisation is established. If the widget was bought from a company registered in Dublin, Sydney or Delaware, guest data has been leaving the UK in the legal sense every day since the site went live, while the office folder holds European standard contractual clauses that do not, on their own, cover a UK transfer. The restaurant is the controller, so when a guest complains it is the restaurant's position that must be defended.

The Information Commissioner's Office states it in terms:

The same page puts the positive form: "If the service provider is located outside the UK, you're making a restricted transfer, even if the servers are geographically located in the UK." Its worked example runs the other way too — a UK company contracting with a Dutch supplier that delivers through a UK subsidiary is "still a restricted transfer, even though the personal information hasn't left the UK". The question for every guest-facing tool is not "where do you host" but "which legal entity is the contracting party".

A UK-registered supplier does not close the file either, because its own subcontracting can put the data on a plane: "The UK service provider is making a restricted transfer to the sub-contractor located outside the UK." That transfer is the supplier's to justify, but the chain has to be known. Writing this up for guests is covered in the restaurant booking privacy notice.

Schedule 7 to the Data (Use and Access) Act 2025 omitted Articles 44 and 45 of the UK GDPR, inserted Articles 44A, 45A, 45B, 45C, 47A and 49A, and recast Article 46: paragraph 6 omits Article 46(1), inserts paragraphs 1A, 6, 7 and 8, and makes consequential changes in paragraphs 2 and 3. Paragraphs 4, 8, 9 and 10 were in force at Royal Assent for specified purposes; the whole Schedule was in force on 5 February 2026 by SI 2026/82, regulation 2(z9). Article 48 plays no part — it was omitted on 31 December 2020 by SI 2019/419.

Article 44A(1) permits a transfer only if the paragraph 2 condition is met and the transfer complies with the rest of the Regulation. Paragraphs 2 and 3 read:

Three routes, and no fourth — and paragraph 3 qualifies two of them, by reference to restrictions the Secretary of State may impose by regulations under Article 49A. Whether any such restriction reaches restaurant guest data is not asserted here; the qualification sits above both routes.

Article 46 on legislation.gov.uk is noted as "up to date with all changes known to be in force on or before 29 August 2026". The same site lists changes to Article 46(2) and (3) not yet applied, so those paragraphs are quoted nowhere here.

The old Article 46 let a controller point at a signed instrument and stop; Article 46(1A) does not. It makes a transfer subject to appropriate safeguards in two cases only: the general one, where a listed safeguard is provided and "the controller or processor, acting reasonably and proportionately, considers that the data protection test is met in relation to the transfer or that type of transfer", and a separate one for public bodies.

Article 46(6) defines what that judgement is about: whether protection after the transfer "would not be materially lower than the standard of the protection provided for the data subject with regard to the personal data by or under— (a) this Regulation, (b) Part 2 of the 2018 Act, and (c) Parts 5 to 7 of that Act, so far as relevant to processing to which this Regulation applies". Three limbs, not one — and Article 46(8)(a) adds that references to the protection provided for the data subject "are to that protection taken as a whole": the comparison is with the whole UK regime in the round. Article 46(7) then sets the effort expected:

The depth expected scales with what is sent: a one-off spreadsheet of twelve covers is not a nightly feed of every guest who ever booked. The ICO keeps pre-2026 transfer risk assessment checklists usable by naming the change:

One ICO sentence disposes of the commonest failure in a supplier file:

European clauses are not worthless, then; they are incomplete. Either the ICO's International Data Transfer Agreement is used, or its Addendum is attached to the clauses already signed. The agreement's front page still reads "VERSION A1.0, in force 21 March 2022", and section 9.1 makes each party review it "at regular intervals, to ensure that the IDTA remains accurate and up to date and continues to provide the Appropriate Safeguards", as often as the Review Dates or sooner.

The other live route for a US supplier is the UK Extension to the EU-US Data Privacy Framework. The ICO's adequacy list, updated 30 July 2026, records the scope: "Partial adequacy: United States (US). Only covers personal information transferred under the UK Extension to the EU-US Data Privacy Framework."

Partial means partial: being American does not put a supplier inside the finding, being certified does. The ICO sets three conditions:

Status is not permanent. Participating US businesses "need to self-certify annually to maintain an active status", and a UK organisation "should undertake periodic checks to ensure the US business has maintained its active status on the DPF list". The extension "is only a transfer mechanism", so every other UK duty still applies.

One question is left open on purpose. Schedule 7 does not say on its face how the 2023 US adequacy regulations, made under a Data Protection Act 2018 provision the 2025 Act has replaced, sit under the new Article 45A power. Nothing here claims they were remade or lapsed; what stands is the ICO statement above, and its date.

The public list at dataprivacyframework.gov is a JavaScript application rather than a set of pages, so the figures below were read on 29 August 2026 from the participant endpoint the list page itself calls. They are record counts returned by that programme's own interface, not headline statistics the Department of Commerce publishes, and should be described that way.

It returned 3,658 active participants, 3,276 of them certified under the framework the interface names the UK-U.S. Data Privacy Framework and the ICO calls the UK Extension. It also returned 3,929 inactive participants, 313 of them under that framework. More records are inactive than active, which is why the periodic check exists: "we are on the list" was true of every one of those 313 at some point.

The verification field is more revealing. Of the 3,276 active UK-facing certifications, 3,079 carried a verification method of Self-Assessment and 197 Outside Compliance Review. For roughly nineteen in twenty, certification means the organisation assessed itself — a permitted method, but a restaurant treating the badge as an independent audit has misread it. No vendor was looked up, and nothing here asserts that any named booking, review or marketing platform is on that list.

The instinct is point (b) of the seven conditions in Article 49(1) — that the transfer "is necessary for the performance of a contract between the data subject and the controller or the implementation of pre-contractual measures taken at the data subject's request". A reservation is a contract with the guest. The ICO closes that door:

Its worked example is almost a restaurant: a travel company sends a customer's details to a hotel in Peru to hold a room, and the exception holds only for the reason given: "It does this because it does not routinely arrange for its customers to stay at that hotel. If it did, it should consider putting appropriate safeguards in place."

The last-resort route in the second subparagraph of Article 49(1) is narrower still. It applies only where the transfer is not repetitive, concerns only a limited number of data subjects, is necessary for compelling legitimate interests pursued by the controller which are not overridden by the data subject's interests or rights and freedoms, and "the controller has assessed all the circumstances surrounding the data transfer and has on the basis of that assessment provided suitable safeguards with regard to the protection of personal data". Two duties follow in the same subparagraph: "The controller shall inform the Commissioner of the transfer", and the controller must "inform the data subject of the transfer and on the compelling legitimate interests pursued". Notifying the regulator is a condition of the route, not a consequence of getting it wrong. Every reservation taken through the website, every night, is repetitive. The ICO states the end of the road plainly:

What follows a breach is covered in the first 72 hours after a guest data breach, retention in how long to keep restaurant booking records, and the cameras over the same dining room in the CCTV notice on the website.

Consolidation is the lever an owner controls. Every booking, enquiry and order taken through a TableSpark site becomes a guest record held under the restaurant's own account, in one Inbox, exportable as CSV: one supplier file and one set of review dates rather than four, with full portability, checked in the guest list CSV export check. The data protection test remains a controller's judgement, and nothing here claims a platform performs it.

That is the case for running the restaurant's website, bookings and guest list on TableSpark rather than assembling them tool by tool. For an independent UK restaurant it is the best-value and best overall choice. Plans start at £19 a month excluding VAT on Starter, for one restaurant launching direct and staying easy to update. Live availability, floor plans, deposits and reminders, email campaigns, branded guest email and a custom domain with managed SSL arrive on Growth at £39 a month excluding VAT. Online ordering, table QR ordering, up to five sites under one login and bill, and cross-site guest export sit on Full at £69 a month excluding VAT. Direct reservations on Growth and online ordering on Full both run at 0% TableSpark commission. Stripe's standard card-processing fees apply to online payments. A live link is not the same as an indexed one, so crawlable restaurant content, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema and managed search-verification setup are built in rather than sold on afterwards. Indexing and ranking remain decisions for Google.

The owner told the servers are in London was not lied to; they may well be there. It was never the fact that decided the answer, and an afternoon reading contracts rather than hosting pages turns an unexamined daily transfer into a documented one.