.svg){kind=small}
.avif)
“We want to use a NeGD-empanelled Consent Manager.”
“A vendor told me that using an NeGD empanelled Consent Manager is mandatory”
- We have heard this repeatedly over the last few weeks.
Does the DPDP Act actually require companies to use NeGD empanelled consent managers?
What exactly is an NeGD empanelled consent manager?
In this 2-minute post we’ll demystify this - using the DPDP Act and DPDP Rules as our primary source.
Does the DPDP Act require companies to use NeGD empanelled consent managers?
No. Neither the DPDP Act nor the DPDP Rules nor any other notification make it mandatory to use NeGD empanelled consent managers.
In fact, the term “NeGD empanelled consent manager” is incorrect. There is no such thing as a NeGD empanelled consent manager under Indian law.
What is an NeGD empanelled consent manager? Everyone keeps talking about it
Again, to repeat, there is no such entity known as an NeGD empanelled consent manager. The concept of such an entity does not exist in India as of now.
If someone is telling you, with full confidence, that “Hey we are an NeGD empanelled consent manager” - ask them to show you where it says so and what this concept means. In official writing.
What does the DPDP Act actually say about Consent Managers?
The DPDP Act defines a Consent Manager as a consent management platform which is registered with the Data Protection Board.
In fact, if you notice - registered consent managers have to act on behalf of Data Principals - not on behalf of Data Fiduciaries.
Rule 4 of the DPDP Rules talks about registration and obligations of a Consent Manager.
Do any registered consent managers exist under the DPDP Rules?
No. There are currently zero registered consent managers in India. Rule 4 of the DPDP Rules will only come into effect after a year i.e. from 13 November 2026
How are companies managing DPDP-compliant consent today?
As noted, registered consent managers act on behalf of the Data Principal and not the Data Fiduciary. We are all waiting for clarity on how exactly the modalities of this will work.
But, the DPDP Act has already kicked in, and Data Fiduciaries must manage consent on their end in accordance with the law, including:
- Consent collection
- Consent storage as an artefact
- Consent withdrawal
- Data Deletion
- Data Discovery and Mapping
Data Fiduciaries are taking 2 approaches to achieve this:
- Third-party software companies building consent/DPDP platforms
- In-house consent platforms being built for self-use by organizations
Companies which participated in the NeGD “Code for Consent” Challenge are all companies that fall into the first bucket. They are not special entities under law. They are commercial entities who chose to take part in a competition.
What is the NeGD “Code for Consent” Challenge?
The NeGD launched a contest to create “Digital Public Infrastructure” (DPI) for consent management - with the ultimate aim of developing Open Source Code for use by small businesses and NGOs.
All participants in this challenge were third-party entities
Out of this, 6 have been shortlisted for Round 2 of the competition - based on a high fidelity prototype. Not a working product.
This has been mistaken for empanelment or registration under some “NeGD framework”. This is incorrect.
The only NeGD list right now is a list of participants in Round 2 of the competition. That’s it.
Participants that clear Round 2 will be empanelled right?
No. Even the participants that clear Round 2 will not become empanelled or authorized registered consent managers under the DPDP Act.
Participants who clear Round 2 will make it to a technical shortlist prepared by NeGD.
Making the technical shortlist means:
- Their code will be open sourced by NeGD for use by businesses and NGOs.
That’s it. NeGD Shortlisting is a competition which produces a public, open source code list. It is not a regulatory approval or authorization exercise.
I am a bit confused – there are a bunch of terms floating around - NeGD Shortlisted Entity, Consent Manager, Consent Platform - clarify for me
The table below clarifies the difference between making the NeGD Technical Shortlist and being a registered consent manager under the DPDP Act. And a Consent Platform
Shortlisting or participation in a government-led initiative is not the same as legal registration under the DPDP Act.
Why did Consentin not take part in NeGD “Code for Consent” Challenge?
We did not participate in the challenge because our product is a closed-source product and not an open source one. We believe that closed-source is the best way to keep security ownership and operational accountability clear.
However, we did participate in another capacity. Pushkal Dubey - Head of Consentin - was a judge on the NeGD “Code for Consent” panel. He played a role in preparing the shortlist of six.
Should I wait for consent managers to be registered? Should I use a consent platform? Should I use an NeGD shortlisted candidate?
NeGD shortlisted candidates are not separate entities compared to consent platforms. They are merely entities who chose to participate in a competition.
This means you have 2 options:
- Wait for a Registered Consent Manager to be notified by DPB
- Onboard a consent platform
Ok I how do I decide between these options?
It is important to note that Registered Consent Managers will not act on behalf of Data Fiduciaries. While we don’t know their final shape - the law clearly states that they are an entity that will act on behalf of the Data Principal.
This means it might not even be possible for Data Fiduciaries to empanel or onboard one specific registered consent manager. They will instead have to support all - because ultimately the Data Principal will choose.
We anticipate a similar framework to UPI or Account Aggregator - with a common interoperable protocol laid out by the DPB. However, the final form of this is unclear.
Ultimately, whatever this protocol is, registered consent managers will only:
- Allow Data Principals to manage consent
- Allow Data Principals to review consent
- Allow Data Principals to withdraw consent
However, Data Fiduciaries have other obligations:
- Allow Data Principals to manage consent
- Allow Data Principals to review consent
- Allow Data Principals to withdraw consent
- Ensure when consent is withdrawn - the accompanying data gets deleted
- Map data to ensure accuracy
- Send out breach notifications
- Manage third party vendor data risk
- Make available consent notices specifying what data is being collected
- Send out look-back notices for existing consent
- Collect cookie consent on website and web apps
So even if you as a Data Fiduciary wait for a Registered Consent Manager, you will only be able to achieve 3 of your obligations.
For achieving the rest of your DPDP obligations you will still need a Consent/DPDP Compliance Platform.
So I should not wait for a Registered Consent Manager?
Yes, you should onboard a Consent/DPDP Compliance Platform as soon as possible to meet the full range of your DPDP obligations.
A Registered Consent Manager, on its own, will not allow you to meet the full range of your obligations. At best, it will only allow you to meet some of them.
Of course, as we mentioned before, it may not even be possible to onboard a Registered Consent Manager as a Data Fiduciary - as it may work on an interoperable public protocol.
We wait for more clarity from MeitY and the Data Protection Board.
.avif)
.png)
