Understanding UK GDPR and analytics: a compliance checklist for data teams

Most analytics problems start small. A product manager wants session recordings. A marketer adds a tag. Someone pastes an email address into a query string because it makes the report easier to read. None of it feels like a data protection decision at the time, which is precisely why it becomes one.

UK GDPR does not ban web analytics. It asks you to be deliberate about why you collect data, how long you keep it, and what people are told. Most of that work happens before the first event fires, in decisions that are far easier to make now than to unpick later.

Start with the lawful basis, not the tool

Every processing activity needs a lawful basis under Article 6 of UK GDPR. Six exist, but two come up in analytics almost every time: consent and legitimate interests.

Legitimate interests requires a three-part assessment. You identify the interest you are pursuing, show that the processing is necessary for it, and balance it against the individual's rights and reasonable expectations. Write that assessment down, date it, and revisit it when the processing changes. An unwritten balancing test is not a basis; it is a hope.

Consent applies where you rely on it, but it also applies separately under the Privacy and Electronic Communications Regulations. Storing information on someone's device, or reading information already stored there, generally needs consent unless the storage is strictly necessary to provide the service the user asked for. That means an analytics cookie needs consent even when the underlying processing could arguably rest on legitimate interests. Two tests, two answers, and teams regularly confuse them.

Pick your basis before you collect anything. You can change it later, but doing so affects what you told people and which rights they hold, so it is a considered decision rather than a tidy-up.

Consent has a higher bar than most banners clear

The standard is freely given, specific, informed and unambiguous. In practice, that means the following.

• Freely given. Nobody should suffer a real detriment for refusing. Treat cookie walls that block access unless you accept as a high-risk pattern and take advice before shipping one.
• Specific. Separate purposes need separate choices. Analytics, personalisation and advertising are not one lump.
• Informed. Name the purposes plainly, mention the main recipients, and link to privacy information that a person could actually read.
• Unambiguous. A clear affirmative action. No pre-ticked boxes, no assuming consent because someone kept scrolling.
• Withdrawable. Withdrawing must be as easy as giving. If "accept all" sits on the first layer, "reject all" belongs there too.
• Recorded. Keep evidence of what was shown, when, which version, and what the person chose. Consent you cannot demonstrate is difficult to defend.

Collect less, and know why you are collecting it

Data minimisation and purpose limitation are the two principles that save the most trouble. IP addresses, device identifiers and user IDs are personal data, even when you think of them as technical plumbing.

Some habits worth building into your tracking plan: strip query strings from page paths, and never send form contents or email addresses into an analytics tool. Round or truncate IP addresses where you can, while remembering that hashing is not anonymisation. Collect country rather than precise location unless precision genuinely changes a decision. Check the defaults on anything that records sessions, and make sure input masking is on before you record a single person, with sensitive pages excluded outright.

Server-side tagging is worth doing for control and reliability, but it is not a privacy fix. Data still leaves your infrastructure, so the lawful basis and the processor contract requirements do not disappear because the request looks tidier.

Set retention by purpose, and actually delete

Storage limitation asks a simple question: how long do you need this, and why? Answer it per layer rather than per tool.

Raw event data might justify a longer window than user-level profiles, and aggregated reporting tables can often be kept longer still because they carry less risk. Whatever the window is, automate the deletion. Policies that rely on someone remembering to run a script tend to fail quietly. Document the reasoning too, so the next person can see why fourteen months was chosen. And decide what happens in backups, because a deletion in production rarely propagates to every archive the same day.

Anonymisation: useful, but do not overclaim it

This is where the arguments get sharpest. Anonymisation means the data can no longer be attributed to an identified or identifiable person. When you assess that, you must consider the means reasonably likely to be used to identify someone, taking account of cost, time and available technology.

Three risks are worth testing against: singling out one person in a dataset, linking records about the same person across datasets, and inference of attributes they never disclosed. A hashed user ID is pseudonymisation rather than anonymisation if you hold the key or can re-link it elsewhere. Aggregated reports with very small counts can reveal individuals, so suppress small cohorts rather than publishing them.

Genuinely anonymous data sits outside UK GDPR, which is why the label is tempting. The bar is high, though, and you should be able to explain your reasoning to a regulator without wincing.

Cover the edges: processors, transfers and accountability

Most analytics stacks involve vendors acting as processors. That requires a written contract covering the points set out in Article 28, a current list of sub-processors, and a way to notify you when that list changes. If data leaves the UK, you need a transfer mechanism, such as UK adequacy regulations or the International Data Transfer Agreement, plus a transfer risk assessment where the destination raises concerns.

Some activities call for a data protection impact assessment: large-scale tracking, session replay, or profiling that affects people in meaningful ways. Keep your record of processing activities current, and involve whoever owns privacy early, while the design is still fluid.

This is general guidance rather than legal advice. Data protection rules interact with sector regulation and with contracts in ways that depend on your circumstances, so involve your privacy lead or a qualified adviser on decisions that carry real risk.

A checklist for your next sprint

1. List every tool that touches user-level data, including the ones someone added without telling you.
2. Write down the lawful basis for each, and the cookie or device-storage position under the electronic communications rules.
3. Audit the consent banner: purposes separated, reject as prominent as accept, withdrawal simple, records kept.
4. Review the tracking plan for query strings, form fields, email addresses and unnecessary identifiers.
5. Confirm session recording masks input and excludes sensitive pages by default.
6. Set and automate a retention window for each data layer, and document the reasoning.
7. Test your anonymisation claims before repeating them in a privacy notice.
8. Check processor contracts, sub-processor lists and any international transfer paperwork.
9. Book a review in six months, or sooner if the stack changes.

None of this is glamorous work, and that is rather the point. A team that can explain its lawful basis, show its consent records, and delete data on schedule is not just compliant. It is a team that can adopt a new tool in an afternoon instead of a quarter, because the groundwork is already done.

Photo: stevepb / Pixabay