GDPR-Compliant WiFi Data Capture: What Every UK Hospitality Operator Needs to Know

Capturing guest data through a WiFi captive portal is entirely legal in the UK — but the compliance requirements are specific and, in some areas, stricter than many operators realise. Getting it wrong doesn't just expose you to an ICO complaint; it can invalidate your entire guest database and the marketing built on top of it.

This guide covers the key obligations under UK GDPR, the Data Protection Act 2018, and PECR — the three frameworks that govern WiFi data collection in UK hospitality venues. If you're new to captive portals, read our complete guide to captive portals first.

The three legal frameworks that apply

1. UK GDPR

The UK's retained version of the EU General Data Protection Regulation governs the collection, processing and storage of personal data. For WiFi data capture, the most relevant requirement is the need for a lawful basis for each processing activity.

2. Data Protection Act 2018

The DPA 2018 supplements UK GDPR and sets out enforcement powers for the Information Commissioner's Office (ICO). It also establishes specific provisions around sensitive categories of data (health, ethnicity, political opinions) — not typically relevant for basic WiFi login data, but relevant if you collect dietary preferences or disability information.

3. PECR — Privacy and Electronic Communications Regulations

PECR is the regulation most operators overlook. It governs electronic marketing — specifically email and SMS. Under PECR, you cannot send marketing messages to a guest who connected to your WiFi unless they have given specific, informed consent to receive marketing from your business. This is a higher bar than UK GDPR's "legitimate interests" — you cannot rely on legitimate interests for direct marketing by email or SMS.

Lawful basis: what you need for each activity

Different processing activities have different lawful bases. Here is how they map for a typical hospitality WiFi deployment:

• Authenticating the guest on your WiFi network: Legitimate interests (Art. 6(1)(f)) — you have a legitimate operational reason to know who is on your network. No separate consent required for basic authentication.
• Building a CRM record: Legitimate interests — provided the guest is informed at the point of data collection (via your portal's Privacy Notice).
• Sending marketing emails: Consent (Art. 6(1)(a)) — and additionally, specific PECR consent. This must be a separate, unticked checkbox. It cannot be bundled with WiFi access terms.
• Syncing data to a third-party CRM: Same lawful basis as the underlying processing. If you're syncing to send marketing, you need marketing consent. If syncing to log visit history, legitimate interests applies.

What valid consent looks like

UK GDPR defines valid consent as "freely given, specific, informed and unambiguous." For WiFi data capture, this means:

• Freely given: You cannot make access to WiFi conditional on accepting marketing. The "tick this box to get WiFi" approach where the box is a marketing opt-in is not freely given. WiFi access and marketing consent must be separable — guests can get online without opting in to marketing.
• Specific: The consent wording must describe what you'll send, not just "updates and offers." "Occasional email offers and news from [Venue Name]" is specific enough. "We may contact you from time to time" is not.
• Informed: A link to your Privacy Policy must be present on the portal page. Guests must be able to see what data you collect and how you use it before they consent.
• Unambiguous: Consent must be a positive action — a tick in an unticked box. Pre-ticked boxes are not valid consent under UK GDPR.

Consent records: what you must store

The ICO expects organisations to be able to demonstrate that consent was given. For each guest who opts in, you must store:

• The date and time consent was given
• The exact wording of the consent statement shown to the guest
• The version of your Privacy Policy in place at that time
• The method by which consent was given (captive portal checkbox)

CaptiveWiFi captures and stores all four data points automatically for every opt-in through the portal. This means if you ever receive a Subject Access Request (SAR) or an ICO enquiry, you can retrieve a complete consent record for any guest in your database.

Data retention

You cannot store personal data indefinitely. Your Privacy Policy must state how long you retain guest data, and your actual practice must match your policy.

A proportionate retention policy for hospitality WiFi data might look like:

• Active guests (visited in the last 24 months): retained
• Guests who have not visited for 24 months: reviewed and deleted unless there is a specific reason to retain them (e.g., outstanding loyalty points)
• Guests who withdraw marketing consent: removed from marketing lists immediately; basic visit records may be retained for operational purposes under legitimate interests

The right to erasure

Under UK GDPR, guests have the right to request deletion of their personal data. This is sometimes called the "right to be forgotten." Your captive portal platform must support the ability to delete individual guest records — including any synced copies in connected CRM platforms.

If a guest submits an erasure request and you have synced their data to three different platforms (your CRM, your email tool, and a loyalty provider), all three must delete the record. Your Data Processing Agreement with each sub-processor should confirm they can execute deletion requests.

The controller/processor relationship

When you use a captive portal platform like CaptiveWiFi, you are the data controller — you determine the purpose and means of processing. CaptiveWiFi acts as your data processor — processing data on your behalf under your documented instructions.

This relationship must be formalised in a Data Processing Agreement (DPA) before any data is processed. The DPA sets out:

• The subject matter and duration of processing
• The nature of the processing and type of data
• Your rights to audit and instruct
• Obligations regarding sub-processors (e.g., cloud hosting providers)
• Breach notification timelines (processors must notify controllers within 72 hours of discovering a breach)

Under UK GDPR, operating without a DPA in place is itself a breach — separate from any issue with the data processing. CaptiveWiFi's DPA is incorporated into our Terms of Service.

ICO registration

Most organisations that process personal data must register with the ICO and pay a data protection fee. Registration is required annually. There are exemptions for very small organisations, but any hospitality business capturing and using guest data for marketing will almost certainly need to register.

Fines for operating without ICO registration are separate from fines for substantive GDPR breaches — you can be fined for both. CaptiveWiFi is registered with the ICO (registration number Z8359853).

Pre-launch compliance checklist

Before you go live with a captive portal at your venue, work through this checklist:

• Privacy Notice is displayed on the portal page, with a link to your full Privacy Policy
• Marketing opt-in is a separate, unticked checkbox
• WiFi access is not conditional on accepting marketing
• Consent wording is specific about what you'll send
• Consent records (timestamp, wording, policy version) are stored automatically
• Data Processing Agreement is in place with your captive portal provider
• DPAs are in place with all CRM and loyalty platforms you sync data to
• You have a process for handling Subject Access Requests and erasure requests
• Your Privacy Policy accurately describes your data retention periods
• Your organisation is registered with the ICO

If you'd like to see how CaptiveWiFi handles these requirements in practice, book a demo and we'll walk through the consent flow, consent record storage, and DPA documentation. Once you're confident on compliance, see how venues are measuring the ROI of guest WiFi marketing.