How UK GDPR and PECR consent rules shape customer data platform audiences

What to take away

Where UK GDPR lawful basis choices meet PECR consent for a customer data platform

A customer data platform holds identity, behaviour and contact data in one place. That makes it the natural point where two UK regimes collide: UK GDPR, which governs personal data processing, and PECR, which governs electronic marketing.

The audience you build is only lawful if both are satisfied. This is the join most UK teams get wrong, because they treat consent as a marketing setting rather than a data protection decision.

Start with the distinction. UK GDPR requires a lawful basis for processing personal data. PECR requires consent, or a narrow soft opt-in, before you send electronic marketing. Choosing legitimate interests as your UK GDPR basis does not give you permission to email under PECR.

The two tests are separate, and a CDP audience that ignores the second will fail on the first complaint.

The Data Protection Act 2018 sits underneath both. It supplies the statutory framework for UK GDPR, sets out the ICO's powers, and creates the exemptions and offences that shape what a UK marketing operation can do.

A team mapping a customer data platform build for privacy review without picking the lawful basis will end up with a data map that cannot answer the first question an ICO caseworker asks.

Lawful basis choices in a CDP usually fall into three groups. Consent covers marketing to prospects and to customers who have actively opted in. Legitimate interests covers analytics, suppression and fraud prevention. Contract covers fulfilment and service messages. Most mature UK estates run all three at once, tagged per purpose, not per record.

The practical consequence is that your CDP schema needs a purpose field, not just a consent flag. A single contact can be lawful for service email, unlawful for newsletter email and lawful for postal mail, all on the same day. If the platform cannot represent that, your audience builder will quietly over-send.

Consent as a lawful basis: the ICO validity test applied to audience records

Consent is one of the six lawful bases for processing personal data, and it is the one with the highest maintenance cost. The ICO consent guidance sets the standard your records must meet.

Freely given means real choice, with no detriment for refusing. Pre-ticked boxes, bundled terms and consent as a condition of service all fail. In a CDP this matters most at the point where you merge a newsletter opt-in into a wider marketing permission. If the customer could not have used the service without agreeing, the consent is not valid.

Specific means granular. Consent to email is not consent to SMS, to profiling, or to sharing with partners. UK audiences built from a single "yes to marketing" checkbox fail the specificity limb, and the fix is per-channel, per-purpose records rather than one all-purpose flag.

Informed means the customer knew who was asking and what for, at the moment they agreed. The organisation must be named, and any third-party reliance must be named too. A CDP that stores consent against a brand but sends from a group company has an informed problem, not just a branding one.

Unambiguous means a clear affirmative action. Silence, inactivity and default settings are not consent. The ICO's page on what is valid consent spells out that the four elements must all be present, which is why an audience built on an inferred opt-in is the riskiest kind of record in the platform.

Apply the test as a checklist against a sample of records before you trust the audience. Take 50 contacts, trace each back to the capture event, and ask whether a stranger could see the four elements. If not, the fix belongs upstream in the capture form, not in the CDP query.

PECR soft opt-in limits for email, SMS and calls in a CDP audience build

The PECR soft opt-in is the one exception that lets UK organisations market electronically without prior consent. It applies to email, SMS and calls, and only where the recipient's details were obtained in the course of a sale or negotiations for a sale.

The ICO guide to PECR sets out the conditions, and they are tighter than most marketing teams assume.

The product must be similar to what was sold. A customer who bought a training course can be offered another course. They cannot be moved into a different product line on the strength of the same transaction. In a CDP this means the soft opt-in flag must carry the original product category, not just a yes or no.

You must have given an opt-out at the point of collection, and in every subsequent message. The opt-out has to be simple and free. A suppression list that takes three days to propagate through the CDP is a PECR problem, because the next send may still include the person who opted out.

Soft opt-in does not cover postal mail, which sits under UK GDPR and the direct marketing rules rather than PECR. It does not cover online advertising or social audiences. It does not cover prospects, only existing customers and people in live negotiations.

Every one of those limits needs to be encoded as a rule in the audience builder, not left to a campaign manager's memory.

The most common CDP failure here is audience overlap. A soft opt-in segment for existing customers gets combined with a consented prospect segment, and the merged audience is sent the same message. The prospects are fine, the customers are fine, but the suppression logic is not, because the message content no longer matches the basis for each group.

Keep segments separate at send time.

Consent records and evidence: what a customer data platform must be able to show

Consent records are the evidence layer. Under UK GDPR you must be able to demonstrate that consent was given, which means the CDP has to store more than a boolean. The ICO guidance is clear that the controller carries the burden of proof, so a record you cannot produce is a record you do not have.

A seventh field matters in practice: the version of the privacy notice in force at the time. Wording changes, and a record tied to an old notice version is still valid if the customer agreed to that wording. Without the version, you cannot show what they were informed of.

Withdrawal of consent must be as easy as giving it, and it must stop processing, not just future sends. If someone withdraws, the CDP should suppress them from the relevant audiences and record the withdrawal with its own timestamp. Keeping the withdrawal record is lawful and necessary, even though the consent itself is gone.

Run a quarterly evidence drill. Pick ten records at random, and try to reconstruct the consent story from the platform alone, without asking the campaign team. If you need a human to explain a record, the record is not doing its job.

This is the same discipline that runs from the statutory record onwards in a UK compliance build.

Cookies, storage and access technologies inside CDP tracking

Cookies and similar technologies sit under PECR, not UK GDPR, and they need their own consent. The ICO guidance on cookies and similar technologies covers storage and access on a user's device, and it applies to pixels, local storage, device fingerprinting and SDK identifiers, not just HTTP cookies.

This is where CDP tracking most often breaks UK rules. A platform that writes an identifier to a browser or app before the user has consented is in breach, even if the data never leaves the UK. Consent must be obtained before the storage or access happens, except for strictly necessary purposes such as security and load balancing.

Analytics is not strictly necessary. Neither is audience measurement, attribution or personalisation. If your CDP uses a first-party cookie to stitch sessions, that cookie needs consent. If it uses a server-side identifier that never touches the device, PECR does not bite, which is one reason UK teams are moving identity resolution server-side.

The consent banner and the CDP must be wired together. A common failure is a tag manager that fires before the consent management platform has resolved the user's choice. The result is a record that says the user consented, and a tracker that ran anyway. Both are visible in an ICO complaint.

Keep a register of every storage and access technology your CDP deploys, with its purpose, duration, and the lawful route. Review it whenever a new destination, pixel or SDK is added. The register is the artefact that turns a vague cookie policy into an accountable one.

Accountability, DPIAs and the Data Protection Act 2018 duties behind the audience

The Data Protection Act 2018 is the statute that makes UK GDPR workable in Britain. It sets the framework, defines the ICO's enforcement powers, and creates the exemptions and offences that apply to marketing and data sharing. Any accountability argument you make about a CDP audience ultimately rests on it.

Accountability under UK GDPR requires you to demonstrate compliance, not merely intend it. In practice that means a record of processing activities, a documented lawful basis per purpose, and evidence that the basis was considered before the audience was built. The ICO expects to see the reasoning, not a retrospective note.

A DPIA is required where processing is likely to result in a high risk to individuals. Large-scale profiling, systematic monitoring and combining data from multiple sources are the classic triggers, and a CDP that builds lookalike or propensity audiences will often cross that line.

Do the DPIA before the audience goes live, and update it when the model or the data sources change.

Map which UK regimes touch a customer data platform build, and who owns each one, before you sign off the work. UK GDPR and PECR sit with the ICO. Advertising claims sit with the Advertising Standards Authority.

Competition and consumer issues can involve the Competition and Markets Authority. Industry codes from the IPA and the DMA shape practice but do not replace the law.

The DPA 2018 also matters for data subject rights. Access, erasure and objection requests must be answerable from the CDP, across every source system it ingests. If a deletion in the CRM leaves the CDP copy intact, the erasure is incomplete. Test the path, not the policy.

Withdrawal, refresh and re-permission cycles for UK audiences

Withdrawal of consent is a live process, not a setting. When someone withdraws, the CDP must stop using their data for the consented purpose, record the withdrawal, and propagate it to every downstream system that received the audience. The ICO consent guidance treats withdrawal as a core requirement, and speed matters: the next send is the test.

Build withdrawal as a first-class event. It should carry a timestamp, a channel, a purpose and a source, exactly like the original consent. A withdrawal that only clears a marketing flag in the ESP leaves the CDP audience intact, and the next export will re-add the person.

Refresh cycles keep consent defensible over time. There is no fixed expiry in UK law, but consent that has not been touched for years is harder to evidence, and re-permission is the clean remedy. Use a rolling review by cohort rather than a single purge date, so the operational load stays even.

Re-permission is not always the right answer. If the original consent was valid, you can rely on it and simply improve the record. If it was not, a fresh opt-in is the only route back to lawful marketing for that contact. Decide per cohort, and document the decision.

Finally, keep the audience definitions under version control. When the basis, the notice or the purpose changes, the audience definition changes with it. A CDP that can show the version history of an audience, alongside the consent records that fed it, is the one that will survive an ICO enquiry with its evidence intact.

Common questions