Most of India’s data protection statute will feel familiar to anyone who has worked with the GDPR. One part will not. The Consent Manager — a registered entity through which a Data Principal may give, manage, review and withdraw consent — has no direct analogue in any other major privacy regime, and it deserves more attention than it has had.
What the Act actually creates
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 their consent, through an accessible, transparent and interoperable platform. A Data Principal may give consent to a Data Fiduciary through a Consent Manager, and the Consent Manager is accountable to the Data Principal.
Read quickly, that sounds like a consent management platform of the kind vendors have been selling for years. It is not. A commercial consent management platform is a tool a company buys to manage its own consent capture; it acts for the fiduciary. A Consent Manager under the Act is registered with the regulator, owes duties to the individual, and sits between the individual and every fiduciary they deal with.
The intellectual lineage is not European. It is Indian, and it is financial: this is recognisably the Account Aggregator architecture, generalised from financial data to personal data at large. Anyone who has watched the Account Aggregator framework develop will recognise both the ambition and the implementation difficulties.
Why it matters commercially
Three consequences follow for organisations that process personal data at scale.
Consent stops being yours to hold
If a meaningful share of your users routes their consent through a Consent Manager, the authoritative record of what they have agreed to no longer lives exclusively in your systems. You will need to be able to receive consent artefacts from an external party, act on withdrawal signals that originate outside your product, and reconcile the two against your own record when they disagree. That is an integration problem with a legal specification, and it is not one most Indian product architectures currently anticipate.
Withdrawal becomes easier, and therefore more frequent
The friction in withdrawing consent today is not legal, it is practical: people do not know where to go. A single interface across all the fiduciaries a person deals with removes precisely that friction. Organisations whose data practices depend on inertia should model what happens when withdrawal takes one tap in a place the user already visits.
This is, to be clear, the point of the provision rather than an unintended consequence. But it has planning implications: consent-dependent processing that cannot degrade gracefully — personalisation, certain analytics, some marketing infrastructure — needs a defined fallback state, and that state needs to be designed rather than discovered.
Interoperability will be a negotiation
“Interoperable” is doing considerable work in the statutory definition. Interoperability in practice will be settled through technical standards, registration conditions and, inevitably, the commercial terms on which Consent Managers and large Data Fiduciaries agree to connect. The organisations that engage early will shape terms that the rest will accept later.
A Consent Manager is not a vendor you select. It is a counterparty your users select, and you contract with the consequences.
What we advise clients to do now
- Separate the record from the interface. If your consent record is stored inside your web front end or inside a single vendor’s platform, you will not be able to accept an external consent artefact without re-architecting. Consent state belongs in a service of its own, with the interface as one of several possible writers to it.
- Design for withdrawal as a first-class event. Most systems treat consent as a flag set at signup. Treat it instead as an event stream: granted, modified, withdrawn, each with a source, a timestamp and a purpose. Everything downstream — suppression, deletion, audit — becomes tractable.
- Map purposes to a stable vocabulary. Interoperability requires that “marketing communications” means something consistent across parties. Organisations with forty purpose strings accumulated over a decade of product launches will need to rationalise them before they can be exchanged with anyone.
- Decide whether you want to be one. For some businesses — particularly in financial services, telecom and identity — registration as a Consent Manager is a strategic question rather than a compliance one. The obligations are significant and the accountability runs to the individual, but so does the position in the flow.
The honest caveat
Frameworks of this kind depend on adoption, and adoption is not guaranteed by notification. The Account Aggregator ecosystem took years to reach meaningful volume, and it had the advantage of a narrower domain and a highly regulated participant set. It is entirely possible that Consent Managers remain a marginal channel for several years.
Our view is that this does not change the advice, because everything in the list above is worth doing regardless. A consent record that is separable from the interface, an event-based model of consent state, and a rationalised purpose vocabulary are the foundations of a defensible DPDP programme whether or not a single Consent Manager ever connects to you. The framework is simply the clearest available argument for building them properly the first time.
Disclaimer
This note is published for general information only. It is not legal advice, it does not take account of your particular circumstances, and reading it does not create a lawyer-client relationship with Incept Legal. The law is stated as at the date of publication. Please take advice before acting.