What Is a Consent Manager Under DPDP? Definition and Requirements

A consent manager under India's DPDP Act is a data fiduciary that enables data principals to give, manage, review, and withdraw their consent to a data fiduciary through a single, transparent, and interoperable platform. It is a distinct legal role created by the Act, and registration for consent managers opens in November 2026.

The concept is India's attempt to solve one of the GDPR era's biggest failures: consent is fragmented across every website you visit, and nobody can manage it from one place. The consent manager is meant to be that one place. This post explains the role, the rules, and what it means for companies that collect consent.

What the Act says

The DPDP Act defines a consent manager as "a person registered with the Data Protection Board, who acts as a single point of contact to enable a data principal to give, manage, review, and withdraw her consent to a data fiduciary through an accessible, transparent and interoperable platform."

Three words in that definition do the heavy lifting:

• Accessible. The platform must be usable by data principals, including people who are not technical
• Transparent. The principal must be able to see what they consented to and who holds their data
• Interoperable. The platform must work across fiduciaries, not trap consent inside one company's ecosystem

The consent manager is itself a fiduciary, which means it carries fiduciary obligations under the Act, including security safeguards and the duty not to process personal data beyond what is needed for its role.

Why India built this role

Under GDPR, consent is managed per-site: every publisher has its own banner, its own record, its own withdrawal flow. The result is consent fatigue and a fragmented record. If a European user wants to withdraw consent from fifty companies, they visit fifty preference centres.

The DPDP Act tries to avoid that with a standardised middle layer. A data principal registers with a consent manager once, and that manager becomes the channel through which they can see and control consent across every fiduciary that uses the ecosystem. In principle, withdrawal becomes one action instead of fifty.

The timeline

Consent manager registration opens November 13, 2026, under the phased rollout of the DPDP Rules. That date matters for two audiences:

• Companies building consent infrastructure should understand the ecosystem they may need to interoperate with
• Fiduciaries should know that the consent-manager channel is a future path for withdrawal, which their consent records need to be ready for

The intervening year, 2026, is when the ecosystem gets built and when the Data Protection Board's registration criteria take shape.

What consent managers mean for product companies

If you are a company collecting consent under DPDP, the consent manager ecosystem affects you in three ways:

1. Withdrawal parity gets a new channel. When a user withdraws through a consent manager, the fiduciary must honour it. Your consent infrastructure needs to be able to receive withdrawal signals from outside your own UI.

2. Interoperability is a design constraint. Your consent records should be structured so they can be reconciled with a consent manager's record of the same user's choices. Proprietary, opaque record formats will be a liability.

3. You remain responsible. Using a consent manager does not outsource your fiduciary obligations. The obligation to collect valid consent, provide notice, and honour withdrawal stays with the fiduciary; the consent manager is a channel, not a shield.

Consent manager vs CMP: know the difference

These get confused constantly. A consent management platform (CMP) is the software a fiduciary uses to collect consent on its own property. A consent manager under DPDP is a regulated intermediary that holds consent on behalf of data principals across fiduciaries.

| | CMP (fiduciary tool) | Consent Manager (DPDP role) | |--|----------------------|------------------------------| | Who uses it | The company collecting consent | Data principals, across companies | | Legal role | Tooling, not a statutory role | Registered fiduciary under the Act | | Scope | One company's consent lifecycle | Cross-fiduciary consent management | | Registration | None | Data Protection Board registration |

A fiduciary will typically need both: a CMP to collect consent well, and the ability to interoperate with consent managers as the ecosystem matures.

What this means for your architecture

The pragmatic reading for product teams in 2026:

• Build consent records that are exportable and structured, not a blob in a database
• Design withdrawal to be receivable from multiple channels: your UI, your SDK, and future consent manager signals
• Keep purpose-level granularity, because a consent manager record is purpose-specific
• Do not wait for the ecosystem to be mature before getting your own consent house in order

None of this requires building a consent manager. It requires building consent infrastructure that could interoperate with one, which is a much cheaper design constraint.

How Erasure approaches consent

Accord, Erasure's consent product, is built for the fiduciary side: versioned notice, purpose-level configuration, immutable receipts, withdrawal parity, and HMAC-signed webhooks so backend systems react to consent changes. The record format is exportable and structured, which is the right posture for a world where consent managers will eventually want to talk to it.

The consent management guide covers the CMP category, and consent under DPDP breaks down the Section 6 conditions. The DPDP timeline has the November 2026 registration date in context.

The bottom line

The consent manager is the most structurally innovative part of the DPDP Act, and its registration window opens in November 2026. For most product companies it is not something to build; it is something to interoperate with. Build consent records that are structured, exportable, and purpose-specific, and you will be ready for the ecosystem when it arrives.