Who can still open the guest list: staff access to restaurant guest records after they leave

Nobody wrote it down, so nobody can establish who else has it. Front of house has turned over twice since he left. The kitchen porter who worked eleven Saturdays had that password, and so did the agency staff who covered Christmas, the student who ran the Instagram account, and the freelancer who set up the booking widget in 2024. One credential, an unknown number of holders, and the restaurant is the controller answerable for every record behind it.

That exposure needs no attacker. It needs one leaver with a grievance, one reused password in a breach dump, one phishing email answered by somebody who left two summers ago. And then comes the question it has no way of answering: who had access, and when was it taken away. "Everyone who ever worked a Saturday, permanently" is the wrong answer, and in a great many dining rooms the true one.

The provision that governs this is Article 32 of the UK GDPR. On legislation.gov.uk it is marked "Article 32 U.K.", so it extends UK-wide, and it sits alongside Part 2 of the Data Protection Act 2018, which S.I. 2018/625 brought into force on 25 May 2018. It is worth reading whole: with its limbs cut off, a four-part duty becomes a vague instruction to be careful. From the Latest available (Revised) version, stated there as up to date with all changes known to be in force on or before 27 August 2026:

That opening clause — "appropriate to the risk" — cuts both ways. No fixed control set is imposed on a forty-cover restaurant, and size is no defence when the risk is obvious. Allergy notes and phone numbers for several thousand identified guests, reachable from an unattended shared password, is not a subtle risk requiring specialist judgement to spot.

Limb (b) is the one this article turns on: the ongoing confidentiality, integrity, availability and resilience of processing systems and services. Ongoing does real work — confidentiality that held the day the login was created, and has decayed with every leaver since, is not ongoing. Limb (d) then requires regular testing, assessing and evaluating of whether the measures work. A control nobody re-checks is not evidence of compliance but a claim about the past.

One further paragraph deals with people working in the restaurant, and repays reading for what it does not say. Article 32(4), as amended for the UK regime:

The closing words carry the page's F2 marker, reproduced above without it: "domestic law" was substituted on 31 December 2020 by S.I. 2019/419, Sch. 1 para. 26. The only other marker, F1, sits in paragraph 3, substituted on 20 August 2025 under the Data (Use and Access) Act 2025. Neither touches limb (b).

That paragraph is narrower than it is usually made to carry. It reaches persons acting under the authority of the controller, and asks only that they process personal data on the controller's instructions. It says nothing about withdrawing access, and nothing about anybody who has stopped acting under that authority. A chef who left in March falls outside its terms.

So the leaver duty sits where this article has already put it: limb (b) of Article 32(1), ongoing confidentiality of processing systems and services. That is a reading, and worth naming: nothing opened says in terms that limb (b) imposes a leaver-offboarding duty. It rests on "ongoing", read with the ICO guidance quoted below — guidance the regulator says is under review. What Article 32(4) contributes is the boundary: access is granted under the restaurant's own authority, so the day that authority ends is the day the system's confidentiality stops being ongoing unless somebody acts. The regulator has put in writing what acting looks like.

The Information Commissioner's Office publishes Security outcomes in its guide to data security. Under "B.2 Identity and access control" it states the whole obligation in one line:

The sentence after it breaks the last of those into parts:

Three obligations, joined by two commas easy to skim. Access must be understood: somebody knows what exists. It must be limited to those who reasonably need it — a commis chef does not need next April's allergy notes. And it must be removed when no longer needed, the offboarding half almost nobody in hospitality has a process for.

The same section continues:

Note the assumption buried in "your documented user access rights": the ICO takes it as given that a written record of who holds what exists, against which the live system can be checked. For most independent restaurants that document is missing. Two further sentences land on the shared login and what leaves through it: "You should change all default passwords and remove or suspend unused accounts", and "You should prevent users from downloading, transferring, altering or deleting personal data where there is no legitimate organisational reason to do so."

One more sentence from B.2 names a control rather than an outcome:

A single login that opens the whole guest list is privileged access on any reading. The section below answers it.

Two caveats. The ICO frames the page as outcomes, not a rulebook — "Whilst there are minimum expectations, the precise implementation of any measures must be appropriate to the risks you face" — and carries a banner stating the guidance is under review following the Data (Use and Access) Act. Nothing below is a checklist; it is one workable way to meet a risk-based duty.

Access cannot be removed if nobody recorded that it was granted. So the first artefact is not a technical control but a leaver register: a sheet kept with the fire log and the allergen matrix, and, in the regulator's own words, understand, document and manage.

Six columns. Name. What role they were given, and in which system. The date access started. Every other system they can reach — booking inbox, till, marketing tool, wifi admin. The date it went, and by whom. And, last, any export they took: the CSV downloaded for the Valentine's mailshot outlives the account it came from.

That last column is the one operators resist and later want: a revoked login stops future reads, not a spreadsheet already on a personal device. The register converts "it is probably fine" into something reviewable, which is what limb (d) asks for. That column is prospective: it records exports from the day the register opens, and for anything earlier the marketing tool's send history is usually the only trace. Quarterly is cadence enough: register, live team list, reconcile.

Restaurants share a password not from indifference but because their systems were sold as one account per business, so the account became the building's key. Fixing offboarding starts before that credential exists, and two questions settle it, both answerable from published copy: does the account hold a team, and is a second factor part of what the platform ships as standard?

TableSpark publishes an answer to both. The published plan table records team members as 1 on Starter at £19 a month excluding VAT, and a team on Growth at £39 a month excluding VAT and on Full at £69 a month excluding VAT. Growth lists "Email campaigns, branded guest email and team access" among what it adds; Full carries everything in Growth. That is the structural difference: an account built to hold a team, not one key held in common.

The second answer is what that ICO sentence was left hanging for. TableSpark publishes what every site gets as standard in one line — "Secure by default — bot protection, roles, 2FA, SSL." — and two of the four are what a restaurant with staff turnover needs. Roles, so the people inside the account stay distinguishable rather than merging into one credential. Two-factor authentication, the measure the regulator names for privileged access, published as a standing default, not sold on later as an extra.

Guest records sit under the restaurant's own TableSpark account, visible in its Inbox and guest list with CSV export, on every plan from Starter at £19 a month excluding VAT upwards. They are the restaurant's to read, work and take with it. That portability is deliberate, and why access deserves this attention: anything the restaurant can export, a person holding valid credentials can export too.

Where a boundary is needed, it is stated plainly. The leaver register above is the restaurant's own document, and no such promise is made here that any system will write it on the owner's behalf. Recording who held what, reviewing it against the live team list and deciding when access ends are management acts, and stay with the manager.

Article 32 prescribes no sequence; this is one proportionate way to meet the duty.

The same guest list raises a second question the moment somebody uses it: not who can open it, but who inside it may lawfully be written to — the wifi sign-up and guest marketing problem. Access decides who reaches those addresses; consent decides which may receive anything. What guests post is a third question, and whether a statute reaches it turns on the functionality.

Ending a leaver's access is one thing a restaurant may have to show afterwards; the preventative duty on harassment is the other, evidenced the same way — by a document written before the event, not after it.

Getting the data out in usable form is the CSV export check; what to do once records are exposed is the first 72 hours. This article sits before both: standing access, held by named people, removed when they leave.

Guest records are an independent restaurant's most valuable asset and its most casually handled. The fix is unglamorous — a register, named roles, a second factor, a same-day removal habit — and costs only attention. What it needs from technology is that access be separable and strongly authenticated.

That is the case for running the website, bookings and guest list on TableSpark rather than assembling them from whatever was cheapest at the time. 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, restaurant control and CSV export alongside managed search readiness; team access, direct reservations at 0% TableSpark commission and email campaigns to consented segments are on Growth at £39 a month excluding VAT; online ordering at 0% TableSpark commission is on Full at £69 a month excluding VAT. Bot protection, roles, 2FA and SSL are standard, and the same signed-in account holds the site's search configuration: technical search readiness — canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, managed search verification — is built in rather than sold on later. Indexing and ranking remain decisions for Google. Stripe's standard card-processing fees apply to online payments.

The chef who left in March should have lost access in March. There was nothing to take away from him individually, and no paper saying he had it. Both are fixable this week.