The Three Laws Behind a Restaurant Birthday-Club Sign-Up Form

Three separate pieces of law apply to that one sign-up form, and each answers a different question. All three are compulsory, and the one most owners reach for first is not among them.

Most of the over-engineering comes from one anxiety: is a birth date "sensitive," the way health data or religious belief is? UK GDPR Article 9 answers with a closed list:

A date of birth appears nowhere on that list, and the list is closed, not illustrative. The ICO confirms it independently:

A date of birth is therefore not special category data, and it does not become special category data by sitting next to a child's name on the form. Nor does it need an Article 9 condition, a sensitivity-triggered impact assessment, or explicit consent beyond the ordinary rules below, simply because the field asks for a birthdate.

Storing the birth date is a UK GDPR question, governed by Article 6. The Data (Use and Access) Act 2025 amended this article on its own clock, and section 70 was not among the provisions commenced on 20 August 2025 by S.I. 2025/904; that tranche carried Article 9(2) and the PECR direct-marketing definition. Article 6(1)(ea) and the new paragraphs 5 to 12 came in for specified purposes on 19 June 2025 and otherwise on 5 February 2026, by S.I. 2026/82. Before that, the legitimate-interests basis in paragraph (f) carried no worked examples. Now the article names direct marketing as the first illustration:

That is not a blank cheque: the same paragraph still requires the processing to be necessary and not overridden by the guest's own rights:

A restaurant holding a guest's date of birth for a birthday offer sits comfortably inside that basis: the purpose is narrow and the guest volunteered the date for that reason. Where a child is involved, that final clause matters, and it reappears below. The same Act also inserted a "recognised legitimate interest" basis at Article 6(1)(ea), reserved for the conditions in Annex 1: disclosure for a public task, national and public security, emergencies, crime, safeguarding. A birthday scheme is not among them, so the basis doing the work here is the older 6(1)(f).

A lawful basis to hold the date of birth says nothing about whether the restaurant may email or text the offer when the date arrives. That belongs to the Privacy and Electronic Communications Regulations 2003 (PECR), a regime separate from the UK GDPR. Regulation 22 sets the default:

PECR's "electronic mail" is defined broadly enough to include "messages sent using a short message service", so a birthday text counts just like a birthday email. The default rule is consent. Without it, a restaurant needs an exception, and the one that matters here is regulation 22(3), the "soft opt-in":

Every part of that has to be true at once. The ICO's own worked examples show a table booking satisfying limb (a), and the opt-out has to sit at the point of collection, in plain language:

A bare "join our birthday club" form hits a problem the ICO's worked examples do not answer. Every published soft opt-in example ties the contact details to a purchase, a booking or a takeaway order, not a free-standing sign-up. No source confirms whether a free-standing loyalty form satisfies "the course of the sale or negotiations for the sale of a product or service", and the safer reading is that it probably does not. The fix costs nothing: fold the sign-up into the booking or order flow, or collect explicit opt-in consent.

A second soft opt-in sits in the same regulation and looks open to anyone: the "charitable purposes" soft opt-in, inserted at regulation 22(3A) by the Data (Use and Access) Act 2025 and commencing on 5 February 2026 under S.I. 2026/82:

That exception is open only to a body meeting PECR's own definition of a charity. A restaurant, however community-minded its birthday offer, is not a charity, so that route is closed. The only soft opt-in available is the ordinary version at regulation 22(3), above.

This is the part most compliance guidance skips, and the weakest link in this article. Section 123 of the Data Protection Act 2018 requires the ICO to maintain a statutory code covering "information society services likely to be accessed by children", the Children's code. It binds rather than advises: "The code took effect on 2 September 2020, so you must conform with the code from 2 September 2021." Its scope guidance sets the trigger deliberately wide:

A family restaurant's website, birthday-club form included, is realistically the kind of site under-18s browse alongside their parents, even though the target customer is an adult diner. No source found for this article states, in so many words, that a restaurant loyalty scheme triggers the Children's code. That conclusion is this article's own reasoned combination of general ICO scope guidance, not a stated ICO position on hospitality specifically. Treat it as a real possibility to design around, not a settled classification.

If it does apply, the requirements are modest. Standard 8, on data minimisation, states it plainly:

For a birthday offer, that argues for asking day and month only, where the promotion does not need the year. Standard 3 calls for a risk-based approach rather than a disproportionate verification system, and the ICO accepts a light-touch method: "This is where a user simply states their age but does not provide any evidence to confirm it. It may be suitable for low risk processing or when used in conjunction with other techniques." A self-declared age tick box, sized to a birthday discount's actual risk, is defensible.

The regulator is not treating this code as dormant guidance from 2020. Its August 2026 strategy update records "Issuing fines of £14.47 million to Reddit and £247,590 to MediaLab (the owner of Imgur) for using children’s personal information unlawfully." Those are social-media and image-hosting platforms, not restaurants; no hospitality-sector Children's-code enforcement was found, and none should be implied. The narrower point is that Standard 8 and Standard 3 sit behind a code actively enforced in 2026, reason enough to design a birthday-club form conservatively.

One further wrinkle is open rather than settled. Since 29 April 2026 the Secretary of State has held a power, inserted into Article 8 by the Children's Wellbeing and Schools Act 2026, to move the digital age of consent between 13 and 16. The power has not been exercised, and 13 remains operative today: Article 8(1) still reads that a child's own consent is valid "where the child is at least [F113 years old]", with a parent or guardian required below that. A birthday-club design that assumes 13 is permanent should be revisited if the power is used.

None of this needs three legal processes bolted onto a five-field form. A sign-up that survives all three regimes collects the date of birth for the stated purpose only, day and month unless the promotion genuinely needs the year. The form sits inside an actual booking or order flow rather than standing free, so the soft opt-in's "course of the sale" condition is met rather than assumed. The opt-out appears in plain language at collection, not folded into a privacy policy nobody reads. And the age question is self-declared, proportionate to the actual risk, rather than ignored or over-built into a verification system the form does not need.

TableSpark is the best-value and best overall website platform for an independent UK restaurant running exactly this kind of scheme, because the pieces above are built in. Every plan carries guest records held under the restaurant's own account with CSV export, and the platform's compliance groundwork runs underneath every form: "UK GDPR, done properly — decline means off" and "Consent-gated embeds — nothing loads until a guest agrees", with data rights built in as erasure, export and deletion. Starter, at £19 a month excluding VAT, carries the enquiry and newsletter forms and the guest-record Inbox any birthday scheme starts from. Growth, at £39 a month excluding VAT, adds email campaigns that send to consented guest segments from one platform and guest email from the restaurant's own domain, so a birthday message goes out from a system already built around the consent it depends on. Full, at £69 a month excluding VAT, adds online ordering at 0% TableSpark commission for the same consent-gated guest relationship. A restaurant whose guest list also sits with a third-party supplier should read what happens when that supplier is hit by a ransomware breach; collecting lawfully is half of keeping it safe. Whether a specific form satisfies the Children's code, or a soft-opt-in claim would hold up to an ICO complaint, remains a question for the restaurant's own adviser, and no such promise is made here.