DPDP consent managers explained: what they mean for your business

The DPDP Act created a role most companies have never had to think about: the consent manager. Rule 4 of the DPDP Rules, which governs how they register and operate, takes effect on 13 November 2026.

Consent managers won't change what you're legally required to do on 13 November, but they will expose weak consent systems faster than any regulator could. If your consent records can't show what someone agreed to and when they withdrew it, a third party keeping its own records will make that obvious.

I'm working on DPDP consent design with companies now, and the hardest part is rarely the consent screen. It's making withdrawal stop the processing everywhere the data went.

What a consent manager is

Under the Act, a consent manager is a person registered with the Data Protection Board who acts as a single point of contact for a Data Principal, the person whose data it is, to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform. The consent manager is accountable to that person and acts on their behalf.

The model is familiar in India. RBI's Account Aggregator framework already lets people share financial data between institutions through a consent intermediary. Consent managers apply similar thinking to personal data in general.

Who can become one

The conditions sit in the First Schedule to the Rules. A consent manager must be a company incorporated in India, with sufficient technical, operational and financial capacity, and a net worth of at least ₹2 crore. It must act in a fiduciary capacity towards the people it serves, avoid conflicts of interest with the companies it shares data with, and keep records of consents given, denied or withdrawn for at least seven years.

What it means for you as a data fiduciary

Someone may give you consent through a consent manager instead of through your own app. They may also withdraw it there. Your systems need to accept that consent, record it against a specific purpose, and act on a withdrawal by stopping processing within a reasonable time, including at processors you've shared the data with.

Under the Act, withdrawing consent must be as easy as giving it. If you've ever built a sign up flow with one tick box and a withdrawal process that needs an email to support and three working days, you already know where you'd fail.

There's a quieter consequence too. Consent managers keep long records. If a dispute reaches the Board, there may be a third party record of exactly what a person agreed to and when they withdrew it. Your own records had better agree.

What to build

Consent records per purpose, not one bundled agreement: who, what purpose, which notice they saw, when, and how. A withdrawal path that triggers deletion or suppression in every system and processor that holds the data. An integration approach for consent managers once standards are published, which will likely come through Board guidance. And a notice under Rule 3 that names how people can withdraw and complain.

Think of consent as belonging to a purpose and the systems that purpose touches, so a withdrawal becomes a set of actions with owners rather than an email in a shared inbox.

Withdrawing consent should be as easy as giving it, and from now on someone outside your company may be keeping score.