DPDP consent managers: what a consent management platform can't do for you

There is a word in the DPDP Act that the market has quietly repurposed, and the gap between the two meanings is where a lot of compliance budget is about to be wasted.

Ask a vendor whether their product is a consent manager and the answer is yes. Ask whether their entity is a Consent Manager within the meaning of Section 2(g) of the Digital Personal Data Protection Act, 2023, and the answer is almost certainly no, because today, for anyone, it cannot be.

A Consent Manager is a licensed role, not a product category

Section 2(g) defines a Consent Manager as a person registered with the Data Protection Board who acts as a single point of contact enabling a data principal to give, manage, review and withdraw her consent, through an accessible, transparent and interoperable platform.

Read that definition carefully, because three things in it are doing work.

Registered with the Board. This is a status conferred by a regulator, not a claim a company can make about itself. It is closer in kind to being a registered intermediary than to being a SaaS category.

A single point of contact for the data principal. The orientation is towards the user, not the business. The Consent Manager exists so that a person can see and control what they have agreed to across the fiduciaries they deal with: one place, not one per company.

Interoperable. The regime anticipates consent moving between fiduciaries through a common layer. That is an ecosystem design, not a widget you drop into a checkout page.

None of this describes the thing most teams are procuring, which is a banner, a preference centre, and a log.

What Rule 4 actually asks of an applicant

The DPDP Rules, 2025 put numbers to it. Rule 4, read with the First Schedule, sets out registration and the conditions attached to it.

Part A covers eligibility. The applicant must be a company incorporated in India with a minimum net worth of ₹2 crore, evidenced by audited financial statements, alongside conditions on technical capability, governance and fitness. The incorporation requirement has a consequence that tends to surprise people: an offshore CMP vendor, including most of the well-known ones from the GDPR era, cannot register directly in its own name.

Part B covers what a registered Consent Manager must then do. The duties include maintaining records of consents given, withdrawals and the notices they related to; avoiding conflicts of interest with the fiduciaries whose consent it intermediates; and, most technically demanding of all, ensuring that personal data routed through its platform is not readable by the Consent Manager itself.

That last condition is worth pausing on, because it is an architectural constraint rather than a policy one. A platform that brokers consent while remaining blind to the data it brokers is a different system from one that keeps a copy for analytics. It is not a feature a vendor bolts on late.

And the timing matters: Rule 4 commences on 13 November 2026. Registration does not exist before then. Any sales deck presenting a registered Consent Manager today is describing something that has not yet been possible to become.

Whose side the Consent Manager is on

This is the part most often misread, and it changes the procurement question entirely.

Section 6(8) makes the Consent Manager accountable to the data principal, acting on her behalf. It is not your service provider in the way a processor is. Its duties run to the user whose consent it manages, and its conflict-of-interest obligations exist precisely to keep it from becoming an instrument of the fiduciaries it sits between.

So the transaction is not what a buyer usually assumes. Engaging a Consent Manager does not move an obligation off your books. You remain the data fiduciary. You still owe the notice under Section 5. You still need a lawful basis under Section 4: consent, or one of the legitimate uses in Section 7. You are still answerable for what you did with the data after consent was given, and for stopping when it is withdrawn.

A Consent Manager changes where the user goes to exercise control. It does not change who is responsible for the processing.

What still has to be true inside your own stack

Strip away the status question and there is a large amount of work that no external party performs for you.

The notice has to be right. Rule 3 requires a notice that stands on its own and itemises, in plain language, the personal data being collected and the specific purpose it is being processed for, described clearly enough that a person can act on it, together with how to withdraw and how to complain to the Board. A consent screen is only as valid as the notice it is attached to.

Consent has to be granular at the purpose level. Section 6(1) requires consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the stated purpose. One acceptance covering onboarding, marketing and analytics fails that test no matter how good the interface is.

Withdrawal has to propagate. Withdrawal must be as easy as giving consent, and when it happens you have to stop processing within a reasonable time, and so does anyone you passed the data to. This is a distributed-systems problem wearing a legal hat. If a withdrawal updates a preference table but not the warehouse, the CRM, the email platform and the vendor you syndicated to, you have recorded an intention rather than honoured a right.

You have to be able to reconstruct any single consent. For a given person on a given date: what were they shown, what did they affirmatively do, and against which version of the notice? If that cannot be produced on request, the records are decorative.

Four questions worth asking a vendor

Not about features. About status and architecture.

1. Are you applying to register as a Consent Manager under Rule 4, in your own name, as an India-incorporated company? If not, and there is no shame in not, say plainly that you are a tool the fiduciary uses, not a Consent Manager under the Act.
2. Can your platform operate without being able to read the personal data that passes through it? Part B makes this a condition of the role, and retrofitting it is close to a rewrite.
3. How does a withdrawal reach systems you do not control? Ask for the mechanism, not the roadmap.
4. What do you not cover? A vendor that cannot name the boundary of its own product is describing marketing, not architecture.

Where a tool stops and a legal position starts

Every question above assumes something already settled that usually is not: which of your processing activities require consent in the first place.

That is not a configuration setting. It is a judgement about each purpose you process for: whether it falls to consent under Section 4, or to one of the legitimate uses under Section 7; whether a purpose is genuinely necessary or merely convenient; whether your user base brings Section 9’s children’s-data obligations into play. Get that wrong and a perfectly implemented consent platform faithfully collects consent you did not need, while missing the basis you did.

No consent platform will make that call for you, and the honest ones do not pretend to. Their terms disclaim legal advice, which is both correct and a clear statement of where their responsibility ends.

This is the gap Sentinel by Vettam is built around. Sentinel maps the DPDP Act and Rules against your actual processing, produces the register that says which obligations apply and which are reasoned out of scope, and puts the legal positions in front of an independent lawyer for review and signature: attributed, dated, on their letterhead. What you implement in a consent platform afterwards is then implementing a decision someone qualified has actually made, rather than a default someone chose during a sprint.

If you are evaluating consent tooling before that groundwork exists, the sequence is backwards. An applicability assessment establishes what you are required to collect consent for, which is the specification the tooling should be bought against. For D2C and consumer platforms in particular, where consent volume is highest and the flows shipped fastest, that specification is usually the difference between a rollout and a rebuild.

Full compliance is required by 13 May 2027. Rule 4 opens on 13 November 2026. There is enough time to do this in the right order, and not much more than enough.

---

This article is general information about Indian data protection law and is not legal advice. Statutory references are to the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025; confirm the current text before relying on any provision. Sentinel is a product of Rylematic Technologies Private Limited; Vettam is a technology company and does not provide legal services. Legal opinions referenced on this site are issued by independent lawyers empanelled with Sentinel.