Written in November 2025. The UK Data Bill this article refers to is now law as the Data (Use and Access) Act 2025.
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 transfer mechanism to the US, with evidence for each?
That's the bar now. This is a working checklist for Legal, the DPO and the digital team: what good looks like, and what evidence to keep. For the full picture of what UK GDPR and PECR require of GA4, read the main guide from GA4 consultant Marc Alexander, GA4 and UK GDPR.
Where things stand.
After Schrems II, regulators ruled against specific Universal Analytics setups that sent EU data to the US without sufficient safeguards. They did not ban analytics. GA4 doesn't log IP addresses by default and has more granular regional controls. There is no EU-wide ruling that GA4 is illegal as a product, but regulators expect you to configure and govern it properly.
UK: DUAA, UK GDPR and PECR
- The Data (Use and Access) Act 2025 (DUAA) amends UK GDPR, the Data Protection Act 2018 and PECR.
- It lets some cookies and similar technologies be set without consent where the risk is low: "statistical purposes" (aggregated analytics used only to improve the service), "appearance" (adapting how a service looks or works to user preferences), plus the existing strictly necessary and emergency assistance exceptions.
- PECR fines now match UK GDPR: up to 17.5 million pounds or 4% of global turnover.
- The changes have applied since 5 February 2026. The ICO is clear that the exceptions are narrow, and its final guidance (29 April 2026) sets strict conditions for each. Either you meet every condition for an exception, or you get consent.
EU/EEA (and Switzerland in most practice)
- ePrivacy rules still expect opt-in consent for analytics and marketing cookies unless they're strictly necessary.
- GA4 can be made compliant with minimisation, consent and a proper transfer tool: the EU-US Data Privacy Framework for certified recipients, or Standard Contractual Clauses (SCCs) plus a Transfer Risk Assessment (TRA).
In practice
Treat EU users as consent-only for GA4. For UK users, rely on a DUAA exception only if Legal or the DPO confirm in writing that your GA4 configuration fits the "statistical purposes" conditions and the implementation matches. Otherwise, assume consent is required.
The rest of this article assumes a consent-first baseline you can defend under both regimes.
1. Consent under PECR and ePrivacy.
What to do together
- Make sure the consent platform really gates GA4. GA4 should be blocked until opt-in on desktop and mobile, on the first pageview, deep links, logged-in pages, iframes and AMP where relevant. If you rely on a DUAA exception for narrowly defined UK analytics, document it separately.
- Offer a real choice. "Decline" should be as easy and visible as "Accept", with "Reject all" not hidden behind "More options". The ICO has flagged design nudges and now has GDPR-level fines to back that up.
- Make withdrawal immediate. Put a privacy settings link in the footer and in-app menus. Withdrawal should stop GA4 across subdomains, iframes and AMP.
A monthly reality test
Once a month, spend ten minutes recording a decline journey on mobile and desktop: home, a key content page, back and forward, a modal, a new tab, and a login if you have one.
Check the network calls and storage. There should be no GA4 requests and no GA cookies or identifiers before consent, and withdrawal should stop GA4 on later hits. Keep the recordings.
Evidence to file
- The current consent banner text and screenshots, versioned.
- Consent logs or summary reports, even if sampled.
- The latest pass or fail sheet from the monthly test.
- If you rely on a DUAA exception: a note from Legal or the DPO naming the exception, the configuration it covers and its review date.
2. Minimise collection and keep personal data out.
What to agree
- A do-not-collect list. No names, emails, phone numbers, exact postcodes or internal customer IDs in event parameters, page paths, query strings or form values. No free-text fields piped into GA4.
- Scoped features. Ads features, remarketing and Google Signals only when there's a clear business case and consent to match. Skip detailed location and device data you don't need.
- Short retention by default. Use the shortest workable GA4 data retention (standard properties offer 2 or 14 months). Any extension needs a written, time-boxed reason with an owner and a review date.
A hygiene routine
Keep a parameter allow-list: which event parameters and user properties may reach GA4. Anything not on it is blocked or stripped first.
Then run a quarterly leak test: crawl key pages and flows, submit safe test inputs (fake emails, postcodes, phone-like numbers), and inspect URLs, page titles and network requests for personal data. Fix what leaks and test again.
Evidence to file
- The current allow-list.
- The last leak test report and the fixes made.
- Screenshots of GA4 retention, Signals and ads personalisation settings.
- Any retention extension memo, with its end date and owner.
3. Lawful basis and documentation.
The paperwork has to match what's configured.
- Record of Processing Activities (RoPA). Describe GA4's purposes, data categories, data subjects, recipients, retention, transfers and security measures, under UK GDPR and, where you process EU data, EU GDPR.
- Notices that reflect reality. Plain English privacy and cookie notices should say that you use GA4, why, that consent is required (except where a clearly defined UK exception applies), how to withdraw, and how long data is kept.
- Assessments. A DPIA where the scale or combination of tracking makes the risk likely to be high. A TRA where you rely on SCCs or the UK IDTA rather than the Data Privacy Framework or UK Data Bridge. If you rely on a DUAA exception, a short addendum explaining why your configuration fits the "statistical purposes" criteria: aggregated, no individual profiling, no cross-site tracking.
- A stated purpose. One paragraph agreed with product and marketing on what GA4 is for (for example "identify confusing content, diagnose performance issues").
Evidence to file
- The current RoPA entry for GA4.
- PDF copies of the live privacy and cookie notices.
- The DPIA and TRA, or a clear statement of why they're not needed.
4. International transfers.
GA4 usually means transfers out of the UK and EU. Decide, and write down:
- For EU data: the EU-US Data Privacy Framework for Google (if certified), or SCCs plus a TRA with any supplementary measures such as encryption, access controls and minimisation.
- For UK data: the UK-US Data Bridge (the UK extension of the framework), or the IDTA or SCCs plus a TRA.
- One slide, updated quarterly, that says what leaves the UK and EU, where it goes, which mechanism you rely on and who owns it.
Write down the triggers for a review (a change to the framework's adequacy status, a major regulator ruling on GA4 transfers, Google changing where GA4 data is processed) and name who decides what happens next.
Evidence to file
- The current transfer slide, dated.
- The last review note, confirming it's still accurate or recording changes.
- Proof of the vendor's certification, or the TRA conclusions for SCCs or the IDTA.
5. Evidence and accountability.
A simple evidence pack
- GA4 admin screenshots: retention, Signals, ads personalisation and data sharing settings.
- Consent platform configuration screenshots and text, plus example consent logs.
- Access governance: who can change GA4 or consent settings, two-factor or single sign-on, and a change log.
- One short note a quarter describing a change that came from GA4 data, showing you use it for a legitimate purpose.
A quarterly review, same agenda every time
- Consent: walk a decline, browse, withdraw journey on a phone and a laptop, and record it.
- Retention: confirm the settings and review any extensions.
- Transfers: reopen the slide and mark it still accurate, or log the changes.
- Personal data: review the latest leak test and fixes.
- Value: note one change shipped because of GA4 data.
Thirty to forty-five minutes a quarter gives you a cycle you can show a regulator.
Acceptance criteria for engineering.
Ask your developers for a demo or screenshots of each point.
- Consent-gated: GA4 runs only after opt-in, except for any documented DUAA exception on UK-only, low-risk analytics. Decline and withdrawal stop GA4 everywhere, including AMP, iframes and subdomains.
- Scoped features: ads personalisation and detailed location and device data are off by default. Anything more needs documented consent reliance and a business case.
- No personal data: the allow-list is enforced, high-risk parameter names (email, phone, postcode) are blocked, and leak tests run quarterly.
- Short retention: the shortest workable setting, with any longer period approved and given a review date.
- Transfers governed: a stated mechanism for EU and UK data, reviewed quarterly, with a named owner and defined triggers.
Common scenarios.
- A/B testing tools: treat them separately from baseline GA4, explain experimentation in the consent text and time-box experiment data.
- Server-side events and the Measurement Protocol: keep EU data on EU-hosted infrastructure where possible, make sure the server pipeline respects the consent state (no server-side bypass), and align server log retention with GA4.
- App and web together: use the same consent model in both, and avoid cross-context IDs without explicit consent.
- B2B sites with forms and a CRM: watch for emails and postcodes leaking into query strings, page titles and event parameters, and strip them at source.
Compliant setups drift because tagging and privacy sit with different people. For an outside check, Marc's GA4 mini audit looks at consent alongside tracking, key events and attribution.