Restaurant Booking Privacy Notice UK: A Form-to-Record Audit

The booking touchpoint is the place to fix first. A footer link on a distant page does not explain a dietary-notes box while someone is deciding what to type. The ICO says privacy information for data collected directly from a person must be provided when the information is obtained. It also says that simply putting a privacy notice somewhere on a website, in case people find it, is not enough; people must be made aware of it and given easy access. See the ICO’s current guidance on when to provide privacy information.

This guide gives an operating audit for a typical independent restaurant. It is not individual legal advice, and a sample notice cannot choose your lawful basis, special-category condition or retention period for you. Those decisions must reflect what your restaurant actually does.

Guidance currency (checked 4 August 2026): the ICO marks the right-to-be-informed guidance used here as under review following the Data (Use and Access) Act and says it may change. The guidance remains published, but recheck the current ICO wording when implementing this audit or materially changing the notice; this article is operational information, not legal advice.

Do not begin by rewriting a long privacy policy. Open the live booking form on a phone and make a list of every field, including optional boxes, hidden tracking, confirmation messages and marketing choices. Then follow each value to the place where staff see, copy, export or delete it.

Now trace the pathway:

This map exposes the practical gap between a statement such as “we value your privacy” and a real account of what happens. If a field has no clear purpose, remove it or make the purpose concrete before collecting another record. The ICO’s data-minimisation guidance says personal data should be adequate, relevant and limited to what is necessary for the stated purpose.

For an online restaurant form, a layered notice is usually the clearest implementation pattern. The first layer sits in the booking journey. It gives the guest the information most relevant to submitting the form and links prominently to the full notice. The second layer explains the complete processing in accessible language.

The ICO specifically describes a just-in-time message on an online form, combined with a prominent link to more detailed information, in its guidance on methods for providing privacy information.

A practical first layer could follow this structure:

That is a drafting pattern, not compliance wording to paste without review. Replace the brackets, link the words “full privacy notice”, and ensure the notice matches the real record flow. If the restaurant has an unexpected use, such as sharing details with a separate venue or using booking history for profiling, do not hide it behind the link. The ICO says the top layer should give prominent, early warning of uses that people may not expect or that may significantly affect them.

Place the message directly above the final booking button or beside the fields it explains. On mobile, it must be readable without a hover action. Use a descriptive link such as “How we use booking information”, not a vague “read more”. Do not make opening the full notice a condition of reading the form; give people a working, accessible link and keep the essential first-layer information in view.

The complete notice must describe the restaurant’s actual processing, not a generic list copied from another business. The ICO’s current checklist of privacy information to provide identifies information that is always required and information that applies in particular circumstances.

Work through the full official list, but use restaurant language. “We use your mobile number to tell you if your table time changes” is more useful than “we process contact data for operational purposes”. Be specific about categories of recipients if naming every provider is not appropriate. If information moves internationally, describe the relevant transfer details and safeguards that apply. If the restaurant relies on consent for a purpose, explain how to withdraw it as easily as it was given.

Also explain whether a field is required and what happens without it where that is relevant. A restaurant may genuinely need a contact route to warn a guest about a closure. That does not automatically mean it needs both a phone number and an email address, a date of birth or an unrestricted life-history box.

Keep booking communication separate from optional marketing. A guest should be able to request a table without being led to think that promotional messages are part of the same operational purpose. Map any marketing choice as its own processing activity, with its own wording and records, and review the separate direct-marketing rules that apply to your channel.

“Dietary requirements” looks like one harmless box, but the content can vary sharply. “Window table if possible” is not health information. “Severe nut allergy; carries an adrenaline auto-injector” may reveal a person’s health status. A religious dietary statement may reveal a protected belief. The field design has to anticipate what a guest may reasonably enter, not just the label chosen by the restaurant.

The ICO lists health data as special category data and says organisations processing special category data need both an Article 6 lawful basis and a separate Article 9 condition. The condition should be determined and documented before processing. Its special category data guidance also stresses necessity, minimisation, security and specific privacy information.

Use these design controls:

Do not assume that every food preference is special category data. Equally, do not design the process as if no guest will disclose an allergy, disability, belief or other sensitive fact. When the correct condition or safeguard is unclear, obtain advice based on the restaurant’s real use before collecting the field.

A booking can involve the restaurant, its website provider, a booking platform, messaging services, payment services and staff devices. Listing “trusted third parties” does not resolve who decides what or why.

The ICO’s controller and processor guide says the key question is who determines the purposes and means of processing. The role follows the facts, not merely the label used in a contract. Document each organisation’s position, instructions and responsibilities for the booking flow.

For each vendor, record:

The restaurant should also know where copies appear after an export. A CSV saved to a manager’s laptop is a new operational copy. Export is valuable for portability and restaurant control, but it also needs an owner, an access rule, a storage location and an end date. “It came from the booking system” is not a retention policy.

There is no single UK GDPR number for how long every restaurant should keep every booking record. The ICO’s storage-limitation guidance says organisations must justify retention from their purposes, review the data they hold, and erase or anonymise information when it is no longer needed.

Split the record into purposes instead of giving everything the longest period:

“Keep while useful” is too vague. Set a period or explain the criteria that produce it, assign an owner, and test whether deletion occurs in the booking system and downstream copies. Consider any genuine accounting, legal-claim or safety purpose separately; do not use one possible future need to retain every field indefinitely.

Rights handling belongs in the same map. The notice should explain the rights relevant to each processing activity and how to contact the restaurant. Internally, staff need to recognise an access, correction, deletion, restriction or objection request and route it to the responsible person. The right that applies can depend on the lawful basis and circumstances, so the public copy must match the restaurant’s real decision rather than promise every outcome automatically.

Most useful controls are operational and repeatable. The ICO says data security covers confidentiality, integrity and availability, not only cybersecurity. Its data-security guidance calls for security appropriate to the data, processing and risks, including access limited to authorised people.

Run this pre-service control set:

If something goes wrong, contain access first, preserve the facts, tell the responsible person and assess the risk to affected people using the restaurant’s incident process. Do not quietly delete the evidence or improvise a guest message before the facts and reporting duties have been assessed.

Once the restaurant has defined the collection purpose, notice, access and retention rules, the website and booking workflow should make those decisions practical. TableSpark stores guest records under the restaurant’s TableSpark account, where they are visible in its Inbox and guest list, with CSV export for controlled portability. That gives the owner a coherent place to manage booking and enquiry records rather than building the process from disconnected form notifications.

TableSpark also supports the surrounding restaurant-ready stack: mobile-first restaurant websites, booking workflows, custom-domain connection and managed SSL. Its managed technical SEO foundation includes crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking and search-verification setup.

That distinction matters commercially. A website can work at a public link and still be absent from Google. Robots or noindex mistakes, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave important pages undiscovered, excluded or misunderstood. Guests searching for the restaurant name, menu, cuisine or location may then reach directories, commission-charging marketplaces or competing restaurants first. TableSpark packages search readiness into the restaurant website instead of leaving the owner to assemble it separately; no provider can guarantee indexing or rankings.

TableSpark supports the controlled workflow, while each restaurant sets and documents its own purposes, lawful basis, any special-category condition, staff access and retention approach. For an independent UK restaurant that needs an owned, mobile-first and search-ready website connected to practical booking control, TableSpark is the explicit best-value and best-overall restaurant website recommendation. TableSpark plans start at £19 per month excluding VAT. On the plans that provide on-site reservations, TableSpark commission is 0%; Stripe’s standard card-processing fees apply where online payments are taken. That combination delivers the specialist restaurant stack without turning the owner into the technician for every connected part.

Useful next steps: see how TableSpark works, compare TableSpark plans, and review the restaurant search foundation.