In Short: What Does GDPR Actually Require of an Analytics Platform?
Four things you must be able to demonstrate: a lawful basis for processing personal data analytically, minimisation rather than landing everything, retention that is enforced by the platform rather than described in a policy, and the ability to answer who can see personal data with a report rather than an investigation. Analytics is not exempt, and "it is only for reporting" is not a lawful basis.
Yes, It Applies to Your Lakehouse
There is a persistent assumption that data protection is an operational-systems problem and analytics is downstream of it. It is not. If personal data is being processed - and a customer identifier in OneLake is personal data - the obligations apply.
What changes in an analytics context is the shape of the risk. Operational systems hold personal data about the people they serve. Analytics platforms tend to hold everything, joined together, accessible to more people, for longer. That combination is precisely what regulators are concerned with.
The ICO's guidance for organisations is the authoritative UK reference. What follows is how the obligations translate into architecture.
Lawful Basis
You need one, and it needs to be documented before processing rather than justified afterwards.
For most business analytics the basis is legitimate interests, which requires a balancing assessment: your interest in the processing, weighed against the individual's rights and reasonable expectations. That assessment is a document your DPO owns, informed by an accurate description of what the platform actually does.
Two places this gets uncomfortable, and both are worth surfacing early:
Analysis the individual would not expect. Reporting on order volumes is unremarkable. Profiling individual behaviour to predict something about them is a different conversation, and may require a different basis.
Repurposing operational data. Data collected to fulfil an order and then used to train a model is being used for a new purpose. That needs thinking about, not assuming.
Neither is an architecture question - but the architect needs to know the answer, because it determines what may be landed.
Minimisation in a Lakehouse
Minimisation conflicts directly with the lakehouse instinct to land everything now and decide later. It has to be deliberate or it does not happen.
Three practical measures:
Do not ingest what no report needs. The default of copying every column from every source is convenient and hard to defend. If nothing consumes a personal field, leave it in the source system.
Pseudonymise where identity is not required. Much analysis needs a stable customer key, not a name and address. Replacing direct identifiers in analytical layers reduces exposure substantially while changing nothing about the analysis.
Aggregate early where individual detail is not the point. If the question is trend by segment, land the aggregate rather than the population.
Retention That Actually Deletes
This is the obligation most commonly failed, and the failure is nearly always the same: a policy exists, and the platform does not implement it.
Retention must be enforced by lifecycle rules that delete, per data category, with evidence that deletion occurred. A policy stating seven years while the lakehouse holds nine is worse than no policy, because it documents a rule you are demonstrably breaking.
The architectural wrinkle is that lakehouses are append-only by design. Deleting specific records from partitioned Delta tables is possible but needs designing - how you partition determines how expensive erasure is. Decide this during design, not when a request arrives with a deadline attached.
Subject Access and Erasure
Both requests reduce to one capability: knowing where personal data lives.
With Purview classification applied across the estate and lineage traced from source to report, a subject access request becomes a query. Without it, it becomes a search across every dataset by someone who hopes they have found them all - which is slow, expensive, and impossible to evidence as complete.
Erasure is harder, because personal data in an analytics estate propagates: raw layer, conformed layer, aggregates, semantic models, cached report data. Map that propagation before you need to reverse it. Where full erasure is genuinely impractical, pseudonymisation at ingestion is often the better design - you cannot be asked to erase what you never held in identifiable form.
Proving Access Control
"Who can see personal data, and can you prove it?" is the question that separates a governed estate from an asserted one.
The answerable version has three parts: role-based access through Entra so permissions attach to roles rather than individuals, row-level security so entitlement is enforced at the data layer rather than by which report someone opened, and platform audit logging so access is evidenced rather than assumed.
If access is managed by habit, memory and historical sharing decisions, the honest answer is that you cannot prove it - and that is itself a compliance finding. Our guide to governed access covers the implementation.
Sensitivity Labels and the Export Problem
The most common real-world leak is not a breach. It is an export.
Data leaves the governed platform for a spreadsheet, and every control designed into the architecture stops applying. Sensitivity labels mitigate this by travelling with the data into exports, carrying encryption and usage policies beyond the platform boundary.
The deeper fix is to make the governed route the convenient one. People export because self-service did not give them what they needed - which makes export volume a useful proxy for how well your platform actually serves its users.
Where Solv Systems Comes In
We build data platforms for organisations with UK GDPR obligations across the UK, EU and South Africa, and we design the obligations into the architecture rather than documenting them alongside it.
In practice that means classification applied where data lives, access enforced at the data layer, retention implemented as lifecycle rules that actually delete, and lineage that turns "where did this come from" into a report. We are not lawyers and we do not give legal advice - your DPO owns lawful basis and policy. What we own is making sure the platform can actually do what the policy says it does.
Sources and Further Reading
Frequently asked
Yes. If personal data is being processed - and a customer identifier in a lakehouse is personal data - the obligations apply to your analytics estate exactly as they do to operational systems. Analytics is not an exemption, and 'it is only for reporting' is not a lawful basis.
Usually legitimate interests, though that requires a documented assessment weighing your interest against the individual's rights, not an assumption. Where analytics goes beyond what the individual would reasonably expect, the assessment gets harder and consent may be needed. This is a question for your DPO, informed by what the platform actually does.
It conflicts with the instinct to land everything, so it has to be deliberate. Practical approaches: do not ingest personal fields no report needs, pseudonymise identifiers in analytical layers where the analysis does not require identity, and aggregate early where individual-level detail is not the point.
Know where personal data lives before you are asked. Classification through Purview and lineage across the estate turn a request into a query rather than a search. The harder problem is usually erasure in an append-only lakehouse - design for it up front rather than discovering the constraint under a deadline.
Retention has to be enforced by the platform, not written in a policy. That means lifecycle rules that actually delete, applied per data category, with the deletion evidenced. A policy document stating you keep data for seven years is worth nothing if the lakehouse holds nine.
With a report, not an investigation. Role-based access through Entra, row-level security at the data layer and platform audit logging together mean the question has a factual answer. If access is managed by habit and memory, you cannot answer it - which is itself a compliance problem.
