Cookie Banners in 2026: What UK Websites Must Do Now ICO Penalties Reach £17.5 Million

If you have not touched your cookie banner since the day it was installed, there is a reasonable chance it no longer meets what the regulator expects. The Information Commissioner's Office has spent the last two years working through the UK's busiest websites tier by tier, and in February 2026 the maximum penalty behind those rules rose to the same order of magnitude as a serious data protection fine.

This guide covers what the law actually requires, how to test your own banner in about five minutes with nothing but a browser, and which fixes matter first.

Two sets of rules, and only one of them is about cookies

Almost every argument about cookie banners starts with the wrong regulation. There are two, and they do different jobs.

PECR — the Privacy and Electronic Communications Regulations — governs the act of storing information on someone's device, or reading information already stored there. That is the cookie rule, and it is technology-neutral: it catches cookies, but equally local storage, session storage, IndexedDB, tracking pixels, mobile SDKs and device fingerprinting. If a script writes something to a visitor's browser or reads an identifier out of it, PECR applies.

UK GDPR governs what you then do with any personal data collected. It decides your lawful basis, your retention periods, your transparency obligations and the rights your visitors can exercise.

Two practical consequences follow, and they trip people up constantly:

• You need consent to set a non-essential cookie even if no personal data results. "It is anonymous analytics" is not an answer to PECR, because PECR is about the storage, not the payload.
• Legitimate interests is not available for setting a non-essential cookie. Under UK GDPR you can sometimes rely on it for a processing activity; for storage and access outside the PECR exemptions the requirement is consent, with no balancing test to fall back on.

The exemptions are narrower than people assume

PECR exempts storage and access for the sole purpose of carrying out a transmission, and storage and access strictly necessary to provide a service the user has explicitly requested. That second limb is the one everyone reaches for, and it is read narrowly: necessary for the thing the user asked for, not for your business model.

Things that normally sit inside the exemption: the session identifier that keeps a logged-in user logged in, the contents of a basket, a load-balancing cookie that routes the request, a cookie recording a security or fraud-prevention decision, and — importantly — the cookie that stores the visitor's own consent choice so you do not have to keep asking.

Things that normally sit outside it: analytics of any brand, A/B testing, session recording and heatmaps, advertising and remarketing tags, conversion pixels, embedded social and video players that set their own identifiers, chat widgets that load before anyone asks for support, and anything described in your own documentation as "helping us improve the site".

One caveat worth acting on. The Data (Use and Access) Act 2025 adjusted parts of the storage-and-access regime, not only the penalties. If you have a borderline script classified as essential, re-read the ICO's current guidance on storage and access technologies before relying on that classification. The guidance, not a vendor's blog post, settles it.

What a lawful banner looks like

Strip away the design debate and the requirements come down to a short list.

• Nothing non-essential fires before a choice is made. This is the most common failure by a wide margin. The banner is correct; the tag manager underneath it is not.
• Reject is as easy as accept, on the first layer. If "Accept all" is a button on the banner itself, there must be a "Reject all" of equal visual weight beside it — same size, same contrast, same prominence. A grey text link next to a bold coloured button does not qualify.
• No pre-ticked boxes and no toggles switched on by default in the preference panel. Consent has to be an action the visitor takes.
• Granular by purpose. A visitor should be able to accept analytics and refuse advertising without being forced into an all-or-nothing choice.
• Silence is not consent. Scrolling, continuing to browse, closing the banner with an X, or a timer that assumes agreement are all invalid. So is "by using this site you agree".
• Withdrawal must be as easy as giving consent. In practice that means a persistent control — a footer link or a small floating button — that reopens the preference panel from any page.
• Transparency behind the banner. Purposes, categories, the identity of third parties and the lifetime of each cookie should be reachable in a click or two, and should match what the site actually sets.

The five-minute test you can run yourself

You do not need an auditor for this. You need a browser and a private window.

• Open a fresh private window, then open developer tools before you load the site. Clear site data in the Application or Storage panel, and open the Network panel alongside it.
• Load your home page and do nothing at all. List the cookies, then look at local storage, session storage and IndexedDB. Anything beyond your essential set is non-essential storage firing before consent.
• In the Network panel, sort by domain. Requests leaving for advertising, analytics or social domains before you have clicked anything are the same failure seen from the other side.
• Now click Reject all, reload, and repeat both checks. After a rejection the only things present should be your essential cookies plus the record of the rejection.
• Open the preference panel and confirm every optional toggle starts off.
• Find the control that lets a visitor change their mind later. If you cannot find it within ten seconds on an interior page, neither will they.
• Repeat at phone width. Banners that look balanced on a desktop frequently push the reject option below the fold on a 375-pixel screen.
• Screenshot the results and date them. If anyone asks later how you reached your conclusion, that folder is the answer.

The design choices the regulator treats as a problem

"Dark pattern" is a vague phrase, so here is the concrete version — what turns a technically present reject option into one nobody uses.

• Visual weighting. Accept rendered as a filled, high-contrast button; reject as low-contrast text, or in a grey that reads as disabled.
• Click asymmetry. Accepting takes one click; refusing takes a trip into a settings panel, a scroll, several toggles and a save.
• Loaded language. "Yes, I will support the site" set against "No, show me worse content". Framing that attaches a penalty to refusal is not a free choice.
• Nagging. A banner that reappears on every page view until the visitor gives in, while an acceptance is remembered for a year.
• Misused legitimate interest tabs. A second tab inside the preference panel where dozens of vendors sit switched on under a basis that does not apply to storage in the first place.
• Cookie walls and consent-or-pay. These are not automatically unlawful, but they are not automatically safe either. They need a genuine, properly reasoned justification, and they attract attention. Do not deploy one because a competitor has.

What actually changed on penalties

The previous maximum for this kind of breach was substantially lower — low enough that a large advertising-funded business could treat it as a cost of doing business. That calculation no longer holds, and that is the real story of February 2026: not a new rule, but a new consequence attached to an old one.

Be realistic about who gets looked at. The campaign above worked from the top of the traffic rankings downwards, and enforcement attention follows scale, conspicuous dark patterns, and organisations that ignore correspondence. For a small business the likely sequence is not a headline fine. It is a complaint from a visitor, a letter with a deadline attached, or — increasingly often — a procurement questionnaire from a larger customer asking you to confirm your consent arrangements in writing. The last of those costs you a contract rather than a penalty.

What honest consent does to your numbers

Fixing a banner that had been quietly setting analytics without consent will reduce your measured traffic. That is not a fault; you were previously counting people you were not entitled to count. Expect the drop to be material, and to differ by audience and by device.

Annotate the exact date of the change in your analytics so nobody reading the chart in six months interprets it as a traffic collapse. Rebaseline from that date and compare like with like afterwards. Move the reporting emphasis onto what consent does not distort — enquiries, phone calls, orders, and the ratio of leads to measured visits. If you use a consent-aware mode that models the missing portion, label modelled figures as modelled everywhere they appear, because sooner or later somebody will treat them as counted data.

What you must not do is solve the reporting problem by making refusal harder. That converts a measurement inconvenience into a compliance finding.

Your twelve-point audit

• Nothing non-essential is stored or read before a choice is made — confirmed in developer tools, not assumed from the consent tool's own dashboard.
• "Reject all" sits on the first layer with the same size, colour weight and positional prominence as "Accept all".
• Every optional toggle defaults to off.
• Consent is granular by purpose rather than a single switch.
• Rejecting leaves only essential cookies plus the consent record, verified after a reload.
• No implied-consent wording survives anywhere on the site, including old legal pages.
• A persistent, findable control reopens the preference panel from any page.
• The cookie list in your policy matches what the site actually sets, including anything added by a recently installed plugin or embed.
• Third parties are named, with their purposes stated in plain language.
• Consent is time-limited and re-requested at a sensible interval, with acceptance and refusal remembered on comparable terms.
• The banner has been tested at phone width with the reject option visible without scrolling.
• You hold a dated record of the test, and a named person owns re-running it whenever a tag, plugin or embed is added.

Work down that list in order. Items one, two, three and five are where the risk concentrates; the rest is housekeeping that becomes cheap once those are right. Where a point is ambiguous for your site, the ICO's guidance on storage and access technologies is short, free, and the only source that settles it.

Sources

• Information Commissioner's Office — guidance on the use of storage and access technologies
• Information Commissioner's Office — published statements on its review of the UK's most-visited websites
• Privacy and Electronic Communications (EC Directive) Regulations 2003, as amended
• Data (Use and Access) Act 2025, Schedule 13
• UK General Data Protection Regulation and Data Protection Act 2018