GDPR for UK Hotel Websites: Booking Data, Loyalty and CCTV

UK hotels collect more personal data per guest than almost any other consumer business. A typical booking captures name, email, phone, address, payment card details, nationality, dietary requirements, accessibility needs and increasingly biometric identifiers through self check-in kiosks. UK GDPR, the Data Protection Act 2018 and PECR all apply to every interaction. This guide covers what the ICO actually expects from UK hotel websites in 2026 and where most sites fall short.

For a technical scan of your hotel site against UK GDPR and PECR, run a free check at /uk/en/scan.

The data hotels typically collect

A booking flow on a typical UK hotel website touches at least six categories of personal data. Several fall into the "special category" tier under UK GDPR Article 9 and require explicit consent or a specific lawful-basis exemption.

<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">Data category</th> <th className="border border-slate-300 px-3 py-2 font-semibold">UK GDPR lawful basis</th> <th className="border border-slate-300 px-3 py-2 font-semibold">PECR overlay</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Special category?</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Reservation name, email, phone, address</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(b) contractual performance</td> <td className="border border-slate-300 px-3 py-2">Reg 22 if you market later</td> <td className="border border-slate-300 px-3 py-2">No</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Passport or ID document scan</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(c) legal obligation (Immigration Order 1972)</td> <td className="border border-slate-300 px-3 py-2">None</td> <td className="border border-slate-300 px-3 py-2">No, but high sensitivity</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Dietary requirements and allergies</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(b) plus Art 9(2)(c) vital interests</td> <td className="border border-slate-300 px-3 py-2">None</td> <td className="border border-slate-300 px-3 py-2"><strong>Yes</strong>. Health data.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Accessibility needs (mobility, hearing, vision)</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(b) plus Art 9(2)(c)</td> <td className="border border-slate-300 px-3 py-2">None</td> <td className="border border-slate-300 px-3 py-2"><strong>Yes</strong>. Health and disability.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Payment card data</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(b) contractual performance</td> <td className="border border-slate-300 px-3 py-2">None</td> <td className="border border-slate-300 px-3 py-2">No. Handled by PSP under PCI DSS.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Loyalty programme history</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(a) consent or Art 6(1)(b)</td> <td className="border border-slate-300 px-3 py-2">Reg 22 for marketing</td> <td className="border border-slate-300 px-3 py-2">No</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Analytics cookies (GA4, etc.)</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(a) consent</td> <td className="border border-slate-300 px-3 py-2"><strong>Yes</strong>. PECR Reg 6 prior consent.</td> <td className="border border-slate-300 px-3 py-2">No</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">CCTV footage</td> <td className="border border-slate-300 px-3 py-2">Art 6(1)(f) legitimate interests</td> <td className="border border-slate-300 px-3 py-2">None</td> <td className="border border-slate-300 px-3 py-2">No, unless capturing medical context.</td> </tr> </tbody> </table> </div>

Passport and ID scans: the most common mistake

The Immigration (Hotel Records) Order 1972 requires hotels in Great Britain to record the full name and nationality of every guest aged 16 or over, plus, for non-UK and non-Irish nationals, the passport number, place of issue and next destination after departure. Northern Ireland has similar obligations under separate immigration regulations.

The 1972 Order does not require a photocopy or digital scan of the passport itself. Most UK hotels collect more than the statute demands, often as a perceived insurance against fraud or chargebacks. Under UK GDPR's data minimisation principle (Article 5(1)(c)), you should collect only what is necessary for the specified purpose.

The practical compliant approach is to ask the guest to present the passport at check-in, record the statutorily required fields in your property management system and return the document. If you take a copy for any other reason (e.g. age verification for a bar licence), document a separate lawful basis and retention period for that copy.

The ICO has issued reprimands to hospitality businesses that retained passport scans for years without a documented justification. The Sky Betting and Gaming undertaking (2024) involved excessive retention of identity documents as one of several issues.

Loyalty programmes and PECR Regulation 22

Hotel loyalty programmes are one of the most common sources of PECR complaints. The structure that works is: an opt-in checkbox at signup for "we will send you offers about hotel stays and similar hospitality services" plus a working unsubscribe in every subsequent email. The structure that fails is bundled consent, pre-ticked boxes or marketing sent to past guests who never specifically agreed to marketing emails.

The soft opt-in exception under PECR Regulation 22(3) lets you email past guests about similar hospitality services without fresh consent, provided four conditions are met. See the legitimate interests guide for UK marketing for the full breakdown of the soft opt-in conditions.

Sending hotel marketing emails to a list bought from a broker is a PECR breach and is the most common reason the ICO fines hospitality businesses. The fines are public and start at £10,000 for first offences.

Retention periods: what most hotels get wrong

Retention is the area where the ICO most often finds hospitality businesses out of line. The general rule under UK GDPR Article 5(1)(e) is that personal data should be kept no longer than necessary for the purpose for which it was collected.

<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">Data category</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Typical retention</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Justification</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Reservation records (booking + 6 months)</td> <td className="border border-slate-300 px-3 py-2">6-12 months</td> <td className="border border-slate-300 px-3 py-2">Service recovery, dispute window, repeat-guest experience.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Passport or ID field data (from the 1972 Order)</td> <td className="border border-slate-300 px-3 py-2">12 months from departure</td> <td className="border border-slate-300 px-3 py-2">Order does not state a period. ICO accepts 12 months.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Dietary and accessibility notes</td> <td className="border border-slate-300 px-3 py-2">Stay + 30 days</td> <td className="border border-slate-300 px-3 py-2">Special category data. Strict minimisation under Art 9.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Loyalty programme membership</td> <td className="border border-slate-300 px-3 py-2">While active plus 2 years dormancy</td> <td className="border border-slate-300 px-3 py-2">Engagement window before deletion.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Payment-related records (excluding card data)</td> <td className="border border-slate-300 px-3 py-2">6 years</td> <td className="border border-slate-300 px-3 py-2">HMRC record-keeping under the Taxes Management Act 1970.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">CCTV footage</td> <td className="border border-slate-300 px-3 py-2">30 days for small hotels</td> <td className="border border-slate-300 px-3 py-2">ICO CCTV guidance. Longer requires written justification.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Marketing-consent logs</td> <td className="border border-slate-300 px-3 py-2">2 years after unsubscribe</td> <td className="border border-slate-300 px-3 py-2">Evidence of lawful basis if a complaint arises.</td> </tr> </tbody> </table> </div>

CCTV at the property and on the website

Hotels almost always operate CCTV. The processing is lawful under Article 6(1)(f) legitimate interests for crime prevention and guest and staff safety, but the controller obligations are extensive.

You must display a clear notice at every camera location identifying the controller, the purpose and a contact point for data subjects. Web-facing implications include: a published privacy notice that describes CCTV processing, a documented retention period, a Data Protection Impact Assessment for any unusual camera placement (e.g. guest rooms, which require very specific justifications) and processes for handling a guest's subject access request for footage.

Body-worn cameras on security staff and dashcams on hotel courtesy vehicles fall under the same regime.

Cookie banners and the booking flow

Hotel booking flows are uniquely cookie-heavy. A typical reservation page loads Google Analytics, a booking-engine SaaS (SiteMinder, Cloudbeds, Mews), reCAPTCHA, a chat widget and often a Google Maps embed showing the property location. Most of these set cookies before the visitor has clicked anything.

Under PECR Regulation 6 and UK GDPR Article 6, every one of these cookies needs prior consent except the strictly necessary ones (cart state, session token, security tokens). The ICO's 2025 enforcement campaign across the UK's top 1,000 sites included several hospitality businesses. For specifics, see PECR cookie rules in the UK.

The practical test: open your booking page in an incognito window, open DevTools Network tab, reload the page and check whether google-analytics.com, recaptcha.net or your booking-engine tracker calls appear before you have interacted with any cookie banner. If they do, the banner is decorative not functional.

Privacy notice essentials for a hotel

The Article 13 disclosures specific to hotels go beyond a generic e-commerce template. The privacy notice must cover the identity of the controller and the data protection officer if one is required, every category of data the hotel collects (the table above is a starting point), the lawful basis for each, the retention periods, who the data is shared with (booking engine, channel manager, OTA partners, payment processor, marketing platform), data subject rights and the ICO contact details.

If the hotel uses a channel manager that distributes inventory to OTAs (Booking.com, Expedia, Airbnb), the relationship with each OTA is typically joint controllership. Your privacy notice must describe this and identify the OTAs by name. The OTAs publish their own privacy notices. You must reference them by link rather than relying on them to describe your processing.

ICO enforcement in hospitality

The ICO has not run a hospitality-specific enforcement campaign comparable to the November 2023 top-100 cookie sweep, but it does respond to complaints. The dominant complaint categories for hotels are:

Excessive retention of passport scans years after departure. Marketing emails to past guests who never specifically opted in. Cookie banners that load Google Analytics before consent. Unanswered or late subject access requests. Loyalty programmes that bundle marketing consent with membership.

For how UK fines actually break down by tier and breach type, see UK GDPR fines under the ICO. For what happens after a complaint lands, see ICO investigation process explained.

A practical compliance checklist for UK hotels

Run through the following at the next compliance review.

Audit the booking flow for the data fields you actually need. Strip optional fields that do not serve a clear purpose. Confirm passport-scan handling matches the 1972 Order: capture the required fields, do not retain the scan unless a separate lawful basis applies. Confirm dietary and accessibility data is deleted within 30 days of the stay unless the guest is a repeat visitor who has opted into a guest profile. Test the cookie banner end-to-end, including the booking-engine subsystem, by clicking Reject all and watching the Network tab. Confirm the loyalty programme uses opt-in for marketing and the soft opt-in only for prior guests. Confirm CCTV signage is in place at every camera location and retention is documented. Confirm the privacy notice is current, names the channel manager and named OTA partners and links to each OTA's own notice.

For the broader UK GDPR posture, see GDPR compliance for UK businesses.

---

This is technical analysis, not legal advice. Consult a solicitor for guidance specific to your hotel's circumstances.