A New Category of Intermediary
The Digital Personal Data Protection Act creates something India's privacy landscape has never had before: a registered, licensed intermediary whose sole function is to help Data Principals manage their consent across multiple Data Fiduciaries from a single interface.
The Consent Manager as defined in the Act is not a CMP vendor. It is not a compliance tool. It is a regulated entity, accountable to the Data Protection Board of India (DPBI), with specific obligations around neutrality, interoperability, and Data Principal access.
A registered CM must enable the Data Principal, not the Data Fiduciary, to give, manage, review, and withdraw consent across multiple platforms from a single interface. The law's initial framing envisioned Data Principals selecting and paying for their own CM. In practice, the architecture is evolving differently: Data Fiduciaries will appoint registered CMs, but those CMs are licensed to act with structural neutrality toward the Data Principal. That separation of appointment from allegiance is what makes the model work. A CM cannot be an agent of the Data Fiduciary whose consents it manages.
Why This Matters Before Registration Opens
The DPBI has not yet opened registration for Consent Managers. But the obligations it will create for Data Fiduciaries exist in the Act now. Every organisation processing personal data under consent needs to understand what a registered CM entering their ecosystem will require of them, not just what it means for the CM itself.
What Changes for Your Business When a CM Goes Live
This is where organisations that have not thought this through will be caught flat-footed.
The first and most foundational change is internal governance. Right now, most organisations process data without a real-time check against current consent state. Data flows from collection into storage and then into processing pipelines, and consent is validated once at collection, not continuously. A registered CM changes the stakes on this. When consent can be withdrawn through an external intermediary at any time and must take effect promptly under Section 6(4), internal pipelines cannot operate on stale consent snapshots. The answer is an internal governance layer: APIs tagged to purpose, checked against a machine-readable consent record before processing executes. Not a consent log. A live consent gate. The difference is that tagging your processing APIs to a purpose list drawn from machine-readable consent means the system decides in real time whether to act, not whether to log.
The second change is external addressability. Under Section 6(4), a Data Fiduciary must honour a withdrawal of consent communicated through a Consent Manager. That instruction arrives from the CM acting on the Data Principal's behalf. Your consent architecture needs to receive, parse, and action a withdrawal from an external intermediary system, not just from your own preference center. A CM cannot push withdrawal instructions into a system with no integration surface. Your Rights Center API needs to be externally reachable.
The third change is vendor contract clarity. If your CMP handles consent processing and a withdrawal comes in via a registered CM, who is responsible for ensuring it propagates downstream within the window required by law? If your contracts do not answer that, you have a compliance gap today.
Your internal audit logs also need to distinguish between consent given directly and consent managed through a CM, because provenance matters for demonstrating compliance to the DPBI.
None of these are expensive changes. All of them require deliberate architecture decisions now, not after registration opens.
What Changes for Data Principals
From the Data Principal's perspective, a registered CM is genuinely useful. Instead of managing consent preferences on every app and platform separately, each with its own login and preference center, they get a single interface to see every consent they have given and withdraw it.
One important clarification on how this works in practice: each Data Fiduciary relationship remains separate. A Data Principal does not group all their consents together and withdraw from everything at once. They see their consents organised by Data Fiduciary, and each withdrawal is directed at a specific entity. The CM provides the unified view; it does not collapse the underlying legal relationships into one. Every Data Fiduciary is still treated as a distinct party with its own consent record.
This is still transformative compared to the current state, where exercising rights requires navigating each organisation's preference center individually. But the CM is an aggregated view and withdrawal channel, not a single switch that controls all consents simultaneously.
What Your Readiness Checklist Should Actually Look Like
Before a registered CM enters your consent flow through a Data Principal interaction, work through three things.
First, assess your internal governance layer. Can your processing systems check against current consent state in real time, not just at collection? If consent withdrawal from an external CM cannot reach your processing APIs and halt the relevant operations, that is the dependency to resolve first. Map your processing workflows to the consent purposes they rely on, and determine whether those links are machine-readable and actionable.
Second, review your vendor contracts. Consent propagation obligations should be explicit in every contract with a data processor. Do not leave it to inference whether your CMP, your analytics vendor, or your outsourced processing partners are obligated to act on withdrawal instructions that arrive from a CM rather than directly from the Data Principal.
Third, audit your integration surface. Which of your Data Principal-facing flows currently rely on your own preference center for rights management? Those flows need to be assessed for interoperability with an external CM. If your Rights Center has no API, that is a structural gap.
The DPBI's registration framework will formalise obligations for CMs. The obligations for Data Fiduciaries follow directly from what the Act already says. Get the architecture right now.