Cookie compliance: what a UK banner must do in 2026

Quick Answer: Cookie compliance on a UK website means blocking non-exempt cookies until the user gives positive consent, explaining purposes and third parties, and making refusal as easy as acceptance. Since 5 February 2026, five PECR exceptions can apply, including a tightly limited statistical-purpose route with a simple, free objection.

Summary in a mind map

Cookie compliance: what a UK banner must do in 2026
│
├─ Classify every technology
│   ├─ Identify storage, access, purpose and provider
│   ├─ Test all conditions of one Schedule A1 exception
│   └─ Block non-exempt tools before consent
│
├─ Design an equal choice
│   ├─ Make rejection as easy as acceptance
│   ├─ Give granular purposes and name third parties
│   └─ Require a positive action before loading
│
├─ Use statistics carefully
│   ├─ Sole purpose must be service improvement
│   ├─ Do not track individual visitors
│   └─ Give a simple and free objection
│
└─ Keep the evidence current
    ├─ Record banner version and consent choice
    ├─ Make withdrawal equally easy
    └─ Re-scan after site or supplier changes

Start with PECR as amended in February 2026

Cookie compliance on a UK website starts with the Privacy and Electronic Communications (EC Directive) Regulations 2003, usually called PECR. Regulation 6 was substituted by the Data (Use and Access) Act 2025 with effect from 5 February 2026. Subject to Schedule A1, a person must not store information in a subscriber's or user's terminal equipment. Nor may a person gain access to information already stored there.¹

The rule covers more than small browser cookies. It concerns storage and access technologies on terminal equipment, so the assessment follows what the technology does. A marketing pixel, local-storage identifier or software-development-kit identifier cannot avoid the rule because the supplier uses a different name.

The amended structure puts the permission routes in Schedule A1. Paragraph 1 permits storage or access where the person receives clear and comprehensive information about its purpose and gives consent.² Other paragraphs define exceptions with their own conditions. The practical sequence therefore starts by inventorying the technology and identifying its purpose. Next, test an exception and obtain consent before use if no exception fully applies.

Regulation 6 is triggered by storage or access in terminal equipment; it does not say that the information must identify a person.¹ A small firm should not omit a technology from this exercise merely because its stored value appears anonymous.

The same analysis should cover the first page load and later events. A tag may remain dormant until a visitor opens a video, starts checkout or uses a chat control. Its delayed trigger does not remove it from regulation 6. The site needs a defined route for that event before launch. This means a valid exception or a recorded consent choice obtained before storage or access begins.

Test each technology against the five exceptions

The Information Commissioner's Office (ICO) identifies five exceptions: communication, strictly necessary, statistical purposes, appearance and emergency assistance.³ An exception is not a broad category label. Every condition must match the actual use.

“Strictly necessary” is narrower than useful, convenient or commercially important. A basket cookie may be necessary to provide the shopping function a visitor requested. A behavioural-advertising identifier is not necessary to deliver the shop page. The ICO states that advertising purposes do not meet the strictly necessary exception. Consent is required for online advertising, cross-site or cross-device tracking and social-media tracking technologies.³

The same discipline applies to third-party services. A tool does not inherit an exception from the page hosting it. Each storage or access operation should be classified by its purpose and behaviour, including what the third party receives.

Evidence for the classification should be concrete. Useful material includes the observed trigger, the technology's duration and the configured purpose. It also includes the flow of information to the provider. That evidence allows a reviewer to compare the implementation with every condition in Schedule A1. It also exposes mixed-purpose tools whose essential function is bundled with advertising or tracking. Where the purposes cannot be separated, the consent decision follows the non-exempt operation.

Treat statistical analytics as a conditional route

Analytics no longer always means consent, but the new statistical-purposes exception is tightly framed. Schedule A1 paragraph 5 applies where the sole purpose is collecting information about how the service is used. That collection must have a view to improving the service. The information must not be shared with another person except to assist with those improvements. The user must receive clear and comprehensive information and a simple, free means of objecting.²

The ICO adds an important boundary: this exception does not permit monitoring or tracking individual visitors.³ A small retailer should therefore inspect configuration, identifiers, provider access, data sharing and downstream uses. A dashboard described as “analytics” may still involve individual profiles, advertising enrichment or reuse by a provider. The product label does not establish the exception.

Where every condition is met, the website can use the statistical route and present a simple objection rather than seeking prior consent. Where one condition fails, the ordinary consent route applies. The record should identify the technical settings supporting the conclusion. A policy sentence alone does not show that individual tracking is disabled.

This table is a conditions test, not a balancing exercise. Strong evidence on four rows cannot compensate for a failed fifth row. A provider contract may help establish restricted sharing. The site's configuration and actual data flow must tell the same story. If the provider can reuse the information for another purpose, the record should not state that sharing is confined to assistance with service improvements.

Build the banner around an equal choice

A compliant banner must make the decision real before non-exempt technology runs. The ICO expects a positive opt-in action and granular choices for different purposes. It also expects the identities of all third parties and information about how users can revisit their preferences.⁴ It also expects refusal to be as easy as acceptance.⁴

The first layer should therefore explain, in concise language, what the non-exempt technologies do. If it presents “Accept all”, it should present “Reject all” with comparable prominence. A settings route can support granular choices, but it should not become an obstacle course for refusal. Pre-selected non-essential purposes, colour tricks and a tiny close icon do not create a freely chosen positive action.

No non-exempt cookie or equivalent identifier may be set while the banner waits for input. The ICO's PECR guide specifically says that non-essential cookies must not be placed on the homepage before consent.⁵ Continuing to browse is not enough; consent needs a clear positive action.⁵

The banner also needs a stable path back to the choice. A persistent “Cookie settings” link in the page footer is one practical pattern. The underlying mechanism should stop future non-exempt storage or access when consent is withdrawn and should communicate the change to relevant tags.

Testing should begin with a clean browser state. Before any choice, the reviewer checks which storage and network activity occurs. Acceptance, refusal and purpose-by-purpose choices are then tested separately. The visible button is only one part of the mechanism. The tag manager, embedded services and later page events must all follow the recorded state. A refusal that looks successful but still permits an advertising request is not an equal or effective choice.

Follow the decision tree before anything is stored

Apply the same routing logic to every technology rather than making a single decision for the website.

In words, the tree branches like this:

• Is storage or access involved? If no, regulation 6 is not the relevant technology rule. If yes, continue.
• Does one Schedule A1 exception fully apply? If no, block the technology and ask for consent.
• Is it statistical or appearance use? If yes, provide clear information and a simple, free objection.
• Is it advertising or individual tracking? It is not strictly necessary or statistical; obtain consent first.³
• Has the user consented positively? Only then may the non-exempt technology run.^4,5

Consider a Leeds shoe retailer using four components. These are a Google Analytics 4 tag, a Meta Pixel, an embedded YouTube product video and an Intercom chat widget. The retailer tests the actual configuration of each component rather than classifying all four by supplier name.

Do not replace consent with browser settings or contracts

Browser controls can support privacy choices, but the ICO says a website must not rely solely on browser settings to indicate consent.⁴ The site still needs a mechanism that provides clear information and records a positive choice for its non-exempt technologies.

Terms and conditions are also the wrong mechanism. The ICO says not to obtain storage-and-access consent through terms and conditions.⁴ Bundling a tracking clause into a purchase contract does not create the specific, informed action required at the technology layer.

Withdrawal must be as easy as giving consent.⁴ A visitor should not need to email support or clear the entire browser history. When consent is withdrawn, stop the relevant future operations and retain only the limited evidence needed to respect and demonstrate the choice.

After a refusal, do not ask again on every visit. The ICO recommends six months as a suitable period before seeking fresh consent.⁴ A material change to purposes or parties may require an earlier fresh decision, but the change should be genuine and explained.

Record the evidence and review the implementation

The compliance record connects legal analysis to code. A technology inventory should contain the name, provider, purpose, duration, data recipients and trigger point. It should also contain the Schedule A1 exception or consent category relied upon. It should identify who approved the classification and the date of the last scan.

For consent, retain the banner version, information shown, purposes offered, timestamp and choice for an appropriate period. The ICO checklist asks organisations to keep cookie-consent records and build in a review period.⁵ The law and guidance do not supply one universal review interval for every site, so choose a frequency that responds to release cycles and supplier changes.

A further review is needed after specified changes. These include when marketing adds a tag, the shop platform changes a plug-in, a provider changes its terms or data flows, or the banner design changes. A regular scan should compare observed technologies with the approved inventory. Unexpected storage should be blocked and investigated, not silently added to the policy afterwards.

The retailer can turn that inventory into a release check for the four worked examples. The analytics row records whether measurement is the sole purpose, whether individual tracking is disabled and whether sharing is limited to service improvement. It also records where the free objection appears.^2,3 The advertising-pixel row records that prior consent is required and confirms that no request fires after “Reject all”.^3,4 The video and chat rows record separately what happens on page load and after the visitor presses play or opens chat. Each row names the provider shown to the user, the banner purpose, the tested trigger and the resulting exception or consent route.⁴

After a banner change, the reviewer repeats the clean-state test for acceptance, refusal, each granular choice and withdrawal. The evidence should connect the visible choice to the technologies that actually ran or remained blocked. A versioned screenshot can show what information and controls appeared. The scan and network record show whether implementation matched them. This creates a repeatable artefact at the end of the procedure. It consists of one approved inventory, one tested banner version and one dated review result. Any unexplained storage remains blocked until it is classified.

Where this procedure does not settle the answer

This procedure cannot classify a technology whose actual storage, access, sharing or identifier behaviour is unknown. Keep the operation blocked until the missing technical evidence is available; a supplier's description is not a substitute for the Schedule A1 conditions.

What to do next

Map every technology on the live site to the decision tree and record the tests completed before any choice. Configure the banner and withdrawal path to enforce each result.

Compare the mechanism with our guide to UK cookie banner requirements for small businesses. Make the implementation and the published explanation describe the same behaviour.

Frequently asked questions

Do all cookies on a UK website need consent?

No. Schedule A1 to PECR contains five exceptions: communication, strictly necessary, statistical purposes, appearance and emergency assistance. Each has precise conditions. Advertising, cross-site tracking, cross-device tracking and social-media tracking do not become exempt merely because the business finds them useful. Non-exempt storage or access needs consent before it occurs.

Must a cookie banner have a reject all button?

The ICO expects a consent mechanism to make refusal as easy as acceptance. For a banner offering an “accept all” action, a comparably prominent “reject all” action is the clearest way to meet that expectation. Do not hide refusal behind extra screens, pre-tick purposes or treat continued browsing as consent.

Can we use analytics without consent after 5 February 2026?

Sometimes. The statistical-purposes exception can apply when the sole purpose is measuring use to improve the service, the information is not shared except to assist those improvements, users receive clear information and can object simply and free of charge. It does not permit tracking or monitoring individual visitors.

Can browser settings or terms and conditions provide cookie consent?

No. The ICO says not to rely solely on browser settings as consent and not to seek consent through terms and conditions. Consent requires a clear positive action. The mechanism must explain the purposes and third parties before non-exempt technologies run, and the user must be able to revisit and withdraw the choice easily.

When should we ask again after a user rejects cookies?

The ICO recommends six months as a suitable period before asking again after a refusal. That is guidance, not permission to pester users or reset their choice on every visit. Ask sooner only where a material change makes fresh information or consent necessary, and keep the refusal effective in the meantime.

What cookie-compliance records should a small business keep?

Keep an inventory of technologies, purposes, providers, duration, data sharing and the exception or consent route used. Retain evidence of the banner version and the user's consent choice for an appropriate period. Record withdrawals, changes and review dates. The ICO checklist specifically expects a review period to be built into the process.