One of the more distinctive features of India’s data protection regime is the Consent Manager — a registered intermediary that gives individuals a single place to grant, review, manage and withdraw consent across the services they use. It is an unusual idea, and one that most other privacy laws around the world do not have. As the framework becomes operational, every Data Fiduciary needs to understand what a Consent Manager is, how it will work, and how to prepare their own systems to interoperate with it.
The problem Consent Managers try to solve
Consent, as most people experience it online, is broken. It is collected once, in a rush, through a banner nobody reads, and then effectively forgotten. Withdrawing it means hunting through obscure settings pages, service by service, if it is possible at all. The result is “consent” that is technically obtained but practically meaningless. The Consent Manager is India’s structural answer to that problem: a way to make consent an ongoing, manageable relationship rather than a one-time checkbox.
What a Consent Manager does
Think of it as a consent dashboard that sits between individuals and the organisations using their data. Through it, a Data Principal can see who holds consent, for what purpose, and switch it off as easily as they switched it on. Instead of navigating dozens of separate privacy settings across dozens of services, an individual gets one interoperable, accountable layer for managing consent. The intent is to make consent genuinely meaningful in practice — visible, portable and revocable — rather than a formality collected and buried.
Who can be one
Consent Managers are not something any business can simply declare itself to be. They must be registered with the Data Protection Board and meet eligibility conditions — incorporation in India and a defined minimum net worth among them — together with technical requirements for managing the consent lifecycle and maintaining records reliably. Registration is a specific, time-bound process, and once the window closes, unregistered entities cannot operate in the role. Organisations that see Consent Manager registration as a strategic opportunity — and it is a genuine new market — should track those dates closely. Everyone else will simply be a user of the ecosystem.
What it means for Data Fiduciaries
The great majority of organisations will be users of Consent Managers, not operators, and for them the practical implications come down to three things:
- Interoperability. Your consent architecture and APIs will need to work with registered Consent Managers. That means consent state has to be something your systems can read and update through an interface — not a value buried in a database that only a developer can change.
- Clean, demonstrable records. You must be able to honour consent, and its withdrawal, in a way that is logged and demonstrable. If a regulator or an individual asks, you should be able to show exactly what was consented to, for what purpose, and when — and when it was withdrawn.
- Purpose fidelity. Consent under the DPDPA is purpose-specific, so your systems must tie each processing activity back to a valid, current consent for that exact purpose. Blanket consent that covers everything is precisely what the model is designed to end.
The Consent Manager provisions are being brought into effect on their own timeline within the DPDP roll-out. Confirm the current registration and go-live dates against the official notifications before you plan around them.
How to prepare now
Even before the ecosystem is fully live, there is valuable groundwork you can do that pays off regardless of exactly how the Consent Manager framework matures:
- Map your consent points. Find every place you collect consent today — web forms, mobile apps, call centres, partner integrations, offline channels — and record what each one is actually for.
- Standardise the record. Capture consent and withdrawal in a consistent, timestamped, purpose-linked format across all those channels, so your consent data is coherent rather than scattered.
- Design for interoperability. Treat consent as a managed signal your systems can query and update through an interface, so that integrating with a Consent Manager becomes a connection exercise rather than a rebuild.
- Fix the plumbing behind withdrawal. Make sure that when consent is withdrawn, your downstream systems actually stop the relevant processing — the hardest part is often not recording the withdrawal but acting on it everywhere.
The takeaway
Organisations that treat consent as a first-class, auditable signal — rather than a one-time checkbox — will integrate with Consent Managers with far less friction when the time comes. And the work is not wasted effort waiting on someone else’s framework: cleaning up how consent is collected, recorded and honoured is core DPDPA compliance in its own right. The Consent Manager transition simply rewards the organisations that did it properly.