ICO relabels cookies. Auditing needs to catch up.

Will the ICO manage to rebrand "cookies"? Most UK organisations still think of the PECR as "cookie compliance." That framing has been wrong since the start, but remains sticky because of how colloquially we use the term.

In the updated PECR guidance, the ICO adopts "storage and access technologies" to shift the focus beyond cookies. In this article, I review the scope of SATs, discuss the reach of the analytics consent exception, and argue that compliance now requires a different kind of audit.

It is not about cookies anymore

The PECR, like the ePrivacy Directive, is technology-neutral. It covers any storage of, or access to, information on a user's device. As I explained in this article, cookies are just a small piece of how websites collect information.

But the industry and authorities have singled out cookies as the main event. The ICO's monitoring of the top 1,000 websites reinforced this: it checked for non-essential cookies, but did not consider the actual data flows behind them.

The new guidance drops "cookies" from the title entirely and explicitly lists six categories of technology in scope: cookies, tracking pixels, link decoration and navigational tracking, web storage, device fingerprinting, and scripts and tags.

This is, I think, a sharper framing than the EDPB's attempt to stretch Article 5(3) of the ePrivacy Directive across every form of storage or processing on a device. The categories individually make sense. Their structure trips me up, though.

Websites communicate with a user's device through requests. Storage offers memory to this conversation through cookies, both HTTP and JavaScript-set, local storage, session storage, and IndexedDB. Requests paired with storage allow servers to write information to a device ("storage") and read it back later ("access").

A tracking pixel is just one instance of a request. Take the tiniest image file, a one-by-one pixel, whose sole purpose is triggering a request back to a server. Redirects to ad tech vendors and iframes can work in similar ways.

Link decoration and device fingerprinting are two specific techniques for making requests more informative. Link decoration appends information about the click event to a URL, so the destination site knows where you came from and what you did. Device fingerprinting collects granular details about your browser and hardware through requests that, taken together, can single out a specific device.

Scripts are pieces of code fetched through requests. Once loaded, they can change the page, fire new requests, and set cookies. Tags, as the ICO rightly notes, are just a colloquial term for scripts built for tracking.

So think of SATs really as storage and requests. Nitpicking aside, the taxonomy matters less than what it implies: if your compliance programme is still scoped around cookies, you are missing most of what PECR actually covers.

The "statistical purposes" exception is very narrow

The five consent exemptions under the Data (Use and Access) Act have now made it into the guidance. Most site and app owners will look at the statistical purposes exception. It is an important carve-out from consent, but the requirements limit its scope considerably.

The statistical exception only applies to first-party, aggregated statistics used to improve your own service. If you use a third-party analytics provider, it must act as a processor and must not link the data with other sources.

Strict purpose limitation applies. You cannot, for example, rely on the analytics exemption for Google Analytics while the same tag feeds Google AdSense.

Even exempt analytics must offer users a simple way to opt out. That means running analytics through your tag manager or consent logic regardless. And server-side tracking is not an escape hatch: the guidance is explicit that the rules apply whether your tag management runs client-side or server-side.

Finally, the ICO reiterates that any storage or access for advertising requires consent. But there is movement. The UK government is exploring new exceptions for certain advertising purposes under the PECR. This matters because contextual advertising still needs basic infrastructure to work: frequency caps, performance reporting, attribution. Without consent-free measurement, privacy-friendly ads do not sell. An exception here could remove this bottleneck.

Consent exceptions and higher penalties mean deeper audits

The DUAA levelled PECR penalties with the UK GDPR. The maximum penalty for a SAT breach is now GBP 17.5 million or 4% of global turnover. The ICO reported in April 2026 that 99% of the top 1,000 UK websites meet its compliance standards for "cookie" banners. Note the air quotes.

That sounds reassuring. But look at what was actually tested. The ICO checked for the absence of non-essential cookies before consent or after rejection, and for the prominence of the reject option.

Auditing SATs means mapping every script, tracker, and SDK by vendor and tying each to a legal basis. It means distinguishing first-party analytics endpoints, such as newssite.co.uk/events, from those loading resources, such as newssite.co.uk/cdn. It involves accessing the tracker payload to review identifiers and consent signals, including Google Consent Mode and the TCF. Most CMPs were not built for this.

The ICO leaves open how often and how deep you should audit. The answer, in practice, is continuously. Release cycles are accelerating. Buy-side ad tech vendors change configuration constantly. Third-party scripts update their behaviour without telling you.

Privacy teams today struggle to tell exactly what their sites or apps actually do when a user clicks "reject all." Bridging that gap means moving audit capabilities out of periodic compliance reviews and into the engineering and ad tech teams that manage SATs every day.

These guidelines and the elevated penalties make the case for changing the way you release websites and apps.