Policy

    One Licence, No Middlemen: Why India Does Not Need CMPs Beside Consent Managers

    The industry has settled on a neat split: the Consent Manager serves the Data Principal, and a CMP serves the Data Fiduciary. I think it is wrong. India built one consent intermediary on purpose. Here is why the unlicensed CMP layer adds risk without adding value.

    By Yuvaraj R
    8 min read

    The consensus is convenient, not correct

    On 13 November 2026, India starts registering Consent Managers. Ahead of that date, the industry has settled on a neat split: the Consent Manager serves the Data Principal, and a Consent Management Platform (CMP) serves the Data Fiduciary. Law-firm notes repeat it. Global vendors repeat it. It is fast becoming received wisdom.

    I think it is wrong. The DPDP Act built one consent intermediary, not two. A fiduciary should run consent either in-house or through a licensed Consent Manager. An unlicensed CMP layer in between does not help anyone except the vendor. For the fiduciary, it adds risk.

    India built one intermediary, on purpose

    The Act names exactly one consent intermediary. Section 2(g) defines the Consent Manager. Section 6(7) to 6(9) says it acts on the Data Principal's behalf, is accountable to her, and must register with the Data Protection Board. The words "Consent Management Platform" appear nowhere in the Act or the 2025 Rules.

    That was a deliberate choice. GDPR and CCPA left consent to businesses and their tools, which is how Europe ended up with cookie banners on every page. India did the opposite. It made the consent intermediary a regulated entity with a statutory duty to the person whose data is at stake.

    The First Schedule makes that duty concrete: an Indian company, ₹2 crore net worth, independent directors, no financial ties to fiduciaries, no ability to read the data it handles, no subcontracting, seven-year records, and Board audit. ELP's recent note puts it well: the Consent Manager "has no such buffer and is directly and independently liable under the statute."

    Why the CMP layer is being sold

    The licence is demanding, and that is the point. It is also why so many vendors would rather not hold one.

    The workaround is to call yourself a CMP that "integrates with" Consent Managers. You sit between the fiduciary and the licensed entity. You capture notices, store consent records and relay withdrawals. You do intermediary work without the net-worth bar, the independence test, the data-blindness rule or the Board audit.

    The framing also suits global vendors. They already sell CMPs built for GDPR. Calling the Consent Manager something separate lets them sell the same product into India and position the licence as someone else's problem. Most explainers on this topic are written by companies selling exactly that product.

    The fiduciary carries the risk the CMP avoids

    Under Section 8(1), the fiduciary is responsible for every processor it uses. Liability does not move down the chain. Penalties for security failures run up to ₹250 crore.

    So picture the chain a CMP creates. A third party holds the consent records your whole processing depends on. It owes no duty to the Data Principal. It is not audited to the Consent Manager standard. If it loses records, delays a withdrawal or mislabels a purpose, the fiduciary answers for it. The CMP answers only under a commercial contract, usually with a liability cap.

    A licensed Consent Manager is directly liable to the Board. A CMP shelters behind the fiduciary. That is not a neutral design difference. It moves regulatory risk from the vendor to the client.

    Who pays is not who is owed

    The usual objection is that a Consent Manager paid by the fiduciary cannot be independent. India already answers that in two places.

    Account Aggregators. Lenders integrate with and largely pay the AA. The AA's duty still runs to the customer, and it cannot see the data it moves.

    Statutory auditors. The company pays the auditor. The auditor's duty comes from statute, not the engagement letter.

    The Consent Manager works the same way. The fiduciary can select and pay a licensed Consent Manager. The duty to the Data Principal comes from the licence and Section 6(8), not the invoice. Independence is protected by structure: the conflict-of-interest bar, data-blindness, direct liability, Board audit, and the Data Principal's ability to move to another Consent Manager.

    A CMP has none of that. Its only duty is contractual, and it runs to the fiduciary. If anyone has an independence problem, it is the CMP.

    Germany shows how the two-layer model ends

    Germany has already run this experiment. Its Consent Management Ordinance under §26 TDDDG took effect in April 2025. It created officially recognised consent-management services that act for users, much like India's Consent Manager.

    The catch: websites are not required to use them. They can keep their own banners and CMPs. A year and a half on, the federal data protection authority (BfDI) has recognised one service, Consenter, on 17 October 2025. It launched in January 2026. Coverage remains low, and German commentators expect most sites not to change.

    That is the two-layer model in practice. When a user-side intermediary sits next to fiduciary-side CMPs, the CMPs keep the traffic and the intermediary starves. If India lets CMPs become the default, its licensed Consent Managers will go the same way.

    Two routes, no middle layer

    This is not a call to centralise consent. Fifty licensed Consent Managers would be healthy competition. What should not exist is an unlicensed layer doing intermediary work.

    A fiduciary should have two routes:

    1. In-house. It runs notice, consent capture, records and withdrawal on its own infrastructure, using software it controls. It is directly answerable for all of it.
    2. A licensed Consent Manager. It selects and pays a registered Consent Manager that owes its duty to the Data Principal.

    The test between the two is simple. If a vendor hosts or controls consent records, or relays consent actions between parties, it is acting as an intermediary and should be licensed. If it only supplies software the fiduciary runs itself, it is a tool, and the fiduciary is in-house.

    With registration opening on 13 November, three things from MeitY and the Board would settle this:

    • Clarify that hosting consent records or relaying consent for fiduciaries is Consent Manager activity.
    • Publish interoperability standards, so connecting to a Consent Manager is no harder than buying a CMP.
    • Confirm that a fiduciary may select and pay a Consent Manager without breaching the independence conditions.

    One licence is the point

    India's privacy law did something no other major regime did: it made the consent intermediary a licensed fiduciary of the individual. Letting an unlicensed layer grow around it would quietly bring back what the licence was designed to remove. Fiduciaries would pay for that in risk, and Data Principals in protection.

    The choice should stay simple. Do it yourself, or use a licensed Consent Manager. Nothing in between.

    Yuvaraj R is Founder and CEO of truConsent, a DPDP-native privacy infrastructure company incubated at IIT Madras Incubation Cell.

    Sources

    truConsent is India's DPDPA-native Consent Manager, purpose-built for the Digital Personal Data Protection Act 2023. Book a demo to see how we manage the full consent lifecycle.

    Continue Reading