Consent Management Platform

A consent management platform (CMP) is software that captures, stores, and enforces individuals' choices about how their personal data is used. On websites and apps, this is the mechanism behind cookie consent banners. In CRM and marketing systems, it is the infrastructure that determines whether a contact can legally be emailed, called, or targeted with advertising.

A CMP that is misconfigured, poorly integrated, or treating consent as a UI problem rather than a data architecture problem will not produce records that hold up to regulatory scrutiny.

What a CMP must do

Capture consent with full context

The consent record must contain: the exact text of the consent request shown to the individual, the timestamp, the version of the privacy notice in force at that moment, the channel (web, mobile, in-person), and the purpose for which consent was given. Capturing a boolean "consented: yes" with no context is not a consent record — it is a checkbox.

Support granular purposes

Under GDPR Article 7 and Recital 32, consent must be specific. A single blanket "I agree to marketing" is not valid where the organisation uses the data for multiple distinct purposes. The CMP must support separate consent per purpose: email marketing, phone outreach, profiling, third-party sharing, and so on.

Enforce withdrawal in real time

Consent must be withdrawable as easily as it was given. The CMP must propagate withdrawal to every downstream system that acts on that consent — email platforms, ad networks, enrichment tools, analytics platforms — immediately or at the next sync cycle. A CMP that records withdrawal but does not enforce it is a liability, not a control.

Maintain a consent audit trail

The audit trail is what you show a supervisory authority. It must be immutable: readable by administrators, but with a complete change history that cannot be edited after the fact. Where reconsent is required (because the notice changed materially), the history must show the gap between withdrawal of original consent and capture of the new one.

Handle preference management alongside consent

Consent is a legal basis. Preferences are expressions of how a contact wants to be communicated with — frequency, channel, topic. The two are related but distinct, and a CMP that conflates them creates audit complexity. The platform should model both separately.

Architecture options

Standalone CMP (e.g. OneTrust, Cookiebot, TrustArc)

Purpose-built for consent and privacy management. Strong audit trail, regulator-recognised, multi-jurisdiction support. Requires integration with CRM and marketing platforms to enforce downstream. The integration layer is where most implementations fail.

CRM-native consent module

Salesforce, Dynamics 365, and several other platforms offer consent tracking within the CRM record. Enforcement is native — no cross-system propagation required. Coverage is limited to data processed in that CRM; any processing outside the CRM (web analytics, ad platforms) requires a separate mechanism.

CDP with consent layer

Customer Data Platforms increasingly include consent as a first-class attribute. The consent record travels with the identity graph, so enforcement is applied at the point of activation regardless of the downstream channel. More complex to implement; requires the organisation to have adopted the CDP as its identity spine.

Integration requirements

A CMP's value is proportional to how many downstream systems it controls. Map your integration requirements before evaluating vendors:

System category	Consent propagation mechanism	Notes
CRM	API or native connector	Must update contact record in real time
Email platform	Suppression list sync or API	Withdrawal must block send within the same sending cycle
Marketing automation	List membership sync	Profiles based on withdrawn consent must be excluded
Paid media (Meta, Google)	Customer list upload / offline conversions	Re-uploading lists without filtering withdrawn contacts is the most common enforcement trigger
Web analytics	Tag manager consent signal	GA4, Mixpanel, and similar require consent mode configuration
Data warehouse	Event stream	Consent events must flow into the warehouse so data access queries can filter by consent status

Selection criteria

1. Regulator recognition

The EU Data Protection Board's guidance on CMPs for cookies is the benchmark. A CMP that has been reviewed by a national supervisory authority (CNIL in France, ICO in the UK) and found adequate is materially lower risk than one that has not.

2. Geo-specific notice management

GDPR requires specific wording; UK GDPR has diverged post-Brexit; Swiss nDSG has different requirements again. If your organisation serves individuals in multiple jurisdictions, the CMP must serve the correct notice version based on the visitor's location — not a generic global notice.

3. Consent versioning

When you update your privacy notice, you need to know: (a) which contacts consented under the old version, (b) whether the change is material enough to require reconsent, and (c) how to reach those contacts to obtain updated consent without using the marketing channels that the expired consent covered. The CMP must support all three.

4. Proof of consent on demand

Supervisory authorities can request proof that a specific individual gave consent. The CMP must be able to produce a single-contact consent history — not an aggregate report — within the time required by the authority (typically 72 hours for breach-adjacent requests).

5. API completeness

Every downstream system will need to query consent status programmatically. The CMP's API must support: lookup by contact identifier, consent status by purpose, full consent history, and webhook notifications on status change. A CMP with a read-only API or with a rate limit that cannot handle your volume will require workarounds that create audit gaps.

Implementation sequence

Step 1 — Purpose inventory

List every purpose for which you process personal data that requires consent as the lawful basis. Do not include processing covered by contract or legal obligation. The purpose inventory becomes the structure of your consent model.

Step 2 — Notice drafting

Each purpose requires a description in plain language that a non-specialist can understand. The description must accurately reflect what you actually do with the data — not what you aspire to do, not a generic privacy notice template.

Step 3 — CMP configuration

Configure the platform against the purpose inventory. This includes the consent UI (banner design, placement, and interaction model), the preference centre, and the downstream integrations.

Step 4 — Integration testing

For each downstream system, verify that withdrawal in the CMP produces the correct outcome in the downstream system within the required time window. Test with synthetic contacts before go-live.

Step 5 — Existing data remediation

For contacts already in your database, determine their lawful basis. Contacts with no basis for processing must not receive marketing. Contacts with documented consent from before the CMP implementation should be migrated where the historical record is adequate.

Step 6 — Ongoing: reconsent cycles

When the privacy notice changes materially, identify the affected contact population and execute a reconsent programme. The channels available for outreach are only those for which you already have valid consent.