The Consent Manager is the most misread role in India's DPDP Rules. Vendors describe it as a mandatory integration, which it is not, and compliance teams confuse it with the cookie-consent platform they already license, which it also is not. Rule 4 creates a registered class of intermediaries and sets out what they owe. It does not oblige an ordinary Data Fiduciary to route consent through one.
It is also the one rule on the early clock, which is why it attracts attention disproportionate to what it actually requires of most companies.
What Is a Consent Manager?
A Consent Manager is a registered intermediary through which a Data Principal can give, manage, review and withdraw her consent. The defining features are that it acts for the individual rather than for any single fiduciary, and that it must be registered with the Data Protection Board.
Registration runs under rule 4, against the conditions in Part A of the First Schedule to the Rules. The role is a piece of market architecture: it creates a place where a person can see every consent she has granted across the services she uses, and revoke any of them from one surface, rather than visiting twenty privacy settings pages.
Rule 4 Does Not Require You to Use One
This is the load-bearing point, and it is worth being precise about. Rule 4 governs the registration and obligations of Consent Managers. Nothing in it compels a Data Fiduciary to obtain consent through a Consent Manager, and nothing in it makes consent captured directly by a fiduciary invalid.
Treat any vendor claim that DPDP mandates Consent Manager integration as a reason to check what else they have got wrong. The obligation rule 4 creates runs on the entities that choose to register as Consent Managers, not on the fiduciaries that might one day use them.
What is genuinely true is that a sector could converge on one, or a large customer could require it commercially. That is a plausible future to stay ready for, not a present duty.
Being told DPDP requires a Consent Manager integration?
Share your work email and we'll walk what rule 4 actually requires against what your consent capture and withdrawal already does, and what interoperability is worth building now.
The One Deadline That Runs Early
Rule 1 splits commencement into three tranches, and rule 4 sits alone in the middle one.
| Tranche | What commences | When |
|---|---|---|
| In force | Rules 1, 2 and 17 to 21 — definitions and the provisions constituting the Data Protection Board | 14 November 2025 |
| One year | Rule 4 — Consent Manager registration and obligations | Mid-November 2026 |
| Eighteen months | Rules 3 and 5 to 16, plus 22 and 23 — notice, consent, safeguards, breach, retention, children, SDF duties, rights, transfer | Mid-May 2027 |
The sequencing is deliberate: the registered class of Consent Managers has to exist before the operational duties that might rely on it. For an ordinary fiduciary, though, the date that matters is the eighteen-month one, because rule 3's notice and consent duties commence then. Building toward November 2026 because it is the nearer date is a common and expensive misread.
A Consent Manager Is Not a Consent Management Platform
The vocabulary collision causes real confusion, because the industry has used "consent management platform" for cookie banners for a decade.
| Consent Manager (rule 4) | Consent management platform | |
|---|---|---|
| Acts for | The Data Principal | The website operator |
| Registration | Required, with the Data Protection Board | None |
| Scope | Consents across many fiduciaries | One property or estate |
| Governed by | Rule 4 and Part A of the First Schedule | Contract |
Licensing a CMP does not make you, or your vendor, a Consent Manager. Conversely, the existence of registered Consent Managers does not remove your own rule 3 duties: the notice still has to itemise the personal data and purposes, and withdrawal still has to be comparably easy to granting under rule 3(c)(i).
What to Build: Interoperability, Not Integration
The useful preparation is to make sure your consent machinery could interoperate with a Consent Manager, without assuming you must integrate with one.
- Record consent at purpose granularity. A single boolean for "accepted terms" cannot be reconciled with an external record of what was consented to. Store which itemised purposes were granted.
- Version the notice. Keep the exact notice text and its effective date alongside each consent record, so a consent can be replayed as it was given.
- Timestamp grant and withdrawal separately. Both events matter, and an overwritten flag loses the history.
- Expose withdrawal as a callable path, not just a UI. If withdrawal only exists as a button in your account settings, an external intermediary has nothing to invoke. Rule 3(c)(i)'s parity requirement is easier to satisfy through a clean internal interface anyway.
- Keep an identifier you could reconcile on. Interoperation requires agreeing on which person a consent belongs to without exposing more data than necessary.
- Separate consent records from the retention floor. Rule 8(3) requires a minimum one-year retention of personal data, traffic data and processing logs, so a withdrawal is not a licence to purge the record of it having been granted.
Everything on that list improves your rule 3 position regardless of whether a Consent Manager ever enters the picture. The full duty-by-duty breakdown is in our DPDP compliance checklist.
If You Are Considering Becoming One
If you are considering becoming one, treat it as a product decision rather than a compliance shortcut. Rule 4 requires an application to the Board and satisfaction of the conditions in Part A of the First Schedule, and registration brings obligations of its own that run continuously once granted.
The honest framing is that it puts you in a regulated intermediary business, with a registered status that can presumably be examined and withdrawn, serving Data Principals rather than the fiduciaries who would be your commercial counterparties. That is a different company from a SaaS vendor adding a consent feature, and the diligence should be proportionate.
Consent Manager Questions Teams Ask
No. Rule 4 creates a registered class of Consent Managers and sets out their registration conditions and obligations. It does not compel an ordinary Data Fiduciary to route consent through one, and consent you capture directly remains valid provided it satisfies rule 3. Your practical task is to make sure your consent records and withdrawal mechanics could interoperate with a Consent Manager if your sector converges on one — not to assume an integration is mandatory.
No, and the similar names cause genuine confusion. A consent management platform is a tool you license to manage consent on your own properties; it acts for you, needs no registration, and is governed by your contract with the vendor. A Consent Manager under rule 4 is a registered intermediary that acts for the Data Principal, is registered with the Data Protection Board against Part A of the First Schedule, and spans consents across many fiduciaries. Licensing a CMP does not make anyone a Consent Manager.
One year after the Rules were published in the Gazette, so mid-November 2026. It is the only rule on that middle clock. The provisions constituting the Data Protection Board came into force on publication, 14 November 2025, and the operational duties most teams have to build for — rules 3 and 5 to 16, covering notice, consent, security safeguards, breach intimation, retention, children's data, Significant Data Fiduciary duties, rights and cross-border transfer — commence eighteen months after publication, in mid-May 2027.
It gives her one place to give, manage, review and withdraw consent across the services she uses, instead of visiting each provider's settings separately. Because it is registered with the Board and acts for her rather than for any fiduciary, it is structurally on her side of the relationship. Whether that materialises as a widely used layer depends on whether providers register and whether sectors adopt them, neither of which the Rules compel.
Honour the withdrawal as you would one made directly, and keep the record. Rule 3(c)(i) already requires withdrawal to be as easy as granting, so the mechanism should not change your obligation — only the surface the request arrives through. Note that withdrawal does not license deletion of everything: rule 8(3) requires retention of personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, so stopping the processing and purging the evidence of consent are different acts.
Get consent capture and withdrawal right before May 2027
Book a demo and we'll walk your notice, consent records and withdrawal flow against rule 3, and show what evidence Konfirmity keeps so a withdrawal can be proved years later.
Book a demo
What Rule 4 Actually Changes for You
Rule 4 is a market-structure rule that got read as a procurement mandate. It registers a class of intermediaries that act for individuals; it does not require you to use one, and it does not displace a single one of your own duties under rule 3.
Build consent records that are granular, versioned and separately timestamped, and expose withdrawal as something more than a button. That is worth doing for rule 3 alone, and it happens to be exactly what interoperating with a Consent Manager would require if the question ever becomes live.
