DPDPA creates a new licensed intermediary for consent. Once one is actually registered, it reshapes consent architecture for every Data Fiduciary in the country — here's what to prepare before that happens.
July 2026 · 6 min read
The DPDPA creates something new to India's privacy landscape: a registered, licensed intermediary whose entire job is helping a Data Principal manage consent across multiple Data Fiduciaries from one place.
The Consent Manager, as the Act defines it, is not a CMP vendor and not a compliance tool you buy. It's a regulated entity, accountable to the Data Protection Board of India, with specific obligations around neutrality, interoperability, and giving Data Principals real access to their own consent record.
A registered CM has to let the Data Principal — not the Data Fiduciary — give, review, manage, and withdraw consent across multiple platforms from a single interface. The Act's original framing imagined Data Principals choosing and paying for their own CM. In practice, the architecture is settling differently: Data Fiduciaries will be the ones appointing registered CMs, but those CMs are licensed to remain structurally neutral toward the Data Principal regardless of who appointed them. That separation — appointment on one side, allegiance on the other — is what makes the whole model work. A CM can't be an agent of the Fiduciary whose consents it's managing.
The Data Protection Board hasn't opened Consent Manager registration yet. But the obligations a live CM will create for Data Fiduciaries already exist in the text of the Act. Every organisation processing data under consent needs to understand what a registered CM entering their ecosystem will demand of them — not just what it means for the CM itself.
This is where organisations that haven't thought it through will get caught flat-footed.
The first change is internal governance. Right now, most organisations process data with no real-time check against current consent state — consent gets validated once, at collection, and the data then flows into storage and processing pipelines from there. A registered CM raises the stakes on that gap. When consent can be withdrawn through an external intermediary at any moment and has to take effect promptly under Section 6(4), internal pipelines can't keep running on stale consent snapshots. What you need is an internal governance layer: processing APIs tagged to purpose, checked against a machine-readable consent record before they execute. Not a log you consult after the fact — a live gate the system checks in real time before acting, drawing from the same purpose list your consent record uses.
The second change is external addressability. Section 6(4) requires you to honour a withdrawal communicated through a Consent Manager, arriving on the Data Principal's behalf from a system that isn't yours. Your architecture needs to be able to receive, parse, and act on that instruction from an external system — a CM can't push a withdrawal into a platform with no integration surface to receive it. Your Rights Center needs an API that's actually externally reachable.
The third change is contractual clarity with your vendors. If your CMP handles consent processing today, and a withdrawal arrives via a registered CM tomorrow, who's responsible for making sure it propagates downstream within the legally required window? If your current contracts don't answer that, that's a gap sitting open right now, not something you can defer until a CM actually launches.
Your internal audit logs need one more adjustment: distinguishing consent given directly from consent managed through a CM, because provenance matters when you're demonstrating compliance to the Board.
None of this is expensive to build. All of it requires a deliberate architecture decision now, rather than a scramble once registration opens.
From the Data Principal's side, a registered CM is genuinely useful. Instead of managing consent separately on every app and platform they use — each with its own login and its own preference centre — they get one interface showing every consent they've given, and a single place to withdraw any of them.
One clarification worth being precise about: each Data Fiduciary relationship stays legally separate. A Data Principal doesn't bundle all their consents together and pull one lever to withdraw everything at once. They see consents organised by Fiduciary, and each withdrawal targets a specific entity. The CM gives them a unified view and a single withdrawal channel — it doesn't collapse the underlying legal relationships into one. Every Fiduciary remains its own distinct party with its own consent record.
That's still a meaningful improvement over today, where exercising your rights means navigating each organisation's own preference centre individually. It's an aggregated view, not a universal off-switch.
Before a registered CM enters your consent flow through any Data Principal interaction, work through three things.
Assess your internal governance layer. Can your processing systems check current consent state in real time, not just at the point of collection? If a withdrawal from an external CM can't reach your processing APIs and stop the relevant operation, that's the dependency to fix first. Map every processing workflow to the consent purpose it relies on, and confirm those links are machine-readable and actionable — not just documented in a policy somewhere.
Review your vendor contracts. Consent-propagation obligations should be spelled out explicitly in every contract with a data processor. Don't leave it to inference whether your CMP, analytics vendor, or outsourced processing partners are obligated to act on a withdrawal instruction arriving from a CM rather than directly from the Data Principal.
Audit your integration surface. Which of your Data Principal-facing flows currently depend on your own preference centre for rights management? Those need to be assessed for interoperability with an external CM. If your Rights Center has no API today, that's the structural gap to close first.
The Board's registration framework will formalise the obligations on CMs themselves. The obligations on Data Fiduciaries already follow from what the Act says today. The architecture work is worth doing now, not after the first CM goes live.
Getting your architecture ready for this ahead of time is exactly what our CMP evaluation service checks for.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation