TREN
Blog / Legal
Legal

Cookie Consent Under UK GDPR and PECR

Most consent banners are wrong in the same three ways. Here is what the rules actually require and the option almost nobody considers.

29 September 2026 · Erdeniz Kurtuluş 6 dk okuma
Cookie Consent Under UK GDPR and PECR

Almost every site has a consent banner and a large share of them do not do what they are supposed to. Not through bad faith, but because the banner was installed as a plugin, configured once, and never checked against what the site actually does.

Here is the shape of the rules and where implementations usually go wrong. This is not legal advice, it is the working understanding we build to.

Two sets of rules, not one

People say GDPR and mean everything. There are two regimes and they cover different things.

Data protection law governs how you handle personal data once you have it. Lawful basis, transparency, retention, individual rights.

The privacy and electronic communications rules govern the act of storing something on someone's device or reading what is there. That is a separate question from whether the thing stored is personal data.

The second one is why cookie banners exist. It is triggered by the storage itself, so it applies even to an identifier that means nothing on its own.

It is not only about cookies

The single most common misunderstanding. The rule is about storing information on a device or gaining access to information already stored there.

Local storage counts. Session storage counts. Anything you write into the browser and read back counts. Swapping a cookie for local storage to avoid a banner does not work, it just makes the banner inaccurate.

Device fingerprinting, which reads characteristics of the device rather than writing to it, is also covered because it involves gaining access to information stored on the device.

What is exempt

Two narrow exemptions. Storage that is strictly necessary to deliver the service the user explicitly asked for, and storage whose sole purpose is transmitting a communication.

Strictly necessary means the service genuinely does not work without it. A shopping basket qualifies. A login session qualifies. A record of the consent choice itself qualifies.

Analytics does not qualify, however useful it is to you. The test is whether the user's requested service breaks without it, not whether your business benefits.

What consent has to look like

Freely given, specific, informed and unambiguous, through a clear affirmative action.

Unpacked, that rules out most of what you see in practice.

Pre-ticked boxes are not consent. Neither is continued scrolling. Neither is a banner that says "by using this site you agree" while the scripts are already running.

Consent must come before the storage happens. A banner that appears while the analytics call has already fired is decoration.

Reject has to be as easy as accept

This is where most banners fail visibly. A large Accept button and a Reject hidden behind a settings link is not a free choice, and regulators have said so plainly.

Both options should be available at the same level, with similar prominence. You can style them differently but you cannot bury one.

Withdrawal has to be as easy as giving it. In practice that means a persistent way back into the choice, not a one-time banner that never returns.

Granularity

Consent is specific. One button covering analytics, advertising and personalisation together is not specific consent for any of them.

The workable pattern is categories. Necessary, always on and explained. Analytics. Marketing. Each independently controllable.

Keep the category descriptions honest. "To improve your experience" describes nothing. Say what is stored, by whom, and for how long.

Third party scripts are your responsibility

Every external tool on your site may be storing something. Chat widgets, embedded video, maps, social buttons, advertising pixels, tag managers.

Embedded video is the one people miss. A standard embed can set advertising cookies before the visitor presses play. There are privacy-preserving embed modes for exactly this reason.

You are the one the visitor is dealing with, so you carry the responsibility for what your page loads. Keep a list of every third party script on the site and what it does. Without a list, nobody remembers what is there six months later.

Consent has to actually block things

A banner that records the choice and then loads everything regardless is worse than no banner. It creates a written record of a promise you are not keeping.

Test it. Open the site in a private window, reject everything, and look at what network requests fire and what ends up in storage. If analytics still runs, the banner is cosmetic.

This test takes five minutes and it fails on a surprising number of sites, including ones where somebody paid for a consent management platform.

The option almost nobody considers

You can avoid the whole regime by not storing anything on the device.

Server-side measurement can work without writing to the browser. Sessions can be resolved from request characteristics with a rotating salt, which produces useful analytics without an identifier that persists on the visitor's machine.

It gives you less than a full analytics suite. You lose reliable returning-visitor tracking and long attribution windows. In exchange there is no banner, nothing to block, and no gap between what your privacy notice says and what the site does.

We measure our own site this way. There is no consent banner because there is nothing to consent to. That was a deliberate trade and for a site like ours it was the right one.

Consent is not always the right basis

For the storage question, consent is what the rules require. For what you do with the data afterwards, consent is one lawful basis among several and often not the best one.

Processing an order does not need consent, it needs a contract. Keeping accounting records does not need consent, there is a legal obligation. Asking for consent where you have a stronger basis creates a promise you then have to honour, including the right to withdraw it.

Work out the basis for each activity separately. Bundling everything under one consent request is both weaker and more work.

Records and reviews

If you rely on consent, you need to be able to show it was given. That means storing what was consented to, when, and against which version of your notice.

Consent is not permanent. Revisit it when what you collect changes, and periodically regardless. A choice made against a notice that has since been rewritten is a weak record.

A short audit you can run today

  • Open the site in a private window and list everything written to storage before you click anything
  • Check that Reject is as prominent as Accept
  • Reject everything, reload, and confirm the blocked scripts are actually blocked
  • Find the route back to change the choice later, and check it exists
  • Compare the categories in the banner to the tools actually on the site
  • Read the privacy notice and check every claim in it is still true

Most sites fail two or three of these. The fixes are usually configuration rather than development, which makes this a cheap afternoon with real value.

gdpr pecr cookies consent privacy compliance

Erdeniz Kurtuluş

Co-founder at Erbeon

Let's Talk About Your Project

Got an idea?