Purpose limitation is the actual gate
UK GDPR says personal data collected for one purpose cannot simply be reused for an unrelated one. Data intelligence projects are, structurally, the reuse of data collected for something else — which is why they stall at legal review more often than at technical review.
The compatibility test is not a formality and it is not the same for every ambition:
- Analysing order history to forecast stock is closely tied to why the order data was collected. Usually compatible.
- Building a dashboard of aggregate customer behaviour is a step further, but the output is not about individuals. Usually workable.
- Scoring individuals to decide who gets an offer is a new purpose with effects on people. Needs its own basis, and possibly a DPIA.
We ask which of these you want during discovery, because the answer changes the architecture. A system designed for the first two can be built without identifiers ever entering the warehouse. A system designed for the third cannot, and should be scoped knowing that.
Pseudonymise at ingestion, not later
The single highest-leverage decision in a UK data project is where identity stops.
If names, emails and account numbers are replaced with stable pseudonyms at the point data enters the pipeline — with the mapping held in your systems, not ours — then the warehouse, the models and the dashboards downstream contain data that is much harder to attribute to an individual. Transfers become far less fraught. Erasure becomes a change in one table rather than an archaeology exercise across five stores. Breach impact drops.
This is not anonymisation and we will not call it that. Pseudonymised data is still personal data under UK GDPR, because the mapping exists. But it materially reduces risk at every stage, and it is nearly free if decided at the start and expensive to retrofit — which is the whole argument for raising it in the first conversation rather than the fifth.
Where the analysis happens
Everything on the UK page about US processing applies. For data intelligence it applies to the largest volume of data in any engagement, so it is worth being concrete about what that means in scoping:
Your systems can stay yours. If the requirement is that the warehouse sits in a UK or EU region, that is an infrastructure specification we can build to. It changes where things are provisioned, not how the pipeline works.
Our access is the transfer that remains. Even with UK-hosted infrastructure, building and supporting the thing means engineers looking at data. That is scoped explicitly — which environments, which datasets, whether production access is needed at all, and whether a masked or synthetic dataset would do for development. Frequently it would.
Derived stores are the ones people forget. Model training sets, extract files, notebook outputs and BI caches are all copies. They need the same retention and erasure treatment as the warehouse, and they are the reason an erasure request that looks simple turns out not to be.
DSARs against a warehouse
A subject access request has to reach every copy. If your analytics stack holds identifiable data in four places, the answer has to cover four places within a month.
Designing for this is straightforward when it is a requirement from the start: either every derived store carries a resolvable pseudonym that maps back through a single table you control, or the derived stores hold no identifiers at all and are simply out of scope for the request. The second is better and is achievable more often than teams assume.
What does not work is discovering the question when the first request arrives.
What this changes about the engagement
Discovery covers purpose, lawful basis and the identity boundary before it covers schemas and dashboards, and the written plan states which datasets carry identifiers, where each copy lives, how long it is kept, and how erasure and access requests are answered. That is the document your DPO wants, and it is the same one that makes the build estimable.
Contracting, currency and hours are as set out on the UK page: quoted and invoiced in USD, contracted under Colorado law, working overlap in the UK afternoon.