Being a Consent Manager vs using one: what actually starts on 13 November 2026

Two different things share one name in Indian privacy work right now. One is the consent software a company runs for itself. The other is a regulated intermediary that must be an Indian company with ₹2 crore of net worth on its balance sheet, independently certified and registered with the Data Protection Board — and whose registration regime switches on in November 2026. The most expensive confusion between them is the belief that using one moves your liability.

The name collision is in the statute, not in the marketing

Section 2(g) of the DPDP Act, 2023 defines a Consent Manager as “a person registered with the Board, who acts as a single point of contact” for a Data Principal. Registration sits inside the definition. A product that is not on the register is therefore not a Consent Manager — not a pending one, not a self-declared one. It is consent management software — a respectable thing to be, and what my team builds.

The real test is which way loyalty runs. Section 6(8) says the Consent Manager “shall be accountable to the Data Principal and shall act on her behalf”. An enterprise platform acts for the fiduciary that pays its invoice. Economic Laws Practice put it flatly in May 2026: such platforms fall outside the definition because they act on behalf of the Data Fiduciary, not the Data Principal. Same screens, opposite duty.

What it takes to be one

The First Schedule, Part A of the DPDP Rules, 2025 is nine items long and reads like a licence, because it is one. Item 1: “The applicant is a company incorporated in India.” That is the whole sentence. I have read at least three write-ups claiming a society or trust may register; the Gazette text does not say that, and the Government’s own explainer says Consent Managers “must be companies based in India”.

Item 4 sets net worth at not less than two crore rupees, and Note (c) defines net worth as total assets less liabilities as they appear in the books of accounts. Balance-sheet test — not paid-up capital, not money raised. A funded company can clear it at application and fall below it two years later while burning cash. Item 7 then reaches into the constitution of the company: the memorandum and articles must carry the conflict-of-interest obligations, amendable only with the Board’s previous approval.

Item 9(a) is where the regime is currently hollow. The applicant’s interoperable platform must be independently certified as consistent with “such data protection standards and assurance framework as may be published by the Board on its website from time to time”. As I write on 28 July 2026, no such framework is public — registration opens against a specification that does not exist, assessed by certifiers nobody has named.

The thirteen obligations in Part B

Part B is thirteen obligations. Item 2 is the constraint everything else hangs off: personal data must move in a manner such that “the contents thereof are not readable by it”. A courier that cannot open the parcel. It holds the consent record, not the data.

Items 3 and 4 define that record: consents given, denied or withdrawn; the notices preceding or accompanying each request; each sharing with a transferee Data Fiduciary. The principal gets access, gets it machine-readable on request, and it is kept at least seven years. Item 6 bans sub-contracting or assignment of any obligation, ruling out the white-label and reseller models most of the CMP market runs on. Item 11(b) requires publishing every shareholder above two per cent, and item 13 says control cannot pass by sale or merger without the Board’s prior approval — which prices an acquisition very differently from an ordinary software exit.

Two myths worth killing. The Rules do not mandate AES-256, or any named cipher, for Consent Managers — item 7 says only “reasonable security safeguards to prevent personal data breach”, and the word encryption appears exactly once in the Rules, in the Data Fiduciary’s safeguards rule, as one illustrative option beside obfuscation, masking and virtual tokens. And the Rules put no language obligation on Consent Managers at all: the duty to offer a notice in English or one of the 22 languages in the Eighth Schedule is Section 5(3) of the Act. Twenty-two scheduled languages plus English, and it is the fiduciary’s obligation, not the intermediary’s.

The date almost everyone is misreading

Rule 1(3) brings Rule 4 — Consent Manager registration and obligations — into force one year after Gazette publication. Rule 1(4) brings Rules 3 and 5 to 16, 22 and 23 into force at eighteen months. The Board-establishment provisions were immediate. So November 2026 is the registration regime for intermediaries, while notice, consent, data-principal rights, breach notification, children’s data and security safeguards land in May 2027. A programme plan that says “DPDP deadline: November 2026” is anchored to somebody else’s obligations.

The exact day is ambiguous: G.S.R. 846(E) is dated 13 November 2025 while PIB says the Rules were notified on 14 November 2025, and Shardul Amarchand Mangaldas computes the milestones as 14 November 2026 and 14 May 2027. I use 13 November 2026 and 13 May 2027 and treat the day as noise. From today: about three and a half months, and about nine and a half.

One more correction, since it is in nearly every vendor deck: the ₹250 crore penalty is not a general maximum. It attaches to a Data Fiduciary’s failure of reasonable security safeguards under Section 8(5). Consent Manager obligations fall under the residual head — “breach of any other provision” — capped at ₹50 crore. The Schedule separately carries ₹200 crore for failing to notify a breach, ₹200 crore for children’s-data obligations and ₹150 crore for Significant Data Fiduciary obligations.

Liability does not move

Section 6(7) says the Data Principal may give, manage, review or withdraw consent through a Consent Manager. Permissive. AZB & Partners read it the same way: fiduciaries may keep collecting consent directly if they meet the notice, withdrawal and record-keeping standards themselves.

Then the two lines that decide the commercial question. Section 6(10): in any proceeding, “the Data Fiduciary shall be obliged to prove that a notice was given by her to the Data Principal and consent was given”. Section 8(1): the fiduciary is responsible “irrespective of any agreement to the contrary”. Routing consent through a registered Consent Manager gives you a channel and a counterparty. It does not give you an indemnity against the Act, and no contract can create one.

The intermediary is not sheltered either. A processor sits behind its contract with the fiduciary; a Consent Manager has no such buffer and is directly and independently liable under the statute, exposed to a principal’s complaint under Section 27(1)(c), to an intimation of breach of a registration condition under 27(1)(d), and to suspension or cancellation under Rule 4(5). Rule 14(3) then puts the same ninety-day grievance ceiling on both parties, which is the tell: the intermediary adds a grievance channel, it does not retire yours.

Duty	Consent Manager	Data Fiduciary
Prove notice and consent — s.6(10), s.8(1)	—	Yes
Notice in English or a scheduled language — s.5(3)	—	Yes
Consent record, machine-readable, 7 years — Part B 3–4	Yes	Yes, separately
Data contents unreadable to itself — Part B 2	Yes	Not applicable
Grievances answered within 90 days — Rule 14(3)	Yes	Yes

We got the record wrong twice

The consent record is the whole asset, and it took two rewrites to model it properly.

Version one was a table of booleans: one row per principal per purpose, withdrawal implemented as an UPDATE. It worked until someone asked what a user had agreed to on a date months earlier, and the honest answer was that we had overwritten it. Consent is an event, not a state. Everything is append-only now; a withdrawal is a new row, never a mutation.

The second rewrite replaced a foreign key to the notice template with a digest of the rendered bytes, for reasons I have written about separately. What matters here is the shape it forced: one render path serving preview, live collection and audit replay, so a mismatched digest fails loudly instead of lying quietly.

The nastiest bug in that area had nothing to do with law. Our export job selected records where created_at > last_watermark, and created_at came from now() — in Postgres, the transaction start time, while the row only becomes visible at commit. A transaction that began before the watermark and committed after it was never exported and never would be, because the watermark had already moved past it. Silent, permanent, invisible to every count-based check. We now settle the watermark behind a lag and plant late-committing rows as traps in the test suite.

What we have not solved: Part B item 4(c) says keep the record seven years, and a principal exercising erasure wants the opposite. Our answer is a ledger keyed to a pseudonym with the identifying material under a separate key, so erasure destroys the key rather than the record — the consent history survives as evidence, unlinkable to a person. Defensible, and it also means that if a complaint about that person reaches the Board later, you have deliberately destroyed your ability to satisfy Section 6(10) for them. Section 6(10) has no expiry. I do not think anyone in this market has a clean answer, and I would rather say so than pretend our diagram closes it.

The precedent that already runs at scale

None of this architecture is novel in India. NITI Aayog’s Data Empowerment and Protection Architecture paper proposed consent managers as an institutional category in August 2020, and RBI had built the working version four years earlier. The NBFC–Account Aggregator Directions of 2 September 2016 set a net owned fund floor of two crore rupees and said no financial information accessed by an Account Aggregator “shall reside with the Account Aggregator”. Same money, same blindness, nine years before the DPDP Rules.

Sahamati’s counters as of June 2026 show 17 operational Account Aggregators, 176 Financial Information Providers, 1,076 Financial Information Users and “493m + Consent Requests Fulfilled”. Its FY26 report says the network facilitated nearly 3.8 crore financial products and services in FY26 and now runs over seven lakh consents a day. It took the better part of a decade to get there.

Account Aggregation is not the DPDP Consent Manager regime — different statute, different regulator, financial information only. But it is the design ancestor, and the honest reference point for how long the second one will take to matter.

The bet we are making

We are building as though the intermediary never arrives. Consent is an immutable artefact carrying the rendered notice digest, the purpose at a pinned version, the locale, the channel and the chain hash, because Section 6(10) asks what was true on a date and a current-state table cannot answer that. We publish our grievance route and hold ourselves to ninety days now, years before anyone can compel it. And we are treating Consent Manager integration as an inbound API we will one day have to serve, not a vendor we will one day buy — the wire format is unknowable until the Board publishes its framework, but the semantics (an artefact, a purpose, a principal identifier, a timestamp, a withdrawal) will not change.

That last part is a bet, and it may be wrong at the protocol level — it is simply the cheapest bet available while the specification does not exist. We build ConsentEra on it, and if the Board’s framework contradicts us, the ledger still survives.