DPDP Consent Management: What Indian Companies Must Build

DPDP consent management is the part of the Digital Personal Data Protection Act (often shortened to DPDPA) that most companies start with, because it is the part customers can see. It is also where the most expensive misunderstanding sits. This guide separates what the law asks of your own organisation from what it asks of registered Consent Managers, then sets out what your consent system has to do before the obligations take effect.

Quick answer

Most Indian companies do not need to register as a Consent Manager. They need a consent management platform. These are different things, and confusing them is costing organisations time and money.

A Consent Manager is a registered intermediary under Section 2(g) of the DPDP Act — a regulated entity that gives individuals one dashboard to control data sharing across many organisations. Registration with the Data Protection Board opens 13 November 2026 and requires a company incorporated in India with a minimum net worth of ₹2 crore, independent certification of its platform, and ongoing accountability to the Board.

A consent management platform is software your organisation runs to capture, store and honour consent for your own processing. No registration. No net worth test.

If you are a bank, hospital, D2C brand or SaaS company processing your customers’ data, you need the second one. You will most likely never need the first.

Why this confusion is so expensive

Rule 4 of the DPDP Rules is long, detailed and intimidating. It reads like a compliance obligation because it is one — just not yours.

The requirements it sets out are genuinely demanding: an entity must satisfy the Board, up front and continuously, that it can operate a trusted, interoperable consent platform. It must be incorporated in India with adequate technical, operational and financial capacity, maintain a minimum net worth of ₹2 crore, and have directors and senior management with a reputation for fairness and integrity. Its memorandum and articles must hard-wire the conflict-of-interest and fiduciary duties prescribed for Consent Managers, amendable only with the Board’s prior approval. An independent certification must confirm the interoperable platform aligns with the Board’s data-protection standards.

That bar is set high deliberately. Consent Managers hold consent records for other people’s customers and are accountable to Data Principals directly, subject to Board inquiry for their own breaches.

Almost no operating business should be trying to clear it. Yet I keep seeing companies read Rule 4, conclude they need to register, and lose weeks to a question that was never theirs.

The test is simple. Are you managing consent for your own processing, or offering a neutral intermediary service where individuals manage consent across multiple unrelated organisations? First case: platform. Second case: registration.

Where the Consent Manager concept comes from

Worth understanding, because it explains why India’s model diverges from GDPR.

The concept traces to the 2017 Srikrishna Committee report and NITI Aayog’s 2020 Data Empowerment and Protection Architecture framework, and it is already operating in Indian finance through the Account Aggregator model.

GDPR relies on controllers and processors to manage consent flows themselves. US frameworks lean on opt-outs and do-not-sell registries. India built something different: a federated, interoperable ecosystem where individuals can centralise, review, modify and withdraw consent through trusted neutral intermediaries.

The closest analogue in your existing mental model is not a privacy tool. It is open banking.

For most organisations the practical implication is this: you will eventually interoperate with Consent Managers rather than become one. Your platform will need to accept and honour consent signals originating outside your own interface. Build with that in mind now — retrofitting it later is expensive.

What DPDP consent actually requires

This is where global consent tools break, because the Act’s requirements are stricter than a cookie banner assumes.

Consent must be free, specific, informed, unconditional and unambiguous. Bundled consent — one checkbox covering marketing, analytics and third-party sharing — fails “specific.” Consent conditioned on service access where the data is not necessary for that service fails “unconditional.”

Notice must comply with Rule 3. Clear, plain-language disclosure of what you collect and why, itemised. Not a link to a 4,000-word policy.

Notice must be available in Eighth Schedule languages. The Constitution lists 22. Most global consent platforms ship English and a handful of European languages. This is a genuine product gap, not a translation project you can bolt on later.

Withdrawal must be as easy as giving. If consent takes one tap and withdrawal takes a support ticket, that asymmetry is a finding. This single requirement invalidates more existing implementations than any other.

Consent must be verifiable, not implied. A Data Fiduciary must maintain a record of consent — timestamped, purpose-linked, provable.

Withdrawal must propagate. When someone withdraws, processing stops across every downstream system. A flag flipped in the consent tool while your CRM, warehouse and email platform carry on is not compliance.

That last point is where most implementations quietly fail. The consent UI works beautifully. The propagation does not exist.

When you do not need consent at all

Consent is not the only lawful basis. Section 7 of the Act lists “certain legitimate uses” where you can process without it. The ones most businesses rely on:

• Data a person gave you voluntarily for a specified purpose, where they have not said they object to that use
• Compliance with a law or a court order
• Medical emergencies and threats to life or health
• Employment purposes, such as payroll and protecting the employer from loss or liability

Two cautions. There is no general “legitimate interest” basis of the GDPR kind, so a broad claim of business need will not do. And a legitimate use has to be recorded against the processing activity just as carefully as consent, or you cannot show it when asked.

Children’s consent is a separate problem

For anyone under 18, Section 9 requires verifiable consent from a parent or lawful guardian, and it rules out tracking, behavioural monitoring and targeted advertising aimed at children. In practice that means an age signal at collection, a parental verification step, and a record that shows which parent consented and how they were verified. It also means a plan for the day the child turns 18, when the basis for processing has to be revisited.

What a consent management platform must do

Evaluating tools, these are the capabilities that separate real platforms from banners with a dashboard:

Purpose-level granularity. Consent recorded per purpose, not per user. One person may consent to service communications and refuse marketing — your record must hold both independently.

Multi-channel capture. Web, app, IVR, and in-person or agent-assisted onboarding. Most Indian customer acquisition is not purely digital, and a web-only tool cannot evidence consent collected over the phone.

Vernacular notice delivery. Eighth Schedule languages, with the delivered language recorded against each consent artefact.

Immutable consent artefacts. Timestamped, purpose-linked, tamper-evident. When the Board asks when consent was obtained and for what, the answer must be provable rather than asserted.

Withdrawal orchestration. APIs or connectors that push withdrawal to every downstream system, with confirmation logged.

Rights request integration. Consent records feed Data Principal rights fulfilment. A platform that cannot tell you which purposes a person consented to cannot help you answer their access request.

Consent Manager interoperability. APIs to accept consent originating from registered intermediaries. Not urgent today. Not optional after November 2026.

Purpose registry tied to your RoPA. Which brings us to the thing most organisations get backwards.

The sequencing mistake

Consent is the visible obligation. It has a user interface, it appears on your website, it feels like progress. So organisations buy consent tooling first, deploy it, then start mapping their data.

And discover the consent architecture rests on assumptions about data flows that were wrong.

You cannot collect purpose-specific consent for purposes you have not enumerated. You cannot propagate withdrawal to systems you have not mapped. You cannot set retention against consent you cannot link to a processing activity.

The order that works:

1. Discover where personal data actually lives — including the systems nobody mentioned at kickoff
2. Build a RoPA that reconciles against real systems, enumerating every purpose
3. Then design consent around what the register shows

ProtectComply runs that sequence — discovery into RoPA into DPIA, with each processing activity linked to its consent basis, so the purposes you collect consent for match the processing you actually do. A steward review queue means nothing enters the record unreviewed.

On the consent side, ProtectComply records consent per purpose, delivers notices in the 22 Eighth Schedule languages plus English, issues tamper-evident consent receipts aligned to ISO/IEC 27560, runs withdrawal across every record held for a person with escalation when it stalls, and handles parental consent with an age-out process. Its interface for registered Consent Managers follows the DEPA approach and is built against the draft specification, so expect it to change as the Board finalises the standard.

The timeline

13 November 2025 — DPDP Rules notified via gazette G.S.R. 846(E). Data Protection Board constituted.

13 November 2026 — Rule 4 commences. Consent Manager registration opens. If you are building an intermediary service, this is your date.

13 May 2027 — Rules 3 and 5–16 commence. Notice and consent obligations become enforceable for everyone. This is your date.

Consent re-architecture is not a quarter’s work if your current implementation is a bundled checkbox. Purpose separation, vernacular notices, withdrawal propagation and artefact storage each touch production systems.

Six questions for consent platform vendors

1. Show me a consent artefact export. Not the dashboard — the record you would hand the Board. Timestamp, purpose, language delivered, capture channel, withdrawal status.
2. Which Eighth Schedule languages are supported? Count them. “Multilingual” is not an answer.
3. When someone withdraws, trace the propagation. Name every system that updates and show me the confirmation log.
4. Can you capture consent over IVR or through an agent? If your onboarding is not purely digital, a web-only tool leaves your largest channel unevidenced.
5. How do purposes get into the platform? If they are typed in manually, they will drift from your actual processing within a quarter.
6. What is your Consent Manager interoperability roadmap? Post-November 2026 this stops being theoretical.

Pair these with our fuller DPDP compliance checklist.

Frequently asked questions

Do we need to register as a Consent Manager under the DPDP Act?

Almost certainly not. Registration applies to entities offering a neutral intermediary service where individuals manage consent across multiple unrelated organisations. If you are managing consent for your own processing, you need a consent management platform, not registration.

What is the minimum net worth for Consent Manager registration?

₹2 crore, under Part A of the First Schedule to the DPDP Rules, 2025 — alongside incorporation in India, independent platform certification, and governance requirements hard-wired into the memorandum and articles.

When does Consent Manager registration open?

13 November 2026, when Rule 4 commences.

What is the difference between a Consent Manager and a consent management platform?

A Consent Manager is a registered intermediary accountable to Data Principals and the Data Protection Board, giving individuals one interface across many organisations. A consent management platform is software an organisation runs for its own processing. Different legal status, different obligations, different buyers.

Is a cookie banner enough for DPDP consent compliance?

No. Cookie consent covers website tracking. The Act requires purpose-specific consent across every processing activity, notice in Eighth Schedule languages, withdrawal as easy as consent, verifiable records, and withdrawal propagating to downstream systems. A banner covers a fraction of that.

Can we reuse our GDPR consent implementation?

Partially, and the gaps are specific. There is no legitimate-interest basis under the DPDP Act, so processing you justified that way needs a fresh basis. Eighth Schedule language coverage has no GDPR equivalent. And withdrawal parity is stated more explicitly than under GDPR.

How long must consent records be retained?

Consent Managers must retain records for at least seven years from consent or withdrawal, whichever is later. Data Fiduciaries should retain consent artefacts for as long as they rely on that consent, plus a defensible period afterwards — you may need to evidence a basis for processing that has already ended.

Does consent need to be in the user’s language?

Notice must be available in English or any language in the Eighth Schedule, at the Data Principal’s option. Which means your platform needs to deliver — and record delivery of — notices across those languages.

Where to start

If your consent implementation is a bundled checkbox and a cookie banner, the gap is bigger than a tooling swap. Run a gap analysis to see which obligations you already meet, then map your data, then rebuild consent against the purposes your register actually shows.

See how ProtectComply links consent basis to real processing activities

How this article was researched

Written against the DPDP Act, 2023 and the DPDP Rules, 2025 as notified, with Rule 4 and First Schedule requirements checked against published legal analysis. Where the Rules are silent we say so rather than extrapolating.

Corrections: write to [corrections email] and we will review and update.

Sources

• Digital Personal Data Protection Rules, 2025 — gazette notification G.S.R. 846(E), 13 November 2025; Rule 3, Rule 4, First Schedule Part A
• The Digital Personal Data Protection Act, 2023 — Sections 2(g), 6(7)–6(9), 7
• NITI Aayog, Data Empowerment and Protection Architecture, 2020
• Committee of Experts under Justice B.N. Srikrishna, report of 2017

General information, not legal advice. Consult qualified counsel before finalising your compliance position.