Consent Managers & DPDP Rules 2025: Strategy FAQs for India

Rainmaker March 28, 2026 Data Protection & Privacy, Featured 4 min read

The Digital Personal Data Protection Act, 2023 (DPDP Act) and the Digital Personal Data Protection Rules, 2025 (DPDP Rules) have fundamentally shifted where consent lives in India. Until now, most organisations treated consent as something they designed, captured, and controlled entirely within their own systems.

Under the DPDP framework, that control increasingly moves outward—towards interoperable consent architectures and a new, regulated intermediary: the Consent Manager (CM).

This FAQ unpacks what CMs are, why they matter, and how they fit into real-world Indian organisational and operational realities.

What problem are CMs trying to solve?

In India today, users’ consents are scattered across dozens of apps and services—each with its own notices, toggles, and withdrawal processes. In practice, withdrawing consent is often slow, fragmented, or confusing. As a result, users frequently exit a service altogether instead of meaningfully exercising their rights.

The DPDP Act treats this not merely as a user-experience gap, but as a structural infrastructure problem. Consent is meant to be standardised, portable, and easy to grant or withdraw—across organisations, not just within them.

CMs are the mechanism through which this shift is intended to operate.

What is a CM under the DPDP framework?

Under the DPDP Act and the DPDP Rules, a CM is a third‑party entity registered with the Data Protection Board of India (DPBI) that acts as a single point of contact for Data Principals to give, manage, review, and withdraw consent across one or more Data Fiduciaries.

At a minimum, a CM must:

be a company incorporated in India with at least a prescribed net worth of INR 2 crore;
offer an accessible platform where individuals can:

See which organisations hold active consents;
View the purposes, duration, and scope of those consents.
Modify or withdraw consent at any time;

operate with minimal exposure to personal data;
maintain detailed consent logs for at least seven years;
provide interoperable technical interfaces in line with the standards prescribed; and
support independent audits and robust governance.

How is a CM different from an internal Consent Management System (CMS)?

Many organisations already have some form of CMS. Under the DPDP Act, it helps to distinguish clearly between the two:

CMS: Your internal system that:

Captures consents at each touchpoint.
Stores consent artefacts (purpose, timestamp, notice version, channel, user ID).
Sends updates to downstream systems and processors when consent is given, modified, or withdrawn.

Not a regulated entity in itself, but central to your DPDP Act compliance story.

CM: A DPBI registered intermediary providing a cross‑organisation dashboard for individuals and governed by explicit obligations under the DPDP Act.

Is using a CM mandatory for organisations?

Section 6(7) of the DPDP Act allows Data Principals to give, manage, or withdraw consent either directly with a Data Fiduciary or through a CM. There is no blanket obligation on every organisation to use a CM.

In practice, this means organisations have three broad options:

Manage consent entirely in‑house, using their own CMS.
Integrate with one or more registered CMs for some or all products.
Use a hybrid model: strong internal CMS plus a CM for specific journeys or segments.

However, choosing not to use a CM does not lower the DPDP Act bar. Every organisation’s internal system must still meet DPDP standards on consent: valid, granular consent, easy withdrawal, verifiable logs, and interoperability where relevant.

What boundaries will CMs be expected to respect?

Under the DPDP framework, CMs are positioned to be neutral, fiduciary‑style intermediaries that act in the best interests of Data Principals, maintain strong security, and support transparent, auditable consent flows. The law does not yet set out a long, itemised prohibited activities list, but a CM that uses its position to weaken user control or commercially exploit consent data is likely to be seen as breaching those duties and inviting regulatory scrutiny.

In practical terms, this means three clear boundaries:

Use consent data only to run the service: Consent information should be used to show people their consents, transmit their instructions to Data Fiduciaries, and keep audit logs—not to build marketing segments, sell behavioural insights, or create new profiling datasets.
Design for user agency, not nudging: Dashboards and flows should make it genuinely easy to see who has access, say yes or no purpose‑wise, and change one’s mind later.
Handle conflicts of interest carefully: Commercial arrangements with Data Fiduciaries must not result in slower withdrawals, preferential treatment, or biased presentation of options.

Regulators are likely to look at whether all consents and withdrawals are treated consistently, promptly, and fairly from the individual’s point of view.

Put simply, a CM is supposed to be a trusted control panel for individuals—not another marketing or analytics channel.

Wrapping Up

CMs are one part of a bigger story: the DPDP Act is shifting Indian consent from static pop‑ups to living, revocable controls.

Practically, companies have an 18‑month runway to decide and implement their CM strategy: the CM is meant to be live around the 12‑month mark, and full consent‑regime obligations bite by May 2027, when the DPDP Act and DPDP Rules are fully operational.

Suggested Reading