UK cookie law: cookies set before consent

The rule

The wording does not mention cookies. It reaches any storage on, or access to, a device, so a tracking pixel or a script that reads a device identifier is inside it.

DUAA also added two new exceptions, which matter for what counts as non-essential. Paragraph 5 allows storage whose sole purpose is statistics about how the service or website is used, to improve it, but only if the information is not shared except to help with those improvements, the visitor is clearly told, and the visitor has a simple, free means of objecting and does not object. Paragraph 6 covers adapting how a website looks or works to the visitor’s preferences, on similar conditions.

PECR takes its meaning of consent from the UK GDPR (reg. 2(1), as the ICO’s guidance quotes it). The ICO’s guidance says that means a clear positive action: continuing to use a website “does not constitute valid consent, nor does the use of a pre-ticked box”. It also says organisations “must not pre-enable non-exempt storage and access technologies”, and that third parties have to be named, not hidden behind “partners”.

On analytics the ICO reads the new exception narrowly. Counting visits, scroll depth, device types and A/B test results are likely to fit. Logs of individual visitors, profiling and anything tied to online advertising do not. A third-party analytics provider can fit only as a processor acting on the site’s behalf, not as a joint controller.

Two limits are worth stating. The transitional rules in SI 2026/82 (reg. 11) keep the earlier regime for acts or omissions before 5 February 2026. And a ceiling is not a tariff: it says what the law allows, not what any authority will do.

On the record, the ICO’s cookie work has run mostly through letters, reprimands and compliance sweeps. On 4 December 2025 it reported that 979 of the 1,000 most-visited UK websites met its checks, 415 of them with no intervention and 564 after engagement, and that it had issued preliminary enforcement notices in 17 cases. Its tests included whether non-essential advertising cookies were stored before the visitor chose. We found no ICO monetary penalty for pre-consent cookies under the new ceiling as of 7 October 2026. The one reprimand set out below was decided under the UK GDPR, not PECR.

What PeekWell checks and how

UK-01 asks one question: did anything that is not exempt load before the visitor answered the banner? The scan answers it from what the browser did.

The method is the same as for EU-01: a fresh browser context with no saved choices, every request and cookie recorded as the page loads, no click on the banner. Request domains and cookie names are compared with a maintained list of tracker signatures, grouped by purpose. The UK ruleset then applies the exceptions before anything is flagged. First-party statistics that stay in the operator’s hands are not flagged. Advertising pixels and Google Analytics 4 are on the flagged side of the list.

The decision is made by code. A language model may help word the explanation in the report, but it never decides that a cookie was set.

The exceptions depend on facts a visit cannot see, such as whether a simple means of objecting exists and what an analytics provider does with the data. The scan works from the category on its list, so a finding for an analytics tool is a prompt to check those conditions.

The scan has limits, and the report says so. It sees the public pages it visited and nothing behind a sign-in. It does not submit forms, test passwords or open addresses nobody linked to. It records cookies and requests; other forms of storage the law also covers are outside it unless they show up as a tracker request. It does not read your contracts or decide what a tag is for beyond the category on its list. Collection on a server, or inside an app, is outside what a browser visit can see. A Passed means the expected behaviour was observed on the pages scanned. It does not say the site complies.

Why it matters for a company

The ICO can establish this fact from outside. In the Bonne Terre reprimand, the ICO found that a pixel from an advertising platform the company had contracted set about 40 third-party marketing cookies before visitors had set their preferences in the banner. The banner told visitors that accepting all cookies meant agreeing to storage for marketing; the ICO found the pixel’s cookies were already in place before that choice was made. The ICO alerted the company on 2 March 2023; by 3 March 2023, the next day, it had taken steps to fix the problem, and the ICO verified that by technical testing on 17 March.

The reprimand was issued under UK GDPR Articles 5(1)(a), 6(1)(a) and 7(1), because the cookies carried personal data and the company relied on consent. PECR regulation 6 sits beside those articles, and since February 2026 it carries the same top-tier ceiling.

For a company the consequences are practical. A regulator can answer whether a tag fired first with a clean browser, so a banner that is not wired to the tags proves little. And data sent to a vendor before the choice has already gone; changing the banner afterwards does not recall it.

Smaller companies and larger companies

PECR regulation 6 has no size threshold. The ICO’s guidance says the rules apply to any organisation running an online service, and the same facts decide it for a five-person startup and a listed group.

In a smaller company the site is often a template or a hosted builder. Someone in marketing adds an analytics tag, an advertising pixel and a chat widget, and a banner plugin is switched on. The banner is real, but one tag was pasted into the theme and loads on every visit before the banner is answered. There is usually no privacy team to notice. We could not confirm a published ICO decision against a smaller company; the guidance applies to everyone.

In a larger company there are more moving parts. A tag manager holds many tags owned by different teams and agencies, a campaign adds a pixel, and an advertising partner’s script loads further scripts of its own. The Bonne Terre reprimand shows the shape: the cookies came from a vendor’s pixel, not from the company’s own code, and the ICO still treated the company as responsible, because it had embedded the technology on its site.

How to fix it

The order of events matters more than the tool you use. The steps below fit most consent tools and tag managers.

1. See what loads first. Open your site in a private window with the browser’s network tab open. Do not touch the banner. Write down every third-party request and cookie, and note what each one is for.
2. Sort each one against the exceptions. A basket, login or security cookie is essential. A visit counter that stays with you and has an objection route may fit the statistics exception. Advertising, retargeting, session recording and social tracking need consent.
3. Block by default in your consent tool. Mark the consent-needing categories as off until the visitor accepts. Check that the categories in the tool match what each tag really does.
4. Start tags from the consent tool’s accept event. In a tag manager, fire each tag on that event rather than on page load. Scripts pasted into the theme, a plugin or a template need the same treatment, or need to go. The mechanics are the same as in EU-01.
5. Name the third parties in the banner. The ICO asks for real names, not “partners”.
6. Re-scan. Clear cookies and storage, reload, and run a scan again. The finding should disappear once nothing that needs consent loads before the choice.

Whether a given setup meets the exceptions is a question for your legal adviser. Peeky reports only what it sees.