Consent Management Platform Guide: What a CMP Actually Does

A consent management platform, or CMP, is software that collects, stores, and manages consent from users. In its simplest form it is the thing that shows a banner, records a choice, and lets users change that choice later. In its useful form it does more: versioned notice, per-purpose choices, immutable receipts, and hooks into your backend so that a consent change actually changes processing.

The category got its reputation from the GDPR cookie-banner boom in Europe. India's DPDP Act is now making CMPs relevant in a different way, because the law makes consent the primary basis for processing, not one of six legal bases. This guide covers what a CMP should do, where most of them fall short, and what the DPDP era changes.

What a CMP is supposed to do

At minimum, a CMP handles the lifecycle of consent:

1. Notice. Shows the user what is being collected, why, and by whom
2. Choice. Lets the user accept, reject, or customize per purpose
3. Record. Stores what the user chose, and what they were shown when they chose it
4. Withdrawal. Lets the user change or revoke their choice as easily as they made it
5. Enforcement. Tells the rest of the system what it is allowed to do

The fifth item is the one that separates tools from toys. If your banner records a rejection but your analytics script still loads, you do not have consent management, you have a banner with extra steps.

Where most CMPs fall short

The GDPR-era CMP market produced a lot of banner widgets with three problems:

• No proof. They record "accepted" but not what the user saw, so a year later you cannot reconstruct the choice. Under a regulator's question, that is a failure.
• No versioning. When you change your privacy configuration, the old records do not point at the old notice. Consent history becomes unreadable.
• No enforcement. The banner and the data pipeline are disconnected. Rejections do not propagate, webhooks do not exist, and "consent" is a UI state, not a system state.

The DPDP Rules, 2025 raise the bar on all three. Notice must be versioned and reconstructable. Consent must meet the five Section 6 conditions, which demands real per-purpose granularity. Withdrawal must be as easy as giving consent. A banner-only CMP cannot do any of this.

What DPDP changes about consent management

The DPDP Act makes consent the default ground for processing personal data, supplemented by a defined set of legitimate uses. For most consumer products that means:

• Every purpose that relies on consent needs its own, specific consent
• Pre-ticked boxes and bundled "accept everything" are out
• Withdrawal parity is a legal requirement, not a UX nicety
• You need to be able to demonstrate consent, which means records, not vibes
• The notice must be in English and the relevant Eighth Schedule Indian languages

A CMP for the Indian market therefore needs language support baked in, per-purpose toggles, and a withdrawal path that is genuinely as easy as the consent path.

What to look for in a CMP

When you evaluate consent infrastructure, work through this list:

| Requirement | Why it matters | |-------------|----------------| | Versioned configuration | You can show what a user saw at any point in time | | Immutable receipts | The record survives later configuration changes | | Per-purpose granularity | Separate consent for separate purposes, as the Rules require | | Withdrawal parity | Users can revoke as easily as they consented | | Backend enforcement | Consent changes propagate to your systems via webhooks | | Privacy-preserving records | Receipts do not store more personal data than needed | | Multi-language notice | English plus Eighth Schedule languages | | Export | You can produce a consent record when challenged |

The last point, export, is the one that gets skipped and the one that matters most under DPDP's evidence orientation. If you cannot produce a record, you cannot demonstrate consent, and demonstration is the entire game.

CMP vs privacy operations platform

A CMP is one piece of privacy operations. Consent tells you what a user allowed. It does not tell you where their data lives, it does not delete it, and it does not prove what happened to a deletion request.

The DPDP Act is broader than consent. It covers erasure rights, breach notification, security safeguards, and significant data fiduciary duties. That is why Erasure is built as a privacy operations platform with Accord for consent, Rights for deletion requests, Data Maps and Systems for knowing and acting on where data lives, and Evidence for proof.

The consent piece is where most companies should start, because it is the highest-frequency interaction and the most fixable. Our consent under DPDP post covers the Section 6 requirements in depth, and the consent receipts post explains why the record matters more than the banner.

The bottom line

A consent management platform is table stakes under DPDP, but only if it does the full job: notice, per-purpose choice, immutable records, withdrawal parity, and backend enforcement. The banner market's weakest products fail on proof and enforcement, which are exactly the parts the Indian regime cares about.

If you are evaluating tools, test the record, not the banner. Ask for the receipt format, the versioning model, and the webhook story before you look at the styling. The product docs show how Accord approaches it, and pricing starts at ₹0 for the free tier.