Consent Managers Under the DPDP Act: What They Are and Who Needs One

The DPDP Act introduces an institution with no equivalent in GDPR: the Consent Manager. It is India's attempt to solve a problem every privacy regime struggles with — consent that is technically valid but practically unmanageable, scattered across hundreds of organisations with no way for an individual to see or control it in one place.

What a Consent Manager is

The Act 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 consent — through an accessible, transparent and interoperable platform.

Two features define the model. First, the Consent Manager is accountable to the data principal, not to the fiduciary — a deliberate inversion of the usual commercial relationship. Second, it is a conduit, not a custodian: the design intent is that the Consent Manager manages consent artefacts and permissions, not the personal data itself.

If this pattern feels familiar, it is: India has run it before with Account Aggregators in financial services, where a regulated intermediary lets a customer authorise data sharing between institutions from one interface. The Consent Manager generalises that idea across every sector.

Who must register, and how

Consent Managers must register with the Board and satisfy prescribed conditions — including requirements around being an Indian company, minimum net worth, technical and operational capacity to maintain interoperable platforms, certified security controls, and fit-and-proper standards for management. Registration opens as part of the phased Rules rollout, with the framework becoming operational ahead of full enforcement in May 2027.

Once registered, a Consent Manager's obligations include maintaining records of consents given, denied and withdrawn along with the notices served; enabling the principal to review and withdraw consent as easily as it was given; making those records available to the principal; not reading or using the personal data flowing through it beyond what is necessary; and avoiding conflicts of interest with the fiduciaries it serves.

What this means if you are a Data Fiduciary

Three points of practical clarity:

• You are not required to become a Consent Manager. This is a distinct, licensed role — most organisations will never register.
• You are not required to use one either. Fiduciaries may continue to obtain consent directly, provided it meets every validity requirement in the Act. The Consent Manager route is an additional channel through which a principal may exercise consent, not a mandatory intermediary.
• But you must be able to receive and act on consent from one. If a data principal chooses to manage their consent through a registered Consent Manager, your systems need to accept a consent artefact from that platform, honour a withdrawal signal that arrives through it, and keep your own records aligned. That is an integration requirement on your roadmap.

Preparing your consent architecture

Whether or not Consent Managers become widely used in your sector, designing for them makes your own consent estate stronger. The prerequisites are the same ones the Act already demands:

1. Purpose-level granularity. Consent must be recorded per purpose, not per user. A single "accepted terms" flag cannot be reconciled with an external platform — or defended before the Board.
2. Machine-readable consent records. Who consented, when, to which purposes, against which notice version, and every subsequent change. Interoperability starts with structured records.
3. Withdrawal that propagates. A withdrawal signal — from your own interface or a Consent Manager — must stop processing across your systems and your processors, not just flip a flag in the CRM.
4. Versioned notices. Retain the exact notice text served with each consent, so any record can be reconstructed years later.
5. API-ready design. Assume consent will eventually arrive and depart over an interface rather than a web form.

Organisations running consent through a purpose-built platform get these properties by default. Those managing consent through form submissions and spreadsheets will need to rebuild — which is a strong argument for fixing consent architecture now rather than after the framework goes live. See how Privonta Shield's consent module structures notices, per-purpose records and propagated withdrawal.

What the Consent Manager model is trying to fix

Consider an ordinary Indian adult in 2026. They have given consent to a bank, three lenders, two insurers, a hospital chain, four e-commerce platforms, a telecom operator, a school, and perhaps sixty apps. Each consent sits in a different organisation's database, described in different language, withdrawable through a different mechanism — if at all. In theory they hold rights over all of it. In practice they cannot even enumerate it.

Every privacy regime hits this wall. GDPR's answer was stronger individual rights and hope that organisations would build good interfaces. India's answer is structural: create a licensed intermediary whose entire purpose is giving the individual one place to see and control consent, and make it accountable to the individual rather than to the businesses paying for the plumbing.

Lessons from Account Aggregators

India has already run this experiment in financial services, and the pattern is instructive. Account Aggregators were introduced with a similar promise: a regulated, consent-driven conduit letting customers authorise data sharing between institutions. Three lessons carry over:

• Adoption follows the largest players. The framework became meaningful only when major institutions integrated. Expect the same here — Consent Manager relevance in your sector will be driven by whether its biggest fiduciaries connect.
• Standardised consent artefacts are the hard part. Interoperability requires agreement on how a consent is represented — purpose, scope, duration, revocation. Organisations whose consent is a boolean flag cannot participate.
• The conduit principle needs enforcing. Value capture pressure pushes intermediaries toward touching data they were meant only to route. Watch for how the Board polices this.

Should you become a Consent Manager?

For the overwhelming majority of organisations, no. Registration involves prescribed conditions around Indian incorporation, net worth, technical and security capability, interoperable platform obligations, and fit-and-proper management standards — and it comes with duties owed to data principals rather than to your business. It is a regulated financial-infrastructure-style undertaking, not a feature.

The realistic exceptions are organisations already operating identity, consent or data-exchange infrastructure at scale, and those whose core business is precisely this intermediation. If that describes you, the strategic question is whether your existing trust position and integration footprint justify the compliance burden.

Your actual to-do list

For everyone else, the Consent Manager framework generates exactly one work item: make sure your consent architecture can interoperate. Concretely — record consent per purpose with structured, machine-readable attributes; retain versioned notice text against each consent; expose withdrawal as a signal your systems and processors consume rather than a flag someone reads; and design the consent lifecycle assuming it may one day be driven over an API by a platform you don't control. Every one of those is already required for validity under the Act. The framework simply removes the option of doing it loosely.

Frequently asked questions

Privonta Shield helps Companies, Government, SMEs and Education Institutes meet every DPDP obligation — data discovery, consent management, rights workflows and audit trails, deployed inside your own boundary. Book a free DPDP assessment →