Data & Compliance

Building GDPR-compliant customer data platforms: lessons from the field

The gap between a CDP that's technically compliant and one that handles consent gracefully at scale is where most projects fail. Here's what we've learned.

Customer Data Platforms have become a standard component of the modern marketing and CX technology stack. They promise a unified customer view — a single record that combines data from web, mobile, CRM, point-of-sale, and third-party sources to enable personalisation, segmentation, and analytics at scale.

The GDPR compliance challenge is not, as is often assumed, primarily a technical one. It is an analysis and governance challenge. The technology can be configured to be compliant. The hard work is understanding what "compliant" actually requires in a given organisational context — and ensuring that the people making technical decisions have that understanding.

Where CDP compliance fails in practice

In our experience working with organisations on data platform projects, compliance failures cluster around three areas.

Consent management at the point of collection. Most organisations have a cookie consent banner. Fewer have a consent management architecture that accurately propagates consent decisions across all data collection points, stores consent records with sufficient granularity to prove what a user consented to and when, and handles consent withdrawal in a way that actually removes the data from all processing pipelines.

The technical implementation of consent management is relatively straightforward. The requirements analysis is not. What does "marketing communications" mean in terms of specific processing activities? Which data is processed under legitimate interest rather than consent, and has that legitimate interest been properly assessed? What happens to data collected before the current consent framework was implemented?

These questions require careful analysis of how data is actually used, which often differs significantly from how it is documented.

Data minimisation in practice. GDPR's data minimisation principle requires that only data necessary for the specified purpose is collected and retained. In a CDP context, this is harder than it sounds. CDPs are designed to collect and unify as much data as possible — that is their value proposition. The pressure from marketing and product teams to collect more data is constant.

The compliance requirement is a genuine constraint on that pressure, and it requires someone with enough understanding of both the business requirements and the regulatory obligation to make principled decisions about what data is in scope. This is not a legal function or a technical function. It is an analysis function.

Third-party data governance. CDPs typically ingest data from multiple third-party sources — advertising platforms, analytics tools, partner data providers. Each of those data flows carries its own compliance questions: what lawful basis applies, what data sharing agreements are in place, what happens if the third party has a breach.

In practice, third-party data governance is the area where documentation most commonly fails to reflect reality. The data processing agreements exist. The actual data flows are more complex than the agreements describe. Identifying the gap requires mapping what data actually moves where — a time-consuming but essential analysis task.

What good CDP governance looks like

The organisations that deploy CDPs successfully — technically functional, legally defensible, and operationally sustainable — share a few common characteristics.

They treat the DPIA as a live document rather than a one-time compliance exercise. The DPIA is updated when new data sources are added, when processing purposes change, and when third-party relationships evolve. It reflects the current reality of the platform, not the reality at the time of initial deployment.

They have clear data ownership. Someone is accountable for each data domain within the platform — not just technically, but in terms of the business decisions about purpose, retention, and consent basis. Accountability is not diffused across the technical team.

They build consent management into the data architecture rather than layering it on top. Consent records are first-class data objects, with the same governance and retention policies as the customer data they relate to. Consent withdrawal triggers processing changes, not just consent record updates.

And they invest in the analysis work upfront. The projects that struggle are typically the ones where the analysis phase was compressed to accelerate delivery. The questions that weren't answered at the start resurface as compliance risks or operational failures at the end.

The BA's role in CDP projects

Business analysts are well-positioned to own the governance strand of a CDP implementation — bridging between the legal requirements, the business use cases, and the technical implementation. The specific skills required are not exotic: stakeholder elicitation, requirement documentation, gap analysis, impact assessment, data flow mapping.

What is required is a working understanding of GDPR's core principles and how they apply in a data platform context — and the seniority to push back when business requirements conflict with compliance obligations.

CDP projects that have a BA with that profile embedded throughout delivery perform significantly better on compliance outcomes than those that treat governance as a separate workstream or a legal sign-off at the end. The analysis has to happen in the design, not after it.

AI Workplace Simulator

Stop describing what you know.
Start showing what you can do.

30 days. 26 verified deliverables across the Junior and Intermediate BA tiers. A portfolio employers can inspect.

More from the blog