Cookie Consent & Forms: A GDPR Guide for UK Schools 2026

What UK GDPR and PECR require from your school's website

UK higher education institutions operate under two overlapping legal frameworks for cookies and data collection on their websites. Understanding which law governs which activity is the prerequisite for getting your implementation right.

UK GDPR — the retained version of Regulation (EU) 2016/679, as incorporated by the European Union (Withdrawal) Act 2018 — governs the processing of personal data. Any time a cookie or tracking technology captures an identifier linked to an individual (a hashed email, a device fingerprint, a user ID), that is personal data processing subject to UK GDPR.

PECR — the Privacy and Electronic Communications Regulations 2003 — governs the act of storing or accessing information on a user's device. PECR applies regardless of whether the data is personal. Setting a session cookie is a PECR matter. Reading it is a PECR matter. Marketing emails are a PECR matter.

The ICO is the supervisory authority for both frameworks in the United Kingdom. In practice, a UK university's website must satisfy PECR before any cookie is placed, and then satisfy UK GDPR for any processing of personal data those cookies facilitate. Non-essential cookies require prior, freely given, specific, informed and unambiguous consent under both regimes. A pre-ticked box, implied acceptance by continuing to browse, or a banner that makes refusal harder than acceptance does not meet this standard.

For the broader legal framework governing your institution's data activities, see our complete GDPR guide for schools.

Which cookies need consent?

Not all cookies are equal under PECR. The ICO draws a clear line between cookies that are strictly necessary for a service the user has requested, and all other cookies. Only the former can be placed without consent.

The most common compliance failure at UK schools is placing Google Analytics without obtaining prior consent, on the mistaken assumption that anonymised data falls outside PECR. The ICO's position is unambiguous: any cookie set by Google Analytics — including the _ga cookie — is a non-essential cookie requiring consent before it fires. GA4's IP anonymisation does not change this.

A second frequent error is treating functional cookies as strictly necessary. A cookie that saves a user's preferred campus for future visits is convenient, not essential. Unless removing it would make the service technically impossible to deliver, it needs consent.

Forms for open days, enquiries and newsletters: compliance rules

Every form on your institution's website — open day registration, prospectus request, enquiry, newsletter signup, UCAS application initiation — is a data collection point governed by UK GDPR. Each one requires a lawful basis, transparent information, and data minimisation.

Open day registration forms

Open day registrations can rely on performance of pre-contractual measures (Article 6(1)(b)) for the data strictly necessary to process the booking: name, email address, programme of interest, attendance date. A UK GDPR-compliant open day form does not need a consent tick-box for these fields. What it does need is a clear privacy notice at the point of submission explaining what data is collected, who processes it, how long it is retained, and how to exercise data subject rights.

Any additional marketing use — sending nurture emails after the open day, adding the registrant to a prospectus mailing list — requires a separate, explicit consent that the user actively opts into. The lawful basis for the booking itself does not extend to subsequent marketing.

Enquiry and prospectus request forms

Enquiry forms (request for information, "ask us a question") typically rely on legitimate interests (Article 6(1)(f)) or consent, depending on your institution's data strategy. Whichever basis you choose, document it in your record of processing activities and reflect it accurately in the privacy notice presented to the prospect.

Data minimisation applies with force here. A prospectus request needs a first name, surname, email address, and programme of interest. It does not need a date of birth, postal address, or telephone number unless you can specifically justify each additional field. Every unnecessary field increases your compliance exposure and — as a practical matter — reduces form completion rates.

Newsletter and marketing consent

Newsletter signups require consent that is separate from any other transaction. A single tick-box on a prospectus request form that bundles consent for "programme information and updates" with "marketing communications from our partners" is not valid. One purpose, one consent. The consent must be documented with a timestamp, the exact wording shown to the user, and the mechanism used to record it.

Under PECR's soft opt-in rule, you may send electronic marketing to prospects who have already engaged with your institution (requested a prospectus, attended an open day) provided the marketing relates to similar services and every communication includes an easy unsubscribe mechanism. This is narrower than most marketing teams assume. For more detail on handling prospect data across the recruitment funnel, see our guide on protecting prospect data under GDPR.

How to implement a compliant cookie banner (ICO standard)

The ICO's published position on cookie banners is that compliant consent must be obtained before non-essential cookies are placed. This has direct design implications.

1. Block non-essential cookies until consent is given. The banner must appear before your analytics, marketing, or functional cookies fire — not simultaneously, and not after a brief delay. If your consent management platform (CMP) triggers GA4 on page load before the banner is acknowledged, you are not compliant.

2. Make accepting and rejecting equally prominent. The ICO has stated clearly that designs which present "Accept all" as a highlighted primary button while burying "Reject all" in small text, or requiring multiple clicks to refuse, are manipulative and non-compliant. A "Reject all" option must be as easy to access as "Accept all".

3. Provide granular controls. Users must be able to consent to some cookie categories while rejecting others. A single "Accept all or nothing" design does not meet the specificity requirement for valid consent.

4. Record consent. Every consent decision must be logged: the timestamp, the categories accepted or rejected, the version of the consent notice shown, and the mechanism used. This record is your evidence of compliance in the event of an ICO enquiry.

5. Enable withdrawal. Users must be able to change their preferences at any time. A persistent link to the cookie preference centre — in the footer, accessible on every page — is the standard mechanism. Withdrawing consent must be as easy as giving it.

6. Refresh consent annually. ICO guidance recommends re-seeking consent after a reasonable period (commonly 12 months) or whenever there is a material change to your cookie use.

Popular CMPs used by UK higher education institutions include OneTrust, Cookiebot (now Usercentrics), and CookieYes. Whichever platform you choose, verify it has a current IAB Europe Transparency and Consent Framework (TCF 2.2) certification if you use programmatic advertising, and that it integrates with your tag manager so cookie tags do not fire pre-consent.

Special case: AI chatbots and conversation data

72% of chatbot interactions on school websites are FAQ-type queries — each one a data processing event that your cookie policy must account for. (Source: Automated classification across 12,000 Skolbot conversations, 2025)

An AI chatbot on your institution's website is a distinct data processing surface that most cookie policies and consent frameworks inadequately cover. Consider what happens in a typical interaction: a prospective student visits your site, a chatbot widget loads, the user types a question about fees or entry requirements, and the platform logs the message content, the timestamp, a session identifier, and potentially the user's IP address. That is personal data processing under UK GDPR.

Several dimensions of chatbot compliance require specific attention:

Session cookies vs. persistent identifiers. A chatbot that uses only a session cookie to maintain conversation continuity within a single visit may qualify as strictly necessary (the user actively initiated the conversation). A chatbot that sets a persistent cookie to recognise returning visitors and retrieve previous conversation history is setting a non-essential cookie that requires consent.

Conversation data retention. Conversation logs are personal data. Your privacy notice must state how long they are retained, who has access, and the lawful basis for processing. A 30-day retention period is a common standard; indefinite retention is indefensible without documented justification.

Third-party data processing. If your chatbot provider processes conversation data on their infrastructure, they are a data processor under UK GDPR Article 28. A Data Processing Agreement (DPA) must be in place before any conversations are processed. This is a contractual requirement, not optional. Your GDPR audit checklist for schools should include a review of every chatbot vendor DPA.

Consent age. Under UK GDPR, the minimum age for valid consent is 13. If your institution's chatbot can be reached by applicants aged 13 to 15 (sixth-form students considering higher education), consider whether your consent mechanism is age-appropriate and whether parental consent mechanisms are in place for under-13 users who might interact with the widget.

Sensitive topics. Prospective students sometimes disclose sensitive personal data — health conditions seeking disability support, financial circumstances requesting bursary information — through chatbot interfaces. Ensure your chatbot's privacy notice is visible before the conversation begins and clearly explains how sensitive disclosures are handled.

FAQ

Does our school need a cookie banner if we only use Google Analytics?

Yes. The ICO's position is that Google Analytics cookies are non-essential and require prior consent under PECR regardless of whether IP anonymisation is enabled. The _ga, _gid, and _ga_[container-id] cookies set by GA4 must not fire until the user has actively accepted analytics cookies. A consent management platform that blocks GA4 tags until consent is recorded is the practical solution. Institutions running GA4 without a consent banner are exposed to ICO enforcement action, including formal notices and fines.

How do we collect lawful consent on open day registration forms?

The booking itself does not require a consent tick-box — use performance of pre-contractual measures (Article 6(1)(b)) as your lawful basis for processing the data needed to register and manage attendance. Display a concise privacy notice at the point of submission, linked to your full privacy policy, explaining the purpose, retention period, and data subject rights. If you intend to send marketing communications after the event, add a separate, unticked opt-in box for that purpose, with clear language describing what the prospect is signing up for. Do not bundle marketing consent with attendance confirmation.

Can a prospective student request deletion of their data after an open day?

Yes. The right to erasure (Article 17, UK GDPR) applies to prospect data. A prospective student who attended an open day can request deletion of their data at any time, provided no overriding legal obligation requires you to retain it. In practice, you may retain data under a legitimate interest for a reasonable period to handle any follow-up queries related to the event itself — but this window is measured in weeks, not years. Once the processing purpose has lapsed, the data must be deleted. Your CRM, email platform, chatbot logs, and analytics must all be included in the erasure response. Test your erasure procedure periodically to confirm you can execute it completely within the one-month statutory deadline.

How long can we retain enquiry form data?

The principle of storage limitation (Article 5(1)(e), UK GDPR) requires that personal data is kept for no longer than necessary for the stated purpose. A reasonable retention period for enquiry form data is 12 to 24 months from the date of last meaningful engagement (the prospect opened an email, visited your site, or interacted with a chatbot). After that period, you should either delete the data or seek fresh consent to retain it for continued marketing. Institutions in the Russell Group and TEF-rated providers typically align retention periods with the UCAS application cycle (one or two academic years). Document your retention periods in your record of processing activities and configure your CRM to enforce them automatically rather than relying on manual deletion.