GA4 After the UK Data Bill 2025: Can You Prove You're Really GDPR Compliant?

If you had to show proof today, could you demonstrate that Google Analytics 4 (GA4) on your website has:

• real consent before collection,

• minimal data,

• short retention, and

• a governed EU→US / UK→US transfer mechanism – with evidence?

That’s the bar now.

There’s been a lot of noise about “Google Analytics is illegal under GDPR.” What regulators have actually done is:

• hit specific Universal Analytics (UA) setups that sent EU data to the US without sufficient safeguards after Schrems II, not ban analytics outright;

• question weak transfer tools and loose implementations, not declare GA4 itself unlawful.

GA4 is different to UA: it uses event-based tracking, doesn’t log IP addresses by default, and offers more granular regional controls. There is no EU-wide ruling that GA4 is illegal as a product – but regulators do expect you to configure and govern it properly.

Meanwhile, the UK has moved on:

• The Data (Use and Access) Act 2025 (DUAA) amends UK GDPR, the Data Protection Act 2018 and PECR, including new, narrow cookie exceptions and much tougher PECR fines (up to £17.5m or 4% global turnover, now aligned with UK GDPR).

• DUAA allows some cookies and similar tech to be set without consent in specific, low-risk scenarios, including:

  • “statistical purposes” – certain aggregated analytics purely to improve the service;

  • “appearance” – adapting how a service looks/functions to user preferences;

  • plus strictly necessary and emergency assistance cases.

The ICO has welcomed the reforms but is crystal clear: these exceptions are narrow, and otherwise you still need consent – and you now face GDPR-level penalties for getting it wrong.

So, as of late 2025:

• In the EU/EEA (and usually CH), GA4 is still consent-only in most cases under ePrivacy + GDPR.

• In the UK, tightly scoped, low-risk analytics may fit a DUAA cookie exception – but you need Legal/DP to bless that in writing and your implementation has to actually match the conditions.

For a UK-based organisation with EU visitors, that means your job is not to argue about “GA4 legal vs illegal”, but to make your GA4 setup something you can defend under both regimes.

This guide is written for Legal, DPO/DP, and Digital/Product together. It shows what “good” looks like, and what evidence you should have on file.

0. UK vs EU in one page

Before we get into checklists, it helps to be clear on the playing field.

UK (DUAA + UK GDPR + PECR)

• DUAA 2025 tweaks the cookie rules under PECR so that some storage/access can happen without consent where the privacy risk is low – notably:

  • “statistical purposes” analytics to understand service use and improve it;

  • “appearance” settings to adapt how a service appears/functions;

  • plus pre-existing “strictly necessary” and emergency exceptions.

• PECR fines now match UK GDPR: up to £17.5m or 4% global turnover.

• ICO draft guidance emphasises a risk-based approach, but removes earlier hints that low-risk analytics would be de-prioritised for enforcement: either you meet the strict criteria for an exception, or you get consent.

EU/EEA (and CH in most practice)

• ePrivacy rules still expect opt-in consent for analytics and marketing cookies unless strictly necessary.

• Several DPAs have ruled on UA setups as non-compliant mainly because of EU→US transfers after Schrems II, not because “analytics is banned”.

• GA4 can be made compliant if configured with minimisation, consent, and proper transfer tools (EU–US Data Privacy Framework for certified entities, or SCCs + Transfer Risk Assessment where needed).

Practically:

• Treat EU users as consent-only for GA4.

• For UK users, only lean on the new DUAA exceptions if Legal/DP deliberately sign off that your GA4 configuration fits the “statistical purposes” conditions. Otherwise, still behave as if consent is required.

The rest of this guide assumes a safe, consent-first baseline that works in both UK and EU, with optional “UK-only exception” notes where relevant.

1) Consent and PECR/ePrivacy

(Make it easy, make it real)

What to do together

• CMP actually gates GA4

  • Make sure your consent mechanism truly blocks GA4 until opt-in – on desktop and mobile, first pageview, deep-links, post-login pages, iframes and AMP where relevant.

  • In the UK, if you choose to rely on a DUAA exception for some narrowly defined analytics, document that separately – do not quietly bypass consent “because the law seems looser now.”

• Real choice, no dark patterns

  • Keep “Decline” as easy and visible as “Accept”: same font size, similar contrast, no hiding “Reject all” behind “More options”.

  • Avoid colour tricks that make “Accept” look like the only real choice. ICO has flagged design nudges as a concern and now has PECR-level fines to back that up.

• Immediate withdrawal

  • Provide a “cookie settings” / “privacy settings” link in the footer and in-app menus.

  • When a user withdraws consent, stop GA4 promptly – across subdomains, iframes, and AMP, not just the page they clicked on.

Reality checks (lightweight)

Run a 10-minute monthly “consent reality test”:

• On mobile and desktop, record a decline journey:

  • home → a key content page → back/forward → open a modal → open a new tab → log in (if applicable).

• Check network calls and storage:

  • no GA4 requests, no GA cookies/identifiers before consent;

  • withdrawal stops GA4 on subsequent hits.

Keep the recordings. If you can’t prove it, regulators will assume it doesn’t work.

Good evidence to file

• Copy of the current CMP text and screenshots (versioned).

• Consent logs / summary reports (even if they’re sampled).

• The latest pass/fail sheet from the monthly reality test.

• If you rely on a DUAA cookie exception for any UK-only analytics: a short written note from Legal/DP explaining which exception (“statistical purposes”, etc.), what GA4 configuration it covers, and when it will be reviewed against updated ICO guidance.

2) Minimise collection and avoid PII

(Collect only what you actually use)

This part is the same game under UK GDPR (as amended by DUAA) and EU GDPR: you minimise data and keep identifiers and personal data out of GA4.

What to agree

• A do-not-collect list

  • No names, emails, phone numbers, exact postcodes, or internal customer IDs as GA4 event parameters, page paths, query strings, or form field values.

  • No “free text” fields piped straight into GA4.

• Scoped features

  • Ads / remarketing features and Signals only on when there is a clear business case and consent to match.

  • Avoid over-detailed location/device data if you don’t genuinely need it.

• Short retention by default

  • Use the shortest workable GA4 retention (e.g. 2–14 months for most marketing and product analytics).

  • Any extension needs a written, time-boxed rationale with a named owner and review date.

PII hygiene routine

• Maintain a parameter allow-list – a simple table of which event parameters and user properties are allowed into GA4. Anything not on the list is blocked or stripped before it hits GA4.

• Run a quarterly leak test:

  • Crawl key pages and flows.

  • Submit safe test inputs (fake emails, postcodes, phone-like numbers).

  • Inspect URLs, page titles, and network requests for PII patterns.

  • Fix anything that leaks and re-test.

  • 
    

Good evidence to file

• The current parameter allow-list.

• The last leak test report and the fixes made.

• Screenshots of GA4 data retention settings and Signals/ads/personalisation toggles.

• Any retention extension memo with end date and owner.

3) Lawful basis and documentation

(Align paper to reality)

For both UK and EU, you need the paperwork to match what’s actually configured.

What to align

• RoPA entry

  • Make sure your Record of Processing Activities describes GA4 with:

    • purposes,

    • categories of data and data subjects,

    • recipients (Google and any other tools),

    • retention,

    • transfers and security measures.

  • Do this under UK GDPR as amended by DUAA and, where you process EU data, under EU GDPR as well.

• Notices that reflect reality

  • Privacy and cookie notices should be in plain English and cover:

    • that you use GA4,

    • for what purposes (measurement, UX, performance, etc.),

    • that consent is required (except where a clearly defined UK exception is used),

    • how to withdraw or change settings,

    • how long analytics data is retained.

• Assessments

  • A DPIA where scale/combination of tracking makes the risk “likely high”.

  • Transfer Risk Assessment (TRA) where you rely on SCCs/IDTA rather than DPF/Data Bridge.

  • If you rely on a DUAA cookie exception: a short addendum explaining why your GA4 config fits the strict “statistical purposes” criteria (aggregation, no individual profiling, no cross-site tracking, etc.).

Practical extras

• A short “measurement purpose” paragraph agreed with Product/Marketing (e.g. “identify confusing content, diagnose performance issues, evaluate feature adoption”), so everyone knows what GA4 is actually for.

• A one-page “Measurement Charter” covering: purpose, choice, minimisation, retention, transfers, and evidence. Share it internally and get it signed by the DPO/Head of Digital.

Good evidence to file

• The current RoPA excerpt for GA4.

• PDF copies of the live privacy and cookie notices.

• DPIA/TRA (or a clear statement of why they’re not required).

• The one-page Charter with sign-off.

4) International transfers

(Simple story, clear owner)

GA4 involves exporting data to Google infrastructure, which typically means transfers out of the EU/UK.

What to decide together

• Your mechanism for EU data

  • If you have EU users, decide whether you rely on:

    • the EU–US Data Privacy Framework (DPF) for Google (if certified), or

    • SCCs + TRA, with any supplementary measures (e.g. encryption, access controls, data minimisation).

• Your mechanism for UK data

  • For UK users, you can typically rely on:

    • the UK–US Data Bridge (the UK extension of DPF), or

    • IDTA/SCCs + TRA if DPF/Data Bridge isn’t being used.

• A single board-ready slide

  • One slide, updated quarterly, that answers:

    • what leaves the UK/EU,

    • where it goes,

    • which mechanism you rely on (DPF/Data Bridge vs SCCs/IDTA + TRA),

    • how often you review that stance,

    • who owns making changes if the legal position shifts.

Operational tip

Write down trigger conditions – for example:

• change to DPF/Data Bridge adequacy status,

• a major DPA ruling on GA4 transfers,

• Google changing where/how GA4 data is processed.

Name the person who decides what happens if a trigger is hit.

Good evidence to file

• The current board slide or note (date-stamped).

• The last review note confirming “still accurate” or recording changes.

• Evidence of vendor certification (DPF/Data Bridge listings) or TRA conclusions for SCCs/IDTA.

5) Evidence & accountability

(Lightweight, regular, shared)

DUAA doesn’t rip up the rulebook; it raises the stakes and expects more structured governance, especially for cookie-driven tools like GA4.

Keep a simple evidence pack

At a minimum:

• GA4 admin screenshots:

  • retention, Signals, ads/personalisation, data sharing settings.

• CMP configuration screenshots and text.

• Example consent logs / reports.

• Access governance:

  • who can change GA4 or CMP settings,

  • confirmation of SSO/2FA,

  • audit trail or change log.

• One short note per quarter:

  • an example of a product/content improvement that came from GA4 insight (shows you’re using the data for legitimate, useful purposes, not just hoarding it).

Run a quarterly 30–45 minute review

Same agenda every time:

1. Consent reality test

   • Walk a decline → browse → withdraw journey on phone + laptop. Record it.

2. Retention

   • Confirm retention settings and review any extensions.

3. Transfers

   • Re-open the board slide and tick “still accurate” or log changes.

4. PII hygiene

   • Review the latest leak test results and fixes.

5. Value

   • Capture one “shipped change” driven by GA4 insight.

That’s the sort of cycle you can show a regulator and say, “We don’t just set and forget – we actively govern this.”

Top-line GA4 setup with full UK/EU compliance

(Acceptance criteria – no wiring)

You can share this list with engineering and ask them for demos/screenshots.

Consent-gated

• GA4 runs only after opt-in (except any explicitly documented DUAA exception applied to UK-only, low-risk analytics).

• Decline/withdrawal stops GA4 promptly across all key journeys (including AMP, iframes, and subdomains).

Scoped features

• Ads / personalisation features and granular location/device detail are off by default.

• Anything beyond “basic measurement” is enabled only with:

  • explicit scope,

  • documented consent reliance (not “we think we’re covered”),

  • a ticketed business case.

No PII

• A parameter allow-list is in place and enforced.

• Quarterly leak tests against URLs, queries, page titles, and forms.

• A block-list for obvious high-risk parameter names (email, phone, postcode, etc.).

Short retention

• Default to the shortest workable GA4 retention (e.g. 2–14 months).

• Any longer retention is documented, approved, and time-boxed with a review date.

Transfers governed

• Clear statement of which transfer mechanism is used for EU and UK data (DPF/Data Bridge vs SCCs/IDTA + TRA).

• Board-level view updated at least quarterly.

• Named owner and defined trigger conditions for changing approach.

Auditability

• Stored screenshots of GA4 and CMP settings.

• Versioned consent copy.

• At least one recent example of a change shipped from GA4 insight.

Common scenarios (and how teams handle them well)

• A/B testing tools

  • Treat experiment platforms as separate from baseline GA4.

  • Make sure consent text explains experimentation.

  • Time-box experiment data and keep experiment IDs away from anything that could identify an individual.

• Server-side events / Measurement Protocol

  • Keep EU data on EU-hosted infrastructure where possible.

  • Ensure server-side pipelines respect the consent state (no “server-side bypass”).

  • Align server logs with GA4 retention.

• App + web hybrids

  • Align the consent concept between app and web.

  • Avoid cross-context IDs unless there’s explicit consent and a clear, documented purpose.

• B2B sites with forms and CRM

  • Watch for emails/postcodes leaking into query strings, page titles, and event parameters.

  • Strip or hash at source; test “mailto:” links and CRM hand-off flows.

Friendly FAQs

“Do we always need consent for GA4 in the UK?”

If GA4 uses cookies or similar identifiers (which it typically does), PECR normally requires consent unless your GA4 usage fits squarely within a DUAA cookie exception like “statistical purposes”. That bar is narrow and requires evidence; a general marketing analytics setup usually won’t qualify.

“Is GA4 ‘GDPR-illegal’?”

There is no blanket EU ruling that GA4 is illegal as a product. Past decisions focused on UA implementations and cross-border transfers. GA4 can be compliant if you:

• get valid consent (EU, and typically UK),

• minimise what you collect,

• keep retention short, and

• use a robust transfer mechanism.

“What retention is ‘right’?”

Pick the shortest window that still lets you answer your real business questions – often 2–14 months for most teams. Anything beyond that needs a written rationale, a review date, and an owner.

“What’s the quickest win?”

Two things, fast:

1. A Consent Reality check (10 minutes, two recordings).

2. A basic parameter allow-list + leak test.

Those two steps strip out a lot of risk immediately.

Need help making GA4 GDPR compliant (and genuinely useful)?

Most analytics agencies are brilliant at tagging and dashboards—but few have deep experience in UK PECR/UK GDPR, transfers, RoPA/DPIA/TRA, or consent reality testing. That gap is why compliant setups drift.

I specialise in GA4 Legal Compliance for UK organisations. If you want GA4 to be the GDPR compliant dataset you can proudly show to boards, auditors, and customers, I can help.

What you’ll get from my GA4 Legal Compliance Audit

• Consent Reality Film (screen recordings on real devices; pass/fail grid).

• Purpose → Metric Map (which metrics drive decisions, with named owners).

• Retention Rationale (short-by-default settings; time-boxed exceptions).

• PII Leak Report (where identifiers can enter URLs/search/forms—and the fixes).

• Transfer Slide (mechanism, monitoring cadence, and a named trigger owner).

• 90-Day Action Plan: Do now / Fix this quarter / Trial once—with owners.

If your team would benefit from an expert partner who understands both analytics and legal compliance, let’s talk.

→ Book a GA4 + GTM Audit→ Ask for sample deliverables and a short scoping call

(No jargon. No theatre. Just a clean, defensible GA4 you can rely on.)