GDPR for Restaurants: Guest Data, Consent and the ICO

Picture a Tuesday morning at a 60-cover independent. An email arrives from a regular: she would like to know what the restaurant holds about her. Her name is in the booking platform. Her phone number is in a paper diary, her allergy is in a WhatsApp group the front-of-house team uses, her email sits in a marketing tool, and a spreadsheet from last Christmas has all of it again with a column of notes nobody remembers writing. The manager who set up the spreadsheet has left. Nobody is sure which of the five places is the full picture. The clock on her request has already started.

The same scatter shapes the other bad mornings. A newsletter goes to every guest who ever booked, including people who gave their number only so the restaurant could confirm a table. A tablet with the day's bookings is left in a taxi. The annual data protection fee, which looks like a small admin job, is never paid because nobody knew the restaurant had to. None of these is exotic. Each comes from the same cause: guest data that lives wherever it happened to land.

The wider evidence is about all UK businesses, not restaurants, and this article says so each time. The Cyber Security Breaches Survey 2025/2026, published by the UK government on 30 April 2026, found that "just over four in ten businesses (43%)" reported some kind of cyber security breach or attack in the last 12 months. That covers every kind of attack on every kind of business, so it is a measure of how common trouble is, not of how many restaurants lose guest lists. The same survey found that around one in seven businesses (14%) held personal data that was not protected by techniques such as anonymisation or encryption.

The rules have also moved. The regulator is the ICO, whose functions passed to the new Information Commission on 30 September 2026; ico.org.uk still carries ICO branding, so the pages quoted below are the ICO's guidance under its existing web addresses. In a news release dated 23 June 2026 the ICO reported that more than two in three businesses aware of the Data (Use and Access) Act either do not know or wrongly think the law change does not apply to them. That is an ICO research figure given in a news release, with the sample not stated there, and it is cited here as the regulator's own description of how well the new rules are understood.

On enforcement, the honest picture is narrower than the headlines. The ICO has fined companies for unsolicited marketing, always in other sectors and always as whole-case outcomes. In January 2026 it fined Allay Claims Ltd £120,000 for more than 4 million unlawful marketing text messages sent between February 2023 and February 2024, and ZMLUK Limited £105,000 for over 67 million marketing emails sent between January and July 2023 without valid consent. In June 2026 it fined KRA Consultancy Ltd £300,000 for 5,575,715 unsolicited marketing texts sent between April 2022 and May 2025. Those are penalties for millions of messages, not for one badly built form. No ICO enforcement case against a restaurant, pub or takeaway was found when this article was researched on 25 October 2026, so nothing here suggests that any restaurant has been fined. The risk for an independent is more ordinary: a complaint nobody can answer, a fee penalty, a breach handled late, and a guest who stops trusting the booking form.

The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025. According to GOV.UK, the regulations bringing most of its data protection and privacy provisions into force took effect on 5 February 2026, simplifying parts of the UK GDPR and modernising enforcement powers. One more date matters to a restaurant: on 19 June 2026 the complaints duty and the remaining provisions came into force, and from 30 September 2026 the Information Commission replaced the office of the Information Commissioner.

For an owner, three things follow. Marketing enforcement now uses the same penalty structure as the rest of data protection. Every organisation needs a clear route for data protection complaints, with acknowledgement inside 30 days. And the guidance to follow still lives on the ICO's pages, which is where this article sends the reader for each rule.

This is a summary of public law and official guidance as published on 25 October 2026, not legal advice.

Most restaurants that take bookings do. The ICO's guide to the data protection fee says there are "three different tiers of fee and controllers are expected to pay between £52 and £3,763." The tier depends on turnover and on staff numbers, and the staff count is broad: "members of staff" includes employees, workers, office holders and partners, and each part-time person counts as one.

The tiers, as the ICO publishes them, and the fixed penalty for not paying:

Paying by direct debit brings an automatic £5 discount at the point of payment, so tier 1 becomes £47 and tier 2 becomes £73. The ICO reserves the right to raise the fixed penalty up to a statutory maximum of £4,350.

Two details catch independents out. The first is the word "or". A business qualifies for tier 1 if its turnover is no higher than £632,000 or it has no more than 10 staff, so a restaurant with 18 staff and £850,000 turnover meets neither test and sits in tier 2. The second is CCTV. The ICO's advice for small organisations says that a business installing CCTV that could capture images of people, and not already registered, "must also register with us and pay the data protection fee," and gives the figure for small and medium businesses as £52 or £78 a year, reduced to £47 or £73 by direct debit. GOV.UK says the same range applies to "most organisations, including charities and small and medium-sized businesses", and adds that failing to pay "may be fined by the ICO."

There is a list of exemptions, and the word that matters is "only". The ICO says a fee is not due if personal data is processed "only" for purposes such as staff administration, advertising, marketing and public relations, accounts and records, not-for-profit purposes, personal or household affairs, or processing without an automated system such as a computer. A restaurant that takes online bookings on a computer, holds a guest database and runs CCTV is processing for more than those purposes. The Journal's reading is that such a restaurant should assume the fee applies and use the ICO's own self-assessment if there is any doubt. Even an exempt organisation, the ICO adds, still has to comply with its other data protection obligations.

Under the ICO's guide to lawful basis, a business "must apply at least one" of the listed bases whenever it handles personal information. For a restaurant three matter: consent, contract and legitimate interests. The ICO describes contract as processing that is "necessary for a contract you have with the person, or because they have asked you to take specific steps before entering into a contract." Legitimate interests applies where the processing is necessary for the business's interests "unless there is a good reason to protect the person's information which overrides those legitimate interests."

The Journal's reading is that a table booking is the clearest fit for contract: the guest asked the restaurant to hold a table, and the restaurant needs a name, a date, a party size and a way to reach them. That reading covers the booking and its confirmation. It does not by itself cover everything a restaurant might want to do next, because each purpose needs its own basis. A short working table shows the split.

Write the basis down for each purpose. The ICO also expects privacy information to be given to people, which leads to the next requirement.

The ICO's right to be informed guidance says organisations "must provide individuals with information including: your purposes for processing their personal data, your retention periods for that personal data, and who it will be shared with." It calls this privacy information and says it must be "concise, transparent, intelligible, easily accessible" and written in "clear and plain language". The ICO's checklist includes the name and contact details of the organisation, the purposes of the processing and the retention periods for the personal data.

For a restaurant that means a notice at each collection point: the booking form, the enquiry form, the newsletter box and any paper walk-in list. The notice should name the restaurant, say that booking details are used to run the booking, say what marketing is sent and on what permission, state how long records are kept, and name the tools that process the data on the restaurant's behalf. The Journal's guide to a restaurant booking privacy notice covers the wording of the notice and where to put it, so it is not repeated here. The point for this article is that a notice should not state a retention period or a recipient list the restaurant has not decided, and that decision depends on knowing where the data is.

The ICO's electronic mail marketing guidance is blunt: "You must not send marketing emails or texts to individuals without specific consent." There is a limited exception for a business's own previous customers, known as the soft opt-in.

The ICO states the exception as two routes: the person "specifically consented to electronic mail from you", or they are "an existing customer who bought (or negotiated to buy) a similar product or service from you in the past, and you gave them a simple way to opt out both when you first collected their details and in every message you have sent." The ICO's longer guidance says the soft opt-in applies only where all of these are met:

• You obtained the recipient's contact details.
• You did so while selling or negotiating to sell a product or service.
• You are only marketing your similar products and services.
• You provided the recipient with an opportunity to refuse or opt out when you collected their contact details.
• You give the recipient an opportunity to refuse or opt out in every subsequent communication.

The ICO uses restaurants as its own examples. Its good practice example reads: "A restaurant collects mobile phone numbers from customers when they book a table on their website. By collecting the contact details themselves, the restaurant satisfies this first part of the soft opt-in." Its bad practice example reads: "A restaurant buys a list of people's mobile phone numbers from a third party, who claims the list is 'soft opt-in compliant'." The ICO is plain that "there is no such thing as a third-party marketing list that is compliant with the soft opt-in."

A second pair of ICO examples shows the consent route. In the good version a customer phones to book and the restaurant asks whether they would like marketing text messages about discounts and events. The customer agrees verbally, and the restaurant adds the number to its marketing database "which shows the time and date they consented." In the bad version the restaurant sends a booking confirmation and then a text advertising a special food event, with no consent step. The ICO also says to keep a record of consent, such as who, when and how, so the restaurant can show it is valid.

One limit applies to how these examples are read. The ICO uses the booking example only for the first condition, obtaining the details. The ICO does not state for restaurants whether a table booking counts as selling or negotiating to sell. The ICO does say a person "doesn't need to actually buy anything" and that it is enough if negotiations for the sale took place, and the Journal's reading is that a booking is likely to qualify. That is a reading, not a ruling, and the safer route for a newsletter is a clear opt-in box that is not pre-ticked, at the point of booking or sign-up.

The fines cited earlier were for millions of unsolicited messages. Allay Claims Ltd also failed to offer a simple way to refuse marketing when collecting details, so the ICO concluded it could not rely on the soft opt-in. For a restaurant the practical lessons are modest and specific. Keep a consent record. Put an unsubscribe link in every email. Do not buy lists. Do not send a promotion in the same message as a booking confirmation unless the guest agreed to promotions. The Journal's guide to restaurant email marketing covers campaigns in detail, and its guide to booking reminders covers the line between a service message and an advert.

Special category data gets extra care under the UK GDPR. The ICO quotes the definition of data concerning health as "personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status", and adds that health data "can be about an individual's past, current or future health status."

The ICO does not say whether a free-text "nut allergy" note on a booking is health data. The Journal's reading is that a note like that can reveal health status, so the safe working assumption is to treat it with care. In practice that means three habits. Collect only what service needs: the allergen, not the guest's medical history. Keep the note off group chats and shared screens that staff outside the shift can see. And match retention to the purpose, which for a one-off visit may be shortly after the visit, while a returning regular who wants the note kept can say so and be recorded as having asked.

A subject access request, or SAR, is a person asking what an organisation holds about them. The ICO's guide to subject access says "people can make SARs verbally or in writing, including via social media." The organisation must respond "without undue delay, and within one month of receipt of the request." In most circumstances there is no charge to the person asking. The page was last updated on 16 July 2026.

Four details decide whether a small restaurant can meet that deadline.

1. The month runs from receipt or, where identity information is needed, from the day that information arrives. The ICO says it can run from "a month of receiving: information confirming the identity of the person the information is about".
2. The time can be extended by up to a further two months, where necessary, if the request is complex or the person has made a number of requests. The organisation must tell the person and explain why within the first month.
3. If the restaurant asks for clarification, the month pauses on the day it asks and resumes the day after the answer. The ICO calls this "stopping the clock."
4. The search must be "reasonable and proportionate", which does not excuse skipping a place where the data plainly sits.

A request made in a direct message or a chat is a valid request. The restaurant's problem is rarely the law; it is knowing where to look.

An illustrative restaurant shows the cost. Take a 60-cover independent with 600 bookings a month and an average party of three, so 1,800 covers a month, 18 members of staff and turnover of £850,000. Every figure in this paragraph and the next is an assumption for the example, not a statistic. One regular asks for everything held on her.

By hand across five places (the booking platform, the paper diary, the WhatsApp group, the marketing tool and the spreadsheet), the example allows 20 minutes to search each place, so 5 x 20 = 100 minutes, plus 30 minutes to confirm identity, collect the results, remove other guests' details and reply. That is 130 minutes, or 130 / 60 = 2.1667 hours. At the April 2026 National Living Wage for workers aged 21 and over, £12.71 an hour, the time costs 2.1667 x £12.71 = £27.54. A real employer's cost is higher than the wage floor, so treat the figure as a lower bound.

From one guest record with a search and an export, the example allows 20 minutes to search and export and 10 minutes to check identity and reply. That is 30 minutes, or 0.5 hours, and 0.5 x £12.71 = £6.36. The difference is £27.54 - £6.36 = £21.18 for each request. The pounds are small. The risk is the one that matters: a place that gets missed, a month that runs out, and a regular who now has a reason to complain.

The ICO says the right to erasure "is not absolute and only applies in certain circumstances", and that a restaurant must respond "without undue delay and at the latest within one month," saying whether it has erased the data or refused. A guest who asks to be deleted from the newsletter is a different request from one who asks for every record to go, and the reply should say which was done. A restaurant may need to keep some records, such as accounts, for other legal reasons, and should say so rather than silently keep everything.

The ICO's storage limitation guidance is direct: "the UK GDPR does not set specific time limits for different types of data. This is up to you, and will depend on how long you need the data for your specified purposes." It adds that a business needs "a policy setting standard retention periods wherever possible." Some vendors publish template periods in their privacy-policy samples. Those are the vendor's example choices, not a legal standard, and a restaurant should set its own: a short period for bookings that were honoured, a defined period for no-show history if one is kept, and an end date for marketing consent that has gone unused.

The ICO's small-organisation CCTV page says a business needs to "put up signs to let people know you're filming them," and that the signs should "explain why you're using CCTV, and who to contact to raise any queries." The business should "decide how long you'll keep the data for and record this in your CCTV policy and privacy information," and have a process to delete footage it no longer needs. The page also asks businesses to set out why CCTV is needed and how they plan to reduce the effect on privacy. Its own bar example covers only a terrace, entrance and exit. CCTV capturing people is also the reason for the fee point above.

Staff are people too. The ICO has separate employment guidance on keeping employment records, information about workers' health and monitoring workers. The simplest rule for a restaurant is to keep rota, payroll and health information in a place guests' data does not share, and never in the guest WhatsApp group.

The ICO's guide says the UK GDPR "introduces a duty on all organisations to report certain personal data breaches" and that this must be done "within 72 hours of becoming aware of the breach, where feasible."

Not every incident is reportable. The ICO's test is that "if a risk is likely, you must notify the ICO; if a risk is unlikely, you don't have to report it." Every breach must be recorded: "you must also keep a record of any personal data breaches, regardless of whether you are required to notify." Where a breach is likely to cause a high risk to people's rights and freedoms, the business must also tell those people without undue delay. The ICO states that failing to notify when required "can result in a heavy fine of up to £8.7 million or 2 per cent of your global turnover", which is a maximum and not what a small business should expect.

The commonest restaurant scenario is the lost device. A tablet with the day's guest list and no passcode goes missing on a Saturday night. The question to answer in the first hour is whether a risk to the people on the list is likely, and the answer depends on what was on the device and whether it was locked. Write the answer and the reasoning in the breach log either way. The Journal's guide to the first 72 hours after a guest data breach sets out the full timeline for the first three days.

The ICO announced on 23 June 2026 that "all organisations must now give people a clear way to raise a data protection complaint, acknowledge it within 30 days, investigate appropriately and communicate the outcome." The Data (Use and Access) Act, section 103, inserts section 164A into the Data Protection Act 2018. It says a controller "must facilitate the making of complaints", for example by providing a complaint form that can be completed electronically and by other means, and that the controller "must acknowledge receipt of the complaint within the period of 30 days beginning when the complaint is received."

The Act then requires the controller, without undue delay, to take appropriate steps to respond and to tell the complainant the outcome. The 30 days is an acknowledgement boundary. The restaurant still has to investigate and report back, and the Journal's guide to data protection complaints in 2026 works through examples. For this article the checklist item is simple: a published email address or form for data complaints, a named person who reads it, and a diary note for the 30-day acknowledgement.

Section 157 of the Data Protection Act 2018 sets two maximum levels: a higher maximum of £17,500,000 or 4% of the undertaking's total annual worldwide turnover in the preceding financial year, whichever is higher, and a standard maximum of £8,700,000 or 2%, whichever is higher. For a breach of the new complaints duty the standard maximum applies. Schedule 13 of the 2025 Act modifies section 157 so that the same structure covers breaches of regulation 22 of PECR, the email and text marketing rule. The GOV.UK factsheet says the Act "aligns the PEC Regulations' enforcement sanctions (powers and fines) with the DPA 2018." The exact date the PECR change started was not separately confirmed in the sources read, so the PECR ceiling is stated here per the Act and the GOV.UK factsheet.

For the example restaurant, 4% of £850,000 is 0.04 x £850,000 = £34,000, but the law's wording takes whichever is higher, so the ceiling is £17,500,000. Nobody should present that as the likely result: no restaurant fine was found, and the realistic costs are the fixed fee penalty, the staff time, and the loss of a guest's goodwill.

Everything in this section applies to the same illustrative restaurant. Records a year are 600 bookings x 12 months = 7,200 booking records.

The regulatory cash cost is small. The fee is tier 2, £78 a year, which is £78 / 12 = £6.50 a month, or £73 by direct debit. A restaurant with 10 staff or fewer would pay tier 1, £52 (£47 by direct debit). The cost of getting it wrong is the fixed penalty of £600 for a tier 2 business, which is £600 / £78 = 7.7 times the annual fee. Everything else in the regulatory column is time and risk, not a fee: the 130 minutes of the by-hand access request, the 72-hour clock, and the 30-day acknowledgement.

The software cost is a separate question, because the tools that hold guest data have different price structures. The 1,800 covers a month in the example exceed the "Up to 1200 covers per month" limit on one booking tool's middle plan, so its top plan is the one this restaurant needs. Every price below is quoted as printed on each provider's own page, read on 25 October 2026.

These prices are not like-for-like, because the providers charge for different things. Over twelve months the arithmetic is: simpleERB Pro £80 x 12 = £960; Favouritetable FT Pro £129 x 12 = £1,548, all paid in advance; Favouritetable FT Ultimo £199 x 12 = £2,388, also paid in advance; TableSpark Growth £39 x 12 = £468 excluding VAT on the monthly plan, or £390 excluding VAT on the yearly option. A restaurant that needs marketing as well as bookings, which is the case when it wants to email consented guests, finds that the Favouritetable page lists marketing on the Ultimo tier. A restaurant using a booking tool plus a separate email service pays two bills and keeps guest data in two systems. Each needs an entry in the privacy notice and a processor agreement. The Journal's guide to what a guest database costs goes through the full stack.

Each of these items stays the restaurant's job, whichever software it uses. Software can make the answers quicker to find. The lawful basis, the retention period and the wording of the notice stay decisions for the owner.

There are three routes in practice. The first is the scatter described at the start: a booking platform, a diary, a chat group, a marketing tool and a spreadsheet. The second is a booking platform plus a separate marketing tool, which tidies the booking side but creates two systems to search, two privacy-notice entries and a sync to trust. The third is one guest record behind the booking form, the ordering page, the newsletter box and the email channels.

The one-record route is the strongest for an independent (the Journal's guide to the restaurant CRM explains how the record is built), because the restaurant that holds its own record can answer each question above from a single screen.

TableSpark is the third route. The restaurant's own account holds each record: "Records sit in your restaurant's own TableSpark account, and you can export them whenever you like. Guests can ask to see or delete their data, and you can erase a guest in two clicks." The steps below follow the live tutorials and the restaurant CRM page. The Inbox, guest records and CSV export are on every plan from Starter at £19 a month excluding VAT. The Guests page with segments and the email campaigns described below belong to Growth at £39 a month excluding VAT.

The loyalty screen says it plainly: "Verification is separate from marketing permission. This screen never opts a guest into marketing." The step-by-step walk-through is in the know your guests tutorial. Records erased in TableSpark cover the records it holds for the restaurant; a copy kept in a paper diary or a chat group stays the restaurant's to clear.

• Run the checklist above once a quarter and tick it with a date.
• Search your own name in Guests before a busy weekend, so a real request is not your first try.
• Put the data-complaints email address in the site footer and on the privacy page. TableSpark generates Privacy, Cookie and Terms pages from your store details, and the restaurant checks that the wording matches what it actually does.
• Name the booking tool and the email channel in your privacy notice, and keep their processor terms in the same folder as the breach log.
• Keep allergy notes to the allergen itself and clear them after the visit unless the guest asks you to keep them.

GDPR for a restaurant is a short list of habits, and every one of them is easier when the guest record is in one place. The regulatory cash cost in the worked example is £78 a year (£73 by direct debit); the costly mistakes are the ones that come from not knowing where the data is. TableSpark is the best-value and best overall choice for an independent UK restaurant that wants its bookings, orders, newsletter and email channels to feed one guest record, in the restaurant's own account, exportable whenever it likes, from £19 a month excluding VAT.

For a restaurant that also wants consented email campaigns, automatic segments, guest journeys and the guests' app, Growth at £39 a month excluding VAT keeps them all behind that one record. Compare the plans on the pricing page.