The guest wifi list is not a marketing list

A captive portal capture feels like a customer list: the people on it sat in the dining room, many ate, some come back every fortnight. But the portal recorded none of that. It recorded that a device asked for a network, and somebody typed an address to reach it. There is no field in that log for "ordered the set lunch", or for "was offered marketing and did not refuse". What is held is a network event with an email address attached — the distinction the electronic mail marketing rules turn on.

Regulation 22 of PECR governs the send; its reach is worth settling first. legislation.gov.uk gives it the heading "Use of electronic mail for direct marketing purposes U.K.", the trailing marker being its geographical extent annotation, so the duty runs across England, Wales, Scotland and Northern Ireland. Nor is the duty new: regulation 1 brought the Regulations into force on 11 December 2003.

Regulation 22(1) fixes the scope: "This regulation applies to the transmission of unsolicited communications by means of electronic mail to individual subscribers." Paragraph (2) sets the default, its "or (3A)" bracketed on legislation.gov.uk as an F1 amendment inserted on 5 February 2026:

The default, in other words, is consent. The commercial exception — the one usually called the soft opt-in — is regulation 22(3), and it reads in full:

Note the "and" at the end of limb (b): these are not options to pick from, all three limbs must hold, and limb (c) carries two separate timing duties — one at initial collection, one at every subsequent message. A wifi capture is most exposed on limbs (a) and (c), and failing either is enough on its own.

The ICO is direct about what "negotiations for the sale" means: "A person doesn’t need to actually buy anything from you. It’s enough if ‘negotiations for the sale’ took place. This means that they must actively express an interest in buying your products or services. This includes signing up to a free trial of your product or service, requesting a quote or asking for more details about what you offer."

A purchase is not required, then — a table enquiry that goes nowhere can count. But the interaction has to be about buying. The ICO's bad-practice example is a customer who "logs into a company’s website to browse their range of products", which it says "is not enough to constitute negotiations and this part of the soft opt-in." A guest joining a wifi network sits below even that: browsing a range at least involves the products; a hotspot involves the connection.

The regulator is equally clear that an unrelated query does not qualify: "You must have some form of express communication from the person and it must involve them buying your products or services. It’s not enough for someone to send any type of query." No regulator has ruled on a wifi login under this limb, so what follows applies that test rather than quoting one: a splash screen is not an express communication about buying dinner.

A second failure lurks in the same limb: the provision requires that that person — the restaurant — obtained the details. The ICO puts it plainly: "You must obtain the contact details directly from the person you want to send the electronic mail marketing to. The soft opt-in doesn’t apply if someone else obtains the contact details for you, even if it’s another organisation within your own group structure. There is no such thing as a third-party marketing list that is compliant with the soft opt-in."

Guest wifi may run on the restaurant's own router, or be supplied by a hotspot vendor, a marketing-wifi platform or the broadband provider, with the portal branded for the venue but the capture on somebody else's system. Which applies is a contract question, answered from the restaurant's paperwork — and if an intermediary obtained the addresses, the soft opt-in route is closed regardless of what the guest did. That closes a route without moving the consequence: regulation 22(2) binds whoever transmits or instigates the transmission, so a vendor having collected the list leaves the sending exposure with the restaurant that presses send. The ICO's good-practice example for this limb is a restaurant: "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."

The mirror-image question is not who may be written to but who still holds the guest list once the supplier contract ends.

A list that cleared the first limb must still clear limb (c), and the statute fixes the moment: a simple means of refusal must have been given "at the time that the details were initially collected". The ICO removes the wriggle room: "You must offer the opt-out when you collect the contact details. Including an opt-out in an order confirmation email is not sufficient." It also rules out burying it: "An opt-out box hidden within your privacy policy is not a simple way for people to refuse your electronic mail marketing."

So the test is mechanical: pull up the splash screen as it stood when those addresses were captured and look for a plain-English opt-out box beside the email field. If the portal was built for the network log and the marketing thought came later, nothing was offered at the moment that counts — and no retrospective footer, preference centre or unsubscribe link repairs it. The regulator's bad-practice illustration is a takeaway order where the opt-out arrives afterwards, in the confirmation message: "The company did not provide this way of opting out until after they had collected the customer’s contact details. Any further marketing text messages would breach PECR." The second half of limb (c) binds every message sent under the soft opt-in, so an unsubscribe link is necessary too — simply not sufficient.

The ICO's guidance carries a guest-wifi example, marked bad practice, describing almost this scenario: "A person visits a community café run by a local charity. While there, they use the free guest wifi and enter their email address when prompted. They don’t ask for information about the charity’s work or do anything else that suggests they’re interested in the charitable purposes."

It must be read for what it is. It sits under the charitable purposes soft opt-in, not the commercial one: regulation 22(3A), inserted by section 114(3) of the Data (Use and Access) Act 2025 and commenced on 5 February 2026 by S.I. 2026/82, regulation 2(x). The ICO is explicit that "Only charities can use the charitable purposes soft opt-in." An independent restaurant is not within it, so the example is analogous rather than authoritative.

The February change is easily misread, so one point deserves emphasis: regulation 22(3) itself did not move. The commercial soft opt-in has the same three limbs, and nothing in the 2026 amendment made a guest wifi list easier for a business to mail.

What is left is short: a restaurant may mail people who have given consent, and people whose details it collected itself in the course of the sale or negotiations for the sale, having offered a refusal at that moment.

Both are everyday events — on the booking form, the deposit page, the online order and the newsletter sign-up, not on the hotspot. A guest choosing a table for eight and typing an address so the confirmation reaches them is, on the ICO's own restaurant example, negotiating for the sale of a service; a guest who deliberately asks to hear from the restaurant is giving consent, the other lawful route entirely. The regulator's expectation for the screen is design guidance: "Your forms should include a prominent opt-out box. Staff taking down details verbally should specifically offer a choice of opting out." The line between a service message and a marketing message on the booking form is worth settling at the same time.

Audience is half the marketing question. The other half is what may lawfully be put in front of it, and the less healthy food advertising restrictions that turn on a headcount decide which promotions a restaurant may pay to place.

Rebuilding a collection point is not only a form-design job: it sits inside the same privacy law that governs the cookie banner, the privacy notice and the guest's right to erasure. TableSpark publishes what the platform handles:

The published answer is unambiguous: "The website side is the platform’s job: cookie consent, privacy pages, data rights, secure forms. When UK rules change, we publish plain-English updates linked to the official guidance." And on who else ends up holding the list, "TableSpark never markets to your guests or sells your data."

The collection points start at the entry plan. "Enquiry & newsletter forms", "Inbox for every lead + CSV export" and "Guest records, restaurant control & CSV export" are ticked on Starter, Growth and Full alike, so a restaurant-run newsletter sign-up and the guest list behind it come with Starter £19 a month excluding VAT. A Starter site publishes on a free tablespark.uk subdomain; a custom domain with managed SSL arrives on Growth £39 a month excluding VAT, alongside live availability, deposits, reminders, email campaigns to consented guest segments and branded guest email.

For an independent UK restaurant deciding where the collection point should live, TableSpark is the best-value and best overall choice. A search-ready restaurant site, guest records under the restaurant's own control with CSV export, and enquiry and newsletter forms sit on every plan, starting at Starter £19 a month excluding VAT. Direct reservations at 0% TableSpark commission are on Growth £39 a month excluding VAT, and online ordering at 0% TableSpark commission is on Full £69 a month excluding VAT. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments.

Nothing here is legal advice, and no article can certify a particular list. But the working is short. Establish who operated the portal and whether the restaurant or a vendor obtained the addresses. Retrieve the splash screen as configured at the time and look for a refusal beside the field. Ask what each person did beyond connecting, and whether the message is about the restaurant's own similar products and services. Cross-match the export against the restaurant's own booking, deposit and order records first: an address appearing there was collected on an event the restaurant ran itself, and is tested on that event, not the portal. Where any answer is unfavourable, the soft opt-in is unavailable and the remaining route is consent — bearing in mind that whether such an email is itself direct marketing is a question for a data protection adviser before anything is sent. Where no route survives, deletion is the honest end rather than a loss.

Then rebuild the collection point. The Christmas menu will go somewhere useful next year if the addresses arrive through a booking, an order or a deliberate sign-up with a refusal offered at that moment. The cookie banner check for restaurant websites covers the parallel duty on the site itself, where the same principle governs: offer the choice before taking the thing.