Skip to content
4 min read

PECR and e-privacy: what most organisations get wrong

PECR and e-privacy: what most organisations get wrong
PECR and e-privacy: what most organisations get wrong

Your business website almost certainly has a cookie banner. You may even have paid for a consent management platform to handle it. But here is the question many businesses never ask: is that banner actually doing what you think it is doing?

When the ICO reviewed the top 200 UK websites in 2024, 134 of them failed to meet basic cookie compliance standards. Not because they lacked cookie banners, but because the banners were not working properly. Cookies were firing before users had given consent. "Reject" buttons were not connected to the systems that control tracking scripts. Analytics tools were transmitting data regardless of what the user clicked.

This is not a niche technical problem. It is a regulatory exposure that, since February 2026, carries a maximum penalty of £17.5 million or 4% of your global turnover.

PECR comes first, not UK GDPR

Most organisations think about data protection in terms of GDPR. But when it comes to cookies and electronic marketing, the Privacy and Electronic Communications Regulations (PECR) are the starting point. PECR is a separate set of rules that governs what you can store on or read from someone's device, and it takes precedence over UK GDPR where its rules apply.

The practical consequence is straightforward: if PECR requires consent for a cookie, you cannot bypass that requirement by relying on "legitimate interests" under UK GDPR. This is the single most common legal misunderstanding I encounter. PECR is the primary gatekeeper. If it says consent, then consent it is.

This confusion is not helped by the consent management platforms themselves. Many CMPs present a separate "Legitimate Interests" toggle alongside the consent options, often switched on by default. The ICO's draft cookie guidance flags this as explicit bad practice. If a user denies consent and your system continues processing under a legitimate interests basis, you are acting unlawfully under PECR.

What the DUAA changed (and what it did not)

The Data (Use and Access) Act 2025 – which replaced the earlier DPDI Bill, with several provisions deliberately dropped – introduced three new exceptions where cookies can be set without consent:

These exceptions are narrower than they might first appear. The statistical purposes exception, for instance, requires that aggregate improvement data is the sole purpose of the cookie. If your analytics tool shares data with a third party for their own purposes, and Google Analytics in its default configuration sends data to Google, the exception almost certainly does not apply without reconfiguration. Even where an exception does apply, you must still tell users what cookies you are setting and offer a simple, free way to opt out. The ICO's final guidance on how these exceptions work in practice is expected in Spring 2026.

The DUAA also raised PECR's maximum penalty from £500,000 to £17.5 million or 4% of global turnover, aligning it with UK GDPR fine levels. What was once a manageable compliance risk is now enough to put a business under.

The gap between the banner and the code

This is where most organisations come unstuck, and it is where the difference between a policy review and a technical audit becomes obvious.

Installing a CMP does not mean you are compliant. A consent management platform is only as good as its integration with your tag management system. If your Google Tag Manager is configured to fire scripts on page load – the default behaviour – rather than waiting for a consent signal from the CMP, your banner is largely cosmetic. It asks for consent while your tracking scripts have already executed.

This is a real privacy risk exposure. In September 2024, the ICO reprimanded Sky Betting and Gaming after finding approximately 40 advertising cookies were placed on users' devices before the cookie banner had even loaded. The CMP was installed. The banner was visible. The scripts fired anyway. You can't hide this, anyone who knows how to use dev tools on a browser can check.

The "Reject All" problem is equally common. Clicking reject should stop tracking scripts from executing, not simply hide the banner. A technical check is straightforward: click "Reject All," refresh the page, and monitor the browser's network traffic. If you see requests going out to advertising or analytics domains after rejection, the reject button is a user interface element that is not connected to the tag management system. It looks compliant; it's not.

Then there is the "strictly necessary" mis-labelling. PECR exempts cookies that are strictly necessary to provide a service the user has requested: a shopping basket, a login session. The test is simple: does the site break without this cookie? If not, it is not strictly necessary. Organisations routinely categorise marketing or preference cookies as "necessary" to avoid the consent requirement. A quick audit of the cookie classifications in your CMP settings will often reveal cookies that have no business being in that category.

What to do about it

The pattern across all of these failures is the same: organisations treat cookie compliance as an administrative task (write the policy, install the banner) when the actual compliance question requires a technical check (are the scripts blocked until consent is given?).

If your organisation has a CMP installed, the most valuable thing you can do is have someone who understands how scripts, tag managers, and cookies work at a technical level audit the implementation. Not just the policy document; the actual behaviour of the website. Open the browser's developer tools, load the page in a clean session, and check what fires before anyone has clicked anything. Check what happens after someone clicks reject. Check whether the cookie classifications in your CMP match what those cookies actually do.

This is the kind of technical compliance audit I help clients with, not just reviewing the compliance documentation, but examining what the systems are actually doing and making sure that matches up with the documentation.