DUA Act 2025 cookie exemption: when UK SaaS builders can legally drop the banner

Every UK SaaS has a cookie banner. Most of them, in 2026, do not legally need one any more.

That is not a hot take. It is the direct consequence of the Data (Use and Access) Act 2025, which came into force on 5 February 2026. The Act rewired PECR regulation 6 — the exact piece of law that forced every UK website to show the "Accept / Reject / Customise" banner for the last two decades — and carved out a new exemption for first-party analytics and a cluster of other low-risk uses.

The SERP for this topic is a mess. Law firms have written explainers that are technically correct and practically useless. CMP vendors have written guides that just happen to conclude you still need a CMP. Nobody has written the one thing a UK indie hacker actually needs: a clear decision tree that tells you, for each cookie you set, whether you can drop the banner, and what your privacy policy needs to say instead.

So that is this post — exemption mechanics in plain English, a six-question decision tree, a tool-by-tool status table, a privacy policy checklist, an exemption-aware banner pattern if you do keep one, ICO enforcement reality in 2026, and a 20-minute audit. We covered the mechanics of building a compliant banner in the UK cookie banner 2026 playbook. This post is the prequel — when you need one at all.

What changed on 5 February 2026

UK cookie rules in 2026 sit on a three-law stack:

1. UK GDPR — the general data-protection framework. Governs what you do with personal data once you have it. Requires a lawful basis and a privacy notice. Unchanged by the DUA Act in any way that affects cookie banners.

2. PECR — the Privacy and Electronic Communications Regulations 2003. Regulation 6 is the cookie rule: before you store or access information on a user's device, you need consent, with narrow exceptions. PECR is where the "banner or no banner" question lives.

3. DUA Act 2025 — the Data (Use and Access) Act 2025, the UK's big post-Brexit data reform. Schedule 12 amends PECR regulation 6 to expand the exceptions. This is the change that made most UK SaaS banners redundant.

Before 5 February 2026, PECR regulation 6(4) had two exceptions: cookies "strictly necessary" for a service the user requested, and cookies for the sole purpose of carrying out an electronic communication. Everything else needed consent.

After 5 February 2026, regulation 6(4) has a longer list. Paraphrasing, the new exemptions cover:

• Sole-purpose statistical analysis of the service, where data is not used to track an identified user and not combined with other data.
• Service improvement — bug tracking, performance monitoring, feature-flag targeting that does not build a user profile.
• Remembering a user's identity across sessions when the user has asked to be remembered.
• Adjusting appearance or configuration to the user's preferences — dark mode, language, font size.
• Security purposes — fraud detection, rate limiting, abuse detection.

The strictly-necessary and electronic-communication exemptions stay.

The crucial detail most explainers bury: the exemptions only apply if the data stays first-party, is not used for advertising, and is not used to build individual user profiles. If you send analytics data to a third-party ad network, you are still consent-gated. The DUA Act did not legalise anything new for advertisers. It just stopped pretending that a first-party uptime monitor was the same as Facebook Pixel.

The four exemptions that actually matter for a UK SaaS

In practice, four exemption categories cover 95% of what a UK SaaS sets. Run through them in order. If a cookie fits the first matching category, it is exempt. If it matches none, keep it gated behind consent.

1. Strictly necessary

What it covers: session cookies, CSRF tokens, shopping-cart state, in-flight payment cookies, load-balancer routing, preferences strictly required for the app to function such as language or currency.

Was exempt before DUA, still exempt. The DUA Act did not need to change anything here. If your user logs in and you need a session cookie to keep them logged in, you have always been allowed to set that without asking.

Gotcha: "strictly necessary" means strictly necessary for a service the user explicitly requested. A logged-in user wants an auth session — strictly necessary. A logged-out visitor on your marketing page does not — so dropping a session cookie on first visit to "just in case" is not strictly necessary, and needs consent if it survives past the session.

2. First-party analytics for site improvement (NEW under DUA)

What it covers: Plausible, Umami, Vercel Analytics, self-hosted PostHog (with the right config), Fathom, Simple Analytics. Also covers server-side analytics based on access logs where the IP is immediately hashed or truncated.

The four conditions, all of which must hold:

• First-party. The cookie is set on your own domain (or a subdomain). Not a third-party domain belonging to the analytics vendor. This is why Plausible qualifies (cookieless, but even its first-party proxy version qualifies) and GA4 does not (its identifiers are fundamentally tied to Google).
• Anonymised or aggregated. The data you can pull out of the tool must not let you identify an individual user. IPs must be truncated or hashed. No persistent cross-session user IDs tied to a natural person.
• Not used for advertising. The data must not be repurposed, exported, or joined to any advertising, retargeting, or lookalike-audience pipeline.
• Service improvement purpose. The reason you are collecting is to understand and improve your own service, not to track the user across the internet.

If any of the four fail, you are back in consent territory. This is where GA4 and Meta Pixel sit.

3. First-party authentication

What it covers: session persistence beyond the browser tab, "remember me" cookies, long-lived auth tokens, refresh tokens.

Was mostly exempt before DUA, now explicitly exempt. The DUA Act clarified the legal status of remember-me cookies, which used to sit in an awkward grey zone. You can now set a 30-day auth cookie when a user ticks "keep me signed in" without a consent banner, provided you are not using that same cookie for analytics or advertising.

What you still have to do: include the cookie in your privacy notice. Tell the user how long it persists, what it contains, and how to clear it. The exemption is from the consent step, not from the transparency step.

4. Statistical / measurement aggregation

What it covers: server-side A/B test bucketing, feature-flag rollout counters, uptime monitoring, performance telemetry where the data is bucketed before it lands in your dashboard.

The hard requirement: the data has to be genuinely statistical. You are counting events per day, per bucket, per feature flag. You are not building a per-user journey. You are not joining this data to a user ID to ask "which users bounced on pricing on Tuesday". The moment a tool gives you the ability to drill from a statistic to an individual's behaviour, the exemption stops applying to the underlying collection.

This is the trickiest category because the tools blur the line. PostHog can be a statistical tool (if you only use funnels and trends and you strip user IDs) or a behavioural one (if you use session replay). Same SDK, totally different legal status. Configure deliberately.

The exemption decision tree

Six yes/no questions, run per cookie. If you get any NO before the end, keep the banner for that cookie.

1. Is the cookie set on your own domain or a subdomain of it?

   • YES — continue.
   • NO — it is third-party. Not exempt. Keep consent.

2. Does the cookie serve one of: strictly necessary, first-party analytics for site improvement, first-party auth, or genuine statistical aggregation?

   • YES — continue.
   • NO — not exempt. Keep consent.

3. Is any data derived from the cookie shared with, or joinable by, a third party (including the tool vendor for their own purposes)?

   • NO — continue.
   • YES — not exempt. Keep consent.

4. Is the data used for advertising, retargeting, lookalike audiences, or any paid-media attribution?

   • NO — continue.
   • YES — not exempt. Keep consent.

5. Could the data be used to identify or track an individual user across sessions in a way that is not strictly necessary for the feature you are providing them?

   • NO — continue.
   • YES — not exempt. Keep consent.

6. Have you documented the cookie in your privacy notice with its purpose, duration, and how the user can clear or refuse it at the browser level?

   • YES — exempt. No banner needed for this cookie.
   • NO — fix your privacy notice first, then exempt.

Run this once per cookie, not once per site. A typical UK SaaS will find that session, CSRF, auth, preferences, and first-party analytics all pass. Anything feeding an ad network will fail at question 3 or 4. Anything with session replay or individual user tracking will fail at question 5.

If every cookie passes, you can legally drop the banner. If any cookie fails, you need a banner — but a much lighter one than you are probably running today. We come back to what that looks like below.

Tool-by-tool status for a typical UK SaaS stack

Most UK SaaS teams we see running the DUA audit end up with roughly this tool list. Here is where each lands.

Plausible Analytics — exempt. First-party, cookieless by default, IPs hashed server-side, not used for advertising. The canonical case the DUA drafters had in mind. No banner needed, but list it in your privacy policy.

PostHog — conditionally exempt. Self-hosted on your own EU or UK infrastructure, no session replay, aggregated funnels only — passes. Cloud PostHog with session replay enabled, or product-analytics joined to auth-ID on a logged-out landing page — fails. Configure deliberately. If in doubt, keep the banner.

Umami — exempt. Same category as Plausible. First-party, no personal data, no advertising use.

Vercel Analytics — exempt. First-party, anonymised, no advertising use. Vercel's own documentation explicitly cites the DUA exemption path.

Google Analytics 4 — NOT exempt. GA4 uses third-party identifiers managed by Google, which processes data for its own purposes. Even with IP anonymisation, consent mode v2, and every toggle flipped, GA4 fails question 3. If you run GA4 you need a consent banner and you need to gate it behind opt-in. The cleanest move is to add Plausible or Vercel Analytics alongside GA4 for the pre-consent measurement.

Sentry — depends on config. Error reporting with PII scrubbing and no session replay — exempt as a first-party improvement tool. Sentry with session replay enabled fails question 5 and needs consent. If replaysSessionSampleRate is not zero, you are not exempt.

Stripe (checkout cookies) — strictly necessary. Cookies Stripe sets during a live checkout flow are exempt under the original PECR rule. No consent needed.

Hotjar and session replay tools — NOT exempt. These exist to record individual user sessions. Question 5's worst case. Consent-gated only.

Intercom / Crisp / chat widgets — depends. The "this visitor has seen the welcome" preference is arguably strictly necessary. The widget cookie that ties a visitor to a pre-auth identity across sessions fails question 5. Read the vendor docs.

Meta Pixel, LinkedIn Insight, TikTok Pixel, FullStory, MS Clarity — NOT exempt. Anything with "advertising", "remarketing", "pixel", or "session recording" in the vendor pitch is consent-gated. No exceptions.

If your stack is entirely in the exempt column — and for a Next.js SaaS on Supabase and Vercel with Plausible or Vercel Analytics, it usually is — you can legally drop the banner.

What your privacy policy still needs to say

Dropping the banner is not dropping the notice. PECR regulation 6(2) still requires clear and comprehensive information about every cookie you set, exempt or not. UK GDPR Article 13 still requires a standalone privacy notice. Both obligations survived the DUA Act untouched.

Your privacy policy — or a dedicated /cookies page linked from it — needs to cover:

The list of cookies. Name, purpose, duration, first-party or third-party, and which exemption category they fall into (or "consent-based" if none). A simple table is fine. The ICO expects a functional reference document, not a brochure.

The purpose of each. One sentence per cookie, plain English. "Keeps you signed in across sessions" beats "authentication session persistence token".

The retention period. Session-only, 30 days, 12 months. Anything beyond 12 months for a lightweight analytics cookie starts to look disproportionate.

Opt-out instructions. Even for exempt cookies, users have the right to refuse at the browser level. Link to browser cookie-clearing instructions or provide a "clear all and reload" button in user preferences. For consent-gated cookies, the opt-out must be as easy as the opt-in.

Controller and, if applicable, DPO contact. The legal entity running the site, a postal address (registered office is fine), and an email that gets read.

The ICO complaint route. A single line pointing users to ico.org.uk. Not optional.

A tight 800-word page with a cookie table is the correct shape. If your lawyer sends you 12,000 words of boilerplate, they are not writing it for your users.

If you keep the banner: the exemption-aware UX

Some UK SaaS will still run at least one consent-gated cookie — GA4 for historical continuity, a Meta Pixel for a paid-media campaign, Hotjar for a specific research sprint. That is fine. The banner does not go away. It gets lighter.

The legal minimum in the post-DUA world, when you only need consent for a narrow set of non-exempt cookies:

Pre-check analytics-only as the default bucket. If your only non-exempt cookie is first-party analytics that just misses the exemption (say, PostHog cloud), pre-selecting it as "on" is now permitted under the DUA because it is low-risk. Advertising must still be off by default.

Drop the advertising bucket entirely if you do not run ads. A banner that says "Accept analytics / Decline / Manage" is less intimidating and converts better than the default CMP templates.

Two buttons, equal weight. Accept and Decline as siblings. Not "Accept All" giant green and "Manage" tiny grey. The ICO has been very public about dark patterns.

Manage is a modal, not a second page. A modal with category toggles and a Save button is the correct shape.

No reject-walls. One banner, decide once, remember the choice, respect it. A seven-day re-ask cadence is acceptable. Every-page re-ask is a dark pattern.

A banner designed this way takes about 20 minutes to build with Claude Code and shadcn/ui and converts significantly better than the off-the-shelf CMP vendors.

ICO enforcement reality in 2026

The exemption is real. The enforcement is also real. Do not read this post as permission to be casual.

Three enforcement patterns the ICO has been running in 2025 and 2026, framed generically:

Pattern one — banner dropped, exemption not earned. A UK SaaS dropped its banner after reading a DUA Act explainer but kept GA4 running without consent. The ICO's automated sweep detected GA4 cookies on the landing page. Five-figure fine, remediation order, six-week timeline.

Pattern two — dark-pattern banner. A consumer fintech ran a banner where "Accept All" was a large green button and "Reject" was a text link in the footer of the modal. Low six-figure fine. The DUA Act did not help because the cookies were advertising cookies, fully outside any exemption.

Pattern three — privacy notice missing. A UK e-commerce site dropped its banner legitimately — the stack qualified — but failed to update the privacy notice to list the analytics tool. A subject access request revealed undisclosed processing. Warning, then fine on repeat.

The common thread: the ICO is not hunting honest mistakes in exemption interpretation. It is hunting dark patterns and undisclosed processing. Earn the exemption cleanly and document it properly, you are in the safe zone.

The 20-minute audit of your existing banner

Spend 20 minutes today. You will be shocked at what comes off.

Minute 0 to 5 — inventory. Fresh incognito window. DevTools / Application / Cookies. List every cookie set before consent and every cookie set after.

Minute 5 to 10 — classify. Run the decision tree on each cookie. Write "exempt" or "consent" next to each.

Minute 10 to 15 — decide. Three outcomes:

• All exempt: drop the banner. Update the privacy notice.
• Mostly exempt, one or two consent-gated: keep a light banner, trim to the two-button pattern above.
• Lots of consent-gated: the audit is a to-do list of tools to replace (GA4 → Plausible, Hotjar → nothing, Meta Pixel → only on campaign landing pages).

Minute 15 to 20 — update the privacy notice. Every cookie on the list. Purpose, duration, first-party/third-party, category. Browser opt-out and ICO complaint link. Ship.

Done. You have either dropped the banner legally or trimmed it to the minimum, and the privacy notice is your paper trail. Your conversion rate just went up because your landing page does not have a 400px legal apology at the bottom.

Key takeaways

• The DUA Act 2025 amended PECR regulation 6 on 5 Feb 2026 to exempt genuine first-party analytics from consent, but only when data is anonymised and not used for advertising.
• Four exemption categories matter for UK SaaS: strictly necessary cookies, first-party analytics, first-party authentication, and genuine statistical aggregation.
• Run the six-question decision tree on every cookie you set. If any answer fails, keep the banner for that cookie or swap the tool.
• GA4, Meta Pixel, LinkedIn Insight, and any tool that shares identifiers with a third party still need consent. Plausible, Umami, Vercel Analytics, and self-hosted PostHog can qualify for the exemption.
• Dropping the banner does not drop the privacy notice. PECR and UK GDPR still require a clear public list of what you set, why, for how long, and how to opt out.

---

This week's free report: UK Charity Soft Opt-In Compliance Toolkit

Score: 8.0/10 — read the full breakdown

Every Thursday we publish a new data-backed UK business opportunity. Subscribe free to get it in your inbox.