GDPR-Compliant Analytics: A Checklist for UK Data Teams

Most analytics projects don't fall foul of data protection law because someone decided to ignore the rules. They run into trouble through small, ordinary decisions: a field that seemed useful at the time, a retention job nobody owned, a cookie banner built by whoever had a spare afternoon.

The result is a pipeline that works beautifully and quietly holds more personal data than anyone can justify. What follows is a checklist for UK teams working under the UK GDPR, the Data Protection Act 2018 and PECR — consent, anonymisation, retention and the ICO's expectations — in roughly the order you'll meet them.

Start with the lawful basis, not the dashboard

Before a single event is logged, be able to answer one question for each dataset: under which lawful basis are we processing this? For product analytics, legitimate interests is the usual candidate, and it is not a free pass. It needs a documented assessment recording the purpose, why the processing is necessary rather than merely convenient, and how you balanced your interests against the individual's rights and expectations.

Consent is the right basis when you want to do something people wouldn't reasonably expect. Separately, PECR requires consent for storing information on, or reading information from, a user's device — which covers most analytics cookies and SDKs. "Strictly necessary" is a narrow category, and measurement rarely fits inside it.

Two traps. First, treating lawful basis and consent as interchangeable; they are separate tests and you can pass one while failing the other. Second, collecting "just in case" fields — date of birth, full postcode, device identifiers, free-text feedback — with no stated purpose. Every field widens the blast radius of a breach and makes a subject access request harder to answer.

Consent that survives scrutiny

Valid consent must be freely given, specific, informed and unambiguous, given by a clear affirmative action. That rules out a fair amount of what still passes for a cookie banner.

• No pre-ticked boxes, and no "by continuing to browse you agree".
• Accept and reject buttons that are equally easy to find and use. If one is green and prominent and the other a grey link three clicks deep, expect questions.
• Granular choices: analytics, advertising and personalisation are different purposes and should be selectable separately.
• Withdrawal as simple as giving consent, from the same place.
• A record of what each person agreed to: the wording they saw, the version of your notice, the timestamp. If you can't show it, you can't rely on it.
• No bundling consent with access to a service where you can reasonably avoid it.

The ICO has been clear that banners must not make rejection harder than acceptance, and it has required well-known sites to change theirs. Consent is also not permanent — refresh it when your purposes change, not only when the regulation does.

Anonymisation and pseudonymisation are not the same thing

Pseudonymised data — a hashed user ID, a salted email, a customer number swapped for a UUID — is still personal data. You can re-link it, often using a lookup table you already own. Access, erasure, breach notification and retention obligations all still apply.

Anonymisation means the data can no longer be attributed to an identifiable person by anyone, using any means reasonably likely to be used. That is a high bar. Test it against three questions: can someone single out an individual, link records about them across datasets, or infer something about them from the rest?

• Collect less. Drop full IP addresses where a truncated or coarse version will do, and avoid free-text fields that quietly catch names.
• Aggregate early. Roll events into counts and summaries before they reach the warehouse, and avoid publishing a breakdown where a group contains only one or two people.
• Band rather than store. Age ranges instead of dates of birth; region instead of full postcode.
• Document your reasoning. If you claim anonymisation, be able to show the tests you ran and the assumptions behind them.

Retention: decide the expiry date first

A retention period you can't enforce is a wish. Set one per dataset before launch, write it into your retention schedule, and automate the deletion so it doesn't depend on someone remembering. Raw event data with identifiers might live for a few months; aggregated reporting tables can live far longer; anything tied to an individual's account should end when the account does.

Things people miss: backups and disaster-recovery copies, logs, exports sitting in someone's downloads folder, and vendors that keep data on their own schedule. Test deletion end to end — pick a user, ask for their data to be removed, and confirm it has gone from the warehouse, the vendor and the backup rotation.

Vendors, transfers and the requests you'll actually get

If a vendor processes personal data on your behalf, you need a written contract meeting Article 28: processing only on your instructions, security obligations, breach notification, help with individual requests, and a list of sub-processors. Know where your data physically sits. If it is transferred outside the UK, you need an appropriate transfer mechanism and a documented assessment of the risks.

Then rehearse the awkward questions. Can you find one person across all your tables? Can you delete them without breaking your metrics? Can you export their data in a readable format? Teams that can't answer these tend to find out during a complaint, which is the most expensive time to learn.

Your pre-launch checklist

1. Purpose written down and lawful basis recorded, with a legitimate interests assessment on file where you're relying on it.
2. Every field justified — if you can't name the decision it supports, don't collect it.
3. Consent banner reviewed, with reject as easy as accept and choices logged.
4. Identifiers, aggregation and banding reviewed before the pipeline goes live.
5. Retention periods set per dataset, automated, and added to the retention schedule.
6. A DPIA completed for anything large-scale, profiling-based, or involving new technology or combined datasets.
7. Vendor contracts, sub-processor lists and transfer mechanisms checked.
8. Access, deletion and export tested on a real record.
9. A named person owns this after launch — not a team, a person.

This is general guidance rather than legal advice, and data protection decisions have to fit your organisation's circumstances — run anything material past your DPO or a data protection solicitor. The ICO's own guidance on consent, cookies, anonymisation, DPIAs and international transfers is free, readable and updated, and it remains the quickest way to sanity-check a plan before you build it.

Photo: Maximilianovich / Pixabay