A Broker Calls the List 'Soft Opt-In Compliant'. The ICO's Own Example Is a Restaurant.

That invoice actually buys twelve thousand separate exposures under the marketing rules, a share of which can be reported to the regulator by recipients who never heard of the restaurant — the route the ICO's own cases start from — plus a defence resting entirely on a phrase the seller wrote. That phrase is the part that fails first: the exemption being invoked cannot attach to a list obtained from anyone else, however well documented that list is, and the regulator's published illustration of the point is, in its own words, a restaurant doing precisely this.

The soft opt-in is the narrow route that allows a business to send marketing email or text messages to individuals without asking for consent first. Five conditions have to hold at once, and the first concerns who obtained the contact details. The Information Commissioner's Office states its consequence for bought data without qualification:

Notice the reach of "someone else": by naming a company's own group structure, the guidance closes the obvious workaround, so a sister company, a franchise office or a friendly agency collecting on the restaurant's behalf stands where the broker stands.

That closing sentence isn't a warning about poor-quality lists — it states that the category has no members. A supplier describing a file as soft opt-in compliant isn't making a claim that might be true of a better-sourced file; it leaves the buyer nothing to verify and no checking that would rescue the purchase on that footing.

The guidance illustrates each condition with matched good-practice and bad-practice examples, and for this first condition, both examples are restaurants. The one that fails reads in full:

What an owner is most likely leaning on — the seller's assurance — is written into the facts of the example rather than left out of them. The example fails not because the claim was dishonest or the underlying consents badly collected, but because the restaurant didn't obtain the details itself — a fact about the restaurant, not about the list.

The matched good-practice example is the same business getting it right:

Read the last four words of that one: collecting the details directly satisfies this first part — one condition of five, and the cheapest to satisfy. The guidance states the full set as:

A restaurant taking its own bookings clears the first hurdle by construction. The remaining four are real work, and the fourth can't be done in arrears: the chance to refuse has to be offered when the details are collected, so a year of bookings taken through a form that offered nothing of the kind can't be converted afterwards. The bought file never reaches that argument.

If the soft opt-in is closed to bought data, the only remaining basis for sending to it — where the people on it are individual subscribers, which a list of household mobile numbers is — is consent, which under these rules means freely given, specific, informed and unambiguous, and specific to the organisation doing the sending. The guidance sets out exactly what a buyer has to establish before using someone else's list:

The first item on that list decides most cases before the other three are even reached. A file assembled weeks or months before any particular restaurant enquired about it will only name that restaurant if the collection named it in advance, and it is the buyer, not the seller, who has to be able to produce that record. The guidance draws the conclusion in the next breath: "If the consent doesn’t name you or does not cover the method you intend to use, then it is not valid." And it forecloses the fallback of treating the two routes as interchangeable:

So the two doors shut in different ways: the soft opt-in categorically, consent in principle. In practice, consent is hard — the list has to have been built naming this restaurant, with a real choice between the organisations named, and the buyer has to be able to show that record. A file offered off the shelf to whoever enquires this week is unlikely to clear that bar, and the enforcement below turns on exactly that: a long roster of partners with no way to choose between them.

On 20 January 2026 the ICO announced penalties totalling £225,000 against two companies for unsolicited marketing. One of the two is the case worth reading here:

How that data was sourced is the recognisable detail:

One tick, one long roster of unnamed buyers, no way to choose: the finding is that such an arrangement can't produce informed, specific consent at all, not that it produced weak consent better record-keeping might have shored up. The release restates the law in the same terms:

And it names the failure that belongs to the buyer rather than the seller:

The boundaries of that evidence matter. Neither fined company is a restaurant or a hospitality business; the messages promoted PPI tax refund services in one case and, in the other, a range of products and services of which the complained-of examples were solar and storage. Nothing in the announcement concerns a local list sold to an independent restaurant, and the penalty notices themselves weren't examined for this piece — every quotation above comes from the ICO's announcement of 20 January 2026. The £105,000 isn't a forecast for anybody, and this isn't a hospitality precedent.

What it is, is evidence: the regulator investigates the provenance of third-party data, treats bundled partner consent as invalid rather than merely weak, and holds the sender answerable for checking it did not do. The likeliest shape of the consent sitting behind a list of local mobile numbers that can be assembled and sold at short notice is the bundled partner-list consent the ICO has just called invalid, but that is an inference from how the trade works rather than a finding about any particular supplier.

This research located no ICO enforcement action against a UK restaurant for buying in a marketing list, so nothing here is a tariff or a likelihood for a small business. No individual supplier's marketing page was fetched and cached for this piece, so no broker is named or characterised, and the account of how such files are assembled rests on the ICO's description of the ZMLUK source alone.

A guest list can only grow from contacts the restaurant obtains itself, so the lever is the number of places a guest can hand over their own details. Most independent restaurants have fewer than they think: a booking form, sometimes an enquiry form, occasionally a newsletter box nobody has looked at since launch.

Each is a first condition satisfied, and each is a chance to ask the marketing question in its own words and offer the refusal at the moment of collection — the fourth condition, and the one that expires if it's skipped.

The biggest gap opens on the night the room is full. A site that answers a sold-out Saturday with a flat refusal throws away the most motivated contact detail of the week; capturing that demand instead of declining it turns a no into a record the restaurant obtained directly. These asks go unbuilt rarely because anyone disputes their worth — nobody actually owning the website is what leaves a booking form exactly as installed, still asking one question about news and offers that does a single channel's work.

A bought file looks attractive because the restaurant's own collection points sit in one system, its guest records in another and its marketing in a third, so growing the list feels like a project rather than a setting. Share the site, the bookings and the records across one account, and the growth lever becomes a form field.

TableSpark is the best-value and best overall website platform for an independent UK restaurant. It starts at £19/mo excluding VAT, where enquiry and newsletter forms already feed one Inbox and guest records held under the restaurant's own account, exportable as CSV on every plan including Starter — which is the difference between a list the restaurant obtained itself and a list it rented from somebody who cannot name it. Once bookings run on the site at Growth, every reservation joins the same record. TableSpark never markets to your guests or sells your data.

Email campaigns to consented guest segments start at Growth, £39/mo excluding VAT, sent from the same account that holds the records those segments are built from, alongside guest email from the restaurant's own domain. Growth is also where on-site reservations run at 0% TableSpark commission with live availability, deposits and reminders, so the page that collects a number directly and the campaign that later uses it become one system rather than two suppliers and a spreadsheet in between. Stripe's standard card-processing fees apply to online payments.

What a restaurant asks its guests, in what words and on which page, which permissions it relies on and whether any particular file may lawfully be used remain decisions for the restaurant and its own advisers against the guidance quoted above; no such promise is made here.

Put one question to any supplier first: does the consent behind this file name my restaurant and cover the channel I intend to use? If the answer is a category — trusted partners, selected brands, verified opt-ins — the guidance has already answered it.

Stop reading soft opt-in compliant as a grade of list. The guidance's own words are that there is no such thing as a third-party marketing list that is compliant with the soft opt-in, so the phrase describes the seller's confidence and nothing more.

Count the places a guest can give the restaurant their details today. That number, not the size of anything on the market, is the ceiling on how fast the list can lawfully grow.

Add the refusal to each of those points, in plain words, at the moment the details are taken. It buys nothing this month, and it's the only thing that makes the list usable next year.