For years, most website compliance work has been framed around one question: "Do we have a cookie banner?"
That question is now too narrow.
On 29 April 2026, the UK Information Commissioner's Office published its final guidance on Storage and Access Technologies, replacing the practical focus on "cookies" with a broader category of technologies that store information on, or access information from, a user's device. The ICO explicitly includes cookies, tracking pixels, link decoration, navigational tracking, web storage, fingerprinting techniques, scripts, and tags.
This matters because many websites can appear "cookie compliant" while still loading analytics scripts, advertising tags, pixels, fingerprinting logic, localStorage identifiers, or URL tracking parameters before valid consent is obtained.
The practical compliance question in 2026 is therefore not:
Do we block non-essential cookies?
It is:
Do we block non-exempt storage and access technologies before consent, and can we prove it?
1. What changed in April 2026?
The ICO finalized its guidance on Storage and Access Technologies, commonly shortened to SATs, after two consultation rounds: one following the December 2024 update to the previous cookie guidance, and another after changes to PECR introduced through the Data Use and Access Act process. The final version also added new sub-chapters on "simple means of objecting" and whether the same technology can be used for multiple purposes.
The most important conceptual change is that the ICO no longer treats "cookies" as the practical boundary of the problem. PECR applies to any technology that stores information on, or accesses information from, a user's terminal equipment. The ICO lists the following examples:
| Technology | Compliance relevance |
|---|---|
| Cookies | Classic browser storage, often used for sessions, analytics, advertising, personalization |
| Tracking pixels | Often used for ad attribution, email tracking, retargeting, and conversion measurement |
| Link decoration | Tracking parameters added to URLs to identify users, campaigns, sessions, or sources |
| Web storage | localStorage and sessionStorage identifiers can persist user or device data |
| Fingerprinting | Device/browser attributes can be combined to recognize users without cookies |
| Scripts and tags | Tag managers and third-party scripts can access device/browser information or trigger storage |
The ICO's guidance says the PECR rules apply across websites, mobile apps, connected devices, and other environments where storage or access occurs. Where personal data is involved, UK GDPR also applies.
2. Why "cookie compliance" is no longer enough
A website can pass a simple cookie check and still fail a real storage and access audit.
For example:
| Website behavior | Why it matters |
|---|---|
| No marketing cookies before consent, but Meta Pixel loads | The pixel may access device information or trigger tracking before consent |
| Cookie banner blocks cookies, but Google Tag Manager loads ad tags | Scripts and tags may initiate non-exempt tracking |
| No third-party cookies, but localStorage stores a visitor ID | Web storage is covered by the same storage/access logic |
| No visible cookies, but fingerprinting script collects browser attributes | Fingerprinting can identify or single out users without cookies |
| Consent banner works, but URL contains persistent click IDs | Link decoration and navigational tracking may still create tracking risk |
The key scientific point is that cookies are only one storage mechanism. Modern tracking systems often rely on hybrid identity graphs, where cookies, browser storage, device signals, redirects, URL parameters, server-side events, and tag-manager rules work together.
So a compliance audit must observe actual browser behavior, not just inspect the cookie table.
3. What PECR requires
The ICO explains that PECR Regulation 6 prohibits storing information, or gaining access to information stored, in the terminal equipment of a subscriber or user unless an exception applies. Where no exception applies, the organization must provide clear and comprehensive information and obtain prior consent to the UK GDPR standard.
The ICO states that consent must involve a clear positive action. Continuing to use a website does not constitute valid consent, and neither do pre-ticked boxes or equivalent mechanisms. The user must be informed before consenting, third parties must be clearly named, non-exempt technologies must not fire before consent, refusal must be as easy as acceptance, and users must have controls over non-exempt uses.
That gives us a practical test model:
| Requirement | Test question |
|---|---|
| Prior consent | Did any non-exempt technology run before the user clicked "Accept"? |
| Clear information | Does the banner or policy explain what the technology does and why? |
| Specificity | Are purposes separated clearly, such as analytics, ads, personalization, security? |
| Third-party naming | Are third parties clearly named before consent? |
| Refusal parity | Is "Reject" as easy as "Accept"? |
| Withdrawal | Can users later change their choice easily? |
| Technical enforcement | Does the actual browser behavior match the declared consent state? |
This last point is where many sites fail. A banner can be legally worded but technically ineffective.
4. Consent is purpose-based, not tool-based
One subtle but important issue is that the same technology can be used for multiple purposes.
For example, a script might support:
| Purpose | Possible compliance status |
|---|---|
| Session security | Potentially exempt if strictly necessary |
| Fraud prevention | Depends on exact legal basis and exemption scope |
| Analytics | Usually requires consent unless a specific exemption applies |
| Advertising measurement | Requires consent |
| Retargeting | Requires consent |
| Personalization | Depends on whether requested by the user and whether exempt |
The ICO's final guidance added a specific discussion on whether the same storage and access technology can be used for multiple purposes. That is important because organizations sometimes classify a whole script as "necessary" because one function is necessary, even though the same script also performs analytics or advertising functions.
A reliable audit should therefore classify technologies by purpose, not merely by vendor or file name.
Bad classification:
analytics.jsis necessary because it helps the website work.
Better classification:
This script performs page analytics and user journey measurement. It is not required to deliver the page requested by the user, so it must not run before consent unless a valid exception applies.
5. Advertising still needs consent
The ICO is very clear on advertising-related storage and access technologies. If a service uses storage or access technologies for online advertising, consent is required. The ICO says online advertising purposes are not exempt from PECR consent requirements, including frequency capping, ad affiliation, ad measurement, performance measurement, click fraud detection, market research, product improvement, or debugging where used for advertising-related purposes.
That is significant because many sites still treat some adtech activities as "functional", "performance", or "legitimate interest".
From an audit perspective, the key question is not what the CMP category says. The key question is what the technology actually does.
Examples of high-risk findings:
| Finding | Why it is risky |
|---|---|
| Ad scripts load before consent | Non-exempt advertising technology runs too early |
| Click IDs stored in localStorage | Persistent ad attribution may occur before consent |
| Ad measurement pixel fires on page load | Advertising measurement is explicitly not exempt |
| Third-party ad vendor not named | Consent may not be informed or specific |
| Reject button does not block all ad calls | Consent state and technical behavior do not match |
6. Analytics needs careful treatment
Analytics is often misunderstood.
Website operators argue that analytics are useful for improving a service. That may be true, but usefulness is not the same as strict necessity. The ICO's broader SATs approach means analytics-related storage or access must be assessed carefully against the available exceptions and consent requirements. The ICO guidance explains that non-exempt use requires prior consent, and advertising-related measurement is not exempt.
A scientific audit should distinguish between:
| Type | Example |
|---|---|
| Aggregate server-side logs | Basic request logs without device access or persistent identifiers |
| Consent-based analytics | Analytics tags only loaded after opt-in |
| Local analytics storage | Client-side identifiers stored in cookies or localStorage |
| Advertising measurement | Conversion tags, pixels, retargeting, campaign attribution |
| Product telemetry | Event tracking, heatmaps, session replay, feature usage |
The riskiest cases are usually session replay, heatmaps, cross-site analytics, and advertising measurement, because they often involve detailed behavioral tracking and third-party processing.
7. The compliance evidence problem
Most compliance failures are not only legal failures. They are evidence failures.
A company may believe:
Our CMP blocks all marketing tools before consent.
But the browser may show:
A third-party script loads before consent, creates localStorage entries, fires a network request, and sends device metadata to an analytics endpoint.
This is why storage and access compliance should be tested using controlled browser states:
| State | What to test |
|---|---|
| Fresh visitor, no choice | What fires before any consent decision? |
| Reject all | What remains after refusal? |
| Accept all | What fires after full consent? |
| Granular consent | Do analytics, ads, and personalization behave separately? |
| Withdrawal | Are previously accepted tools stopped after consent is changed? |
| Return visit | Is the stored consent state respected? |
The audit should collect evidence from multiple layers:
| Evidence layer | What it proves |
|---|---|
| Cookies | Name, domain, expiry, category, creation timing |
| localStorage / sessionStorage | Persistent or session identifiers outside cookies |
| Network requests | Third-party calls, pixels, APIs, tracking endpoints |
| Scripts and tags | Which code executes before and after consent |
| Consent state | CMP choice, consent string, category settings |
| Screenshots | What the user was shown at the moment tracking occurred |
| Timing | Whether storage/access happened before or after consent |
This matters because regulators and internal legal teams need reproducible proof, not assumptions.
8. Dark patterns still matter
Technical blocking is not enough if the consent interface manipulates the user.
The EDPB's deceptive design pattern guidance focuses on user interfaces that push people into unintended, unwilling, or harmful decisions about personal data. Although the EDPB document is framed around social media platforms, its principles are relevant to consent interfaces generally: lawfulness, fairness, transparency, data protection by design, and avoiding manipulative design choices.
For cookie and SAT banners, common risk patterns include:
| Pattern | Example |
|---|---|
| False hierarchy | "Accept all" is bright and primary, "Reject" is hidden or grey |
| Obstruction | Reject requires several clicks, accept requires one |
| Ambiguous wording | "Continue" or "OK" is used instead of clear consent choices |
| Preselection | Optional categories are enabled by default |
| Forced consent | Access is blocked unless the user accepts non-essential tracking |
| Misleading categories | Advertising tools placed under "functional" or "necessary" |
The ICO also states that users must be able to refuse non-exempt storage and access as easily as they can accept it.
9. What a modern SAT audit should include
A strong audit should not be a static cookie list. It should be a reproducible browser experiment.
Minimum audit methodology
| Step | Action |
|---|---|
| 1 | Open the page in a clean browser profile |
| 2 | Capture all cookies, localStorage, sessionStorage, IndexedDB where relevant |
| 3 | Capture network requests before consent |
| 4 | Detect third-party scripts, pixels, tags, and redirects |
| 5 | Save screenshot of the initial banner |
| 6 | Click "Reject all" and repeat storage/network capture |
| 7 | Click "Accept all" and repeat capture |
| 8 | Compare differences across states |
| 9 | Map each technology to purpose and vendor |
| 10 | Flag technologies that fire before consent without a valid exception |
Stronger audit methodology
For higher-risk sites, add:
| Advanced check | Why it matters |
|---|---|
| Multiple page types | Home, article, product, checkout, login, search, video page |
| Mobile and desktop | Mobile layouts often use different banners and scripts |
| Geo testing | EU/UK/US visitors may see different consent behavior |
| Repeat visits | Stored consent states can produce hidden failures |
| Tag manager inspection | GTM and similar systems can trigger hidden vendors |
| URL parameter testing | Link decoration may appear only on campaign URLs |
| Video player testing | Embedded video often loads third-party trackers |
| Ad slot testing | Advertising scripts may fire only on monetized templates |
This is especially important for media websites, e-commerce, SaaS landing pages, and lead-generation sites.
10. Practical checklist for website owners
Use this as a fast internal review.
Pre-consent
| Question | Pass condition |
|---|---|
| Do non-essential cookies appear before consent? | No |
| Do pixels fire before consent? | No |
| Do analytics calls fire before consent? | No, unless validly exempt |
| Does localStorage contain user/session/tracking IDs before consent? | No, unless validly exempt |
| Do ad scripts load before consent? | No |
| Are third-party vendors named before consent? | Yes |
| Is "Reject" as easy as "Accept"? | Yes |
| Are optional categories off by default? | Yes |
Reject state
| Question | Pass condition |
|---|---|
| Are advertising requests blocked? | Yes |
| Are analytics tags blocked unless validly exempt? | Yes |
| Are localStorage tracking IDs removed or not created? | Yes |
| Are pixels blocked? | Yes |
| Is the rejection stored correctly? | Yes |
| Does the site remain usable? | Yes, except for optional features that truly require consent |
Accept state
| Question | Pass condition |
|---|---|
| Are technologies loaded only after consent? | Yes |
| Are purposes consistent with the banner description? | Yes |
| Are vendors consistent with the vendor list? | Yes |
| Can the user withdraw later? | Yes |
| Does withdrawal stop future non-essential tracking? | Yes |
11. Common failure examples
Failure 1: "Reject all" does not reject all
The banner offers a reject button, but network logs show advertising or analytics requests after rejection.
Why it matters: Consent is not only a UI state. It must control actual execution.
Failure 2: localStorage is ignored
The site blocks cookies but stores a persistent visitor ID in localStorage.
Why it matters: PECR is technology-neutral. Web storage is explicitly covered by the ICO's SATs guidance.
Failure 3: Tag manager loads too early
The site blocks known vendor cookies, but the tag manager itself loads before consent and triggers third-party requests.
Why it matters: Scripts and tags are included in the ICO's SAT scope.
Failure 4: Advertising measurement is classified as analytics
Conversion pixels or campaign attribution tools are placed in a "performance" or "analytics" category and run before consent.
Why it matters: The ICO states that advertising-related purposes, including ad measurement and performance, are not exempt.
Failure 5: The vendor list does not match reality
The privacy policy names five vendors, but the browser contacts fifteen third-party domains.
Why it matters: Consent must be informed and specific. The ICO says third parties must be clearly and specifically named where their storage and access technologies are used.
12. What this means for compliance teams
The April 2026 ICO guidance pushes compliance teams toward a more evidence-based model.
A modern compliance program should maintain:
| Artifact | Purpose |
|---|---|
| Storage/access inventory | List of cookies, storage entries, pixels, scripts, tags, vendors |
| Purpose classification | Necessary, analytics, advertising, personalization, security, etc. |
| Consent-state evidence | Before consent, reject, accept, withdrawal |
| Vendor map | Domains, processors, third parties, data destinations |
| Technical controls | CMP rules, tag-manager rules, script blocking |
| Audit logs | Timestamped proof of what happened in the browser |
| Regression checks | Monitoring when a new vendor or script appears |
The practical goal is not just to configure a CMP once. The goal is to detect drift.
Marketing teams add new pixels. Product teams add analytics. Developers add A/B testing tools. Ad ops changes tags. Video players introduce new vendors. Without recurring scans, compliance decays.
Conclusion
The ICO's April 2026 guidance confirms what browser evidence has shown for years: cookie compliance cannot be reduced to a cookie banner.
The real compliance boundary is broader:
Any technology that stores information on, or accesses information from, the user's device must be assessed, classified, controlled, and evidenced.
That includes cookies, pixels, localStorage, sessionStorage, scripts, tags, fingerprinting techniques, link decoration, and tracking requests.
For website owners, the practical lesson is simple:
Do not audit only the banner. Audit the browser.
A compliant website should be able to prove what happens:
- before consent,
- after rejection,
- after acceptance,
- after withdrawal,
- across page types,
- across devices,
- across real third-party vendors.
In 2026, "we have a cookie banner" is no longer a convincing compliance answer.
The better answer is:
We have evidence that non-exempt storage and access technologies do not run before valid consent.
Sources
- ICO, Final storage and access technologies guidance published, 29 April 2026.
- ICO, Guidance on the use of storage and access technologies, finalised 29 April 2026.
- ICO, What are storage and access technologies?
- ICO, What are the PECR rules?
- ICO, What are the exceptions?
- UK legislation, PECR Regulation 6.
- EDPB, Guidelines 03/2022 on deceptive design patterns in social media platform interfaces.