Cookie Banners and UK Law: Getting It Right

What follows is general information, not legal advice. Cookie rules turn on the specific technologies a site uses and the purposes it uses them for, and the guidance in this area has been revised recently. For a decision that carries risk for your business, take advice from a solicitor or a data protection specialist and read the Information Commissioner’s Office guidance directly.

That caveat matters here, because a large number of UK sites are running banners that were correct in 2015 and have not been looked at since.

Two sets of rules, not one

Cookie consent in the UK sits at the intersection of two instruments, and people who only know about one of them usually get it wrong.

The Privacy and Electronic Communications Regulations 2003, generally shortened to PECR, are the rules that actually govern storing information on, or reading information from, a user’s device. This is the part that requires consent, and it applies whether or not the information involved is personal data.

The UK GDPR supplies the definition of consent that PECR relies on, and governs what you then do with any personal data collected. Its standard for consent is high: freely given, specific, informed and unambiguous, indicated by a clear affirmative action.

A useful consequence follows. Because PECR covers access to a device rather than personal data specifically, the rules are not limited to things called cookies. Pixels, tracking scripts, local storage, session storage and device fingerprinting techniques fall within the same regime. Removing cookies while keeping equivalent tracking by other means does not solve the problem.

The regime was amended by the Data (Use and Access) Act 2025, which introduced a small set of narrow, purpose-limited statutory exceptions and increased the maximum penalties available for certain PECR breaches. The ICO has issued updated guidance on storage and access technologies reflecting those changes, and it is worth reading the current version rather than a summary — this one included.

What valid consent looks like

Consent is required for anything that is not strictly necessary, and it must be obtained before the technology is set or accessed, not afterwards.

That timing requirement is where most non-compliant implementations fail. A banner appears while the analytics tag has already fired in the page head. The consent tool is loaded asynchronously and the tracking scripts load in parallel. Whatever the banner says, the storage already happened.

Beyond timing, the well-established points are these.

Silence is not consent. “By continuing to browse this site you accept our use of cookies” does not meet the standard. Neither does scrolling, nor closing the banner, nor simply navigating to another page. Consent requires a positive action.

Pre-ticked boxes are not consent. Any toggle for a non-essential purpose must start off.

Refusing must be as easy as agreeing. If there is an “Accept all” button on the first layer, there needs to be an equally accessible way to decline on that same layer, with comparable prominence. Burying rejection behind a “Manage preferences” screen and two further clicks is a pattern the ICO has repeatedly criticised, and it has run review programmes of the UK’s most-visited websites and written to operators whose banners did not offer a fair choice.

Consent must be specific and informed. People should be able to tell what they are agreeing to, in categories that mean something, with the third parties involved identified or at least readily discoverable.

Withdrawal must be possible. There should be a persistent, findable way to change a decision later — commonly a link in the footer that reopens the preference panel.

Strictly necessary is narrower than people hope

The exemption from consent applies to storage that is strictly necessary to provide the service the user has actively requested. That is a functional test, and “necessary” means necessary to the user’s requested service, not necessary to your business.

Clear examples of exempt use include remembering the contents of a shopping basket, keeping someone logged in during a session, load balancing, and storing a user’s own consent choices.

Analytics is the case that trips people up. Analytics improves your website. It is not what the visitor asked for. Historically the ICO signalled that low-risk first-party analytics was not an enforcement priority, and many sites relied on that. The current guidance no longer carries that language, and the position now turns on whether a specific statutory exception is met. Assuming you can set analytics without consent because “everyone does” is not a defensible plan in 2026.

Advertising and remarketing tags — including conversion tracking for paid campaigns — clearly require consent.

Design patterns to avoid

Regulators use the term “dark patterns” for interface choices that steer people towards a decision they would not otherwise make. Several are common on cookie banners.

• A large, coloured “Accept all” next to grey text-only “Reject”.
• A reject route that requires more clicks than the accept route.
• Language that implies the site will not work if you decline.
• Repeatedly re-prompting someone who has already declined, until they give in.
• Banners that obscure the content and cannot be dismissed without a choice, on a site where no choice is genuinely needed.
• Vague categories such as “improve your experience” that describe nothing.

Consent-or-pay models, where declining means paying for access, are a live and contested area. If you are considering one, that is firmly a question for a lawyer.

A practical way to get to a defensible position

1. Find out what your site actually sets. Load it in a private window with developer tools open and list every cookie, every storage item and every third-party request before you touch the banner. Most sites set things nobody remembers adding.
2. Classify each one by purpose and decide honestly whether it is strictly necessary.
3. Delete what you do not use. Tags from finished campaigns and abandoned tools are the easiest compliance win available, and they speed the site up as well.
4. Block by default. Configure the consent tool so non-essential scripts do not execute until a choice is recorded. If you use a tag manager, that means consent-aware triggers rather than tags firing on page load.
5. Fix the banner design. Accept and reject at equal prominence on the first layer, no pre-ticked toggles, a genuine link to a cookie policy that lists what is set and why.
6. Keep a record. You should be able to show when and how consent was obtained.
7. Re-check after any change. Adding a chat widget, an embedded video or a booking system frequently introduces new storage without anyone noticing.

The commercial reality

Implementing this properly will reduce the volume of data flowing into your analytics and advertising platforms, because a meaningful proportion of people decline when declining is easy. That is the intended outcome of the law, not a bug in your setup, and the honest response is to adjust how you interpret your reporting rather than to weaken the banner.

Consent mode and modelled conversions exist to soften that gap in some platforms. They do not remove the underlying obligation.

If you want your tagging and consent setup reviewed together, that spans web analytics, Google Ads and website development. For anything where the legal exposure is the real question, speak to a qualified adviser first.