Your consent flow works. A user taps accept, a row lands in your database, marketing gets its audience, and nobody thinks about it again. Now picture a platform your company has never integrated with, never signed a contract with, sending a withdrawal instruction on that same user's behalf and expecting your systems to honour it. That is the shape of the DPDP consent manager deadline landing on 13 November 2026. Most Indian data teams are still treating consent as something they own, when the law is about to treat it as something they receive.
Why the DPDP consent manager deadline lands early
The DPDP consent manager deadline lands early because your obligation is not to register a consent manager, it is to accept instructions from one, and that capability takes far longer to build than a vendor contract takes to sign.
Read the commencement schedule and it looks generous. MeitY notified the Digital Personal Data Protection Rules, 2025 on 13 November 2025. Rule 4 and the First Schedule, which carry the consent manager machinery, take effect exactly a year later. The operative duties on data fiduciaries wait until 13 May 2027. Eighteen months of runway. Plenty of time.
That reading is wrong, and it is the most common mistake in Indian compliance roadmaps right now. The 2027 date governs what you must tell people. The 2026 date governs what your systems must be able to hear. Those are different engineering problems, and the second one is harder, because it means an external party you did not choose gets to change the state of a record inside your platform. Anyone who has watched India's telecom sector fight over whether operators should display verified KYC names to the people they call already knows how slowly identity plumbing moves once it has to work across companies.
What is a consent manager under the DPDP Act?
A consent manager is an Indian-incorporated company, registered with the Data Protection Board, that gives a person one interface to grant, review, manage and withdraw consent across every business holding their data.
The First Schedule sets the bar deliberately high. The applicant must be incorporated in India. It must hold a minimum net worth of two crore rupees. Personal data routed through its platform must not be readable by it, which rules out the obvious architecture where a broker sits in the middle and inspects payloads. Consent records must be retained for seven years. Together those conditions describe an entity closer to a depository than to a SaaS product, and the capital test alone will keep the field small. Four numbers frame the problem.
Phase-in runway
18 months
Notification to full force
Entry bar
Rs 2 crore
Minimum registered net worth
Managers registered
0
As of September 2026
Rules in force
1 of 3
Commencement phases live today
The third cell is the one that should bother you. The Board is established in law under Section 18 of the Act, and MeitY has invited applications for its Chairperson and Members, with a search panel headed by the Cabinet Secretary. It is not fully constituted. No registry exists, so no company has been registered to do the job the rule assumes will be done. Meanwhile the DPDP Act's own schedule of penalties sets a ceiling of 250 crore rupees for a single failure to take reasonable security safeguards, and that ceiling is not waiting for anyone to be appointed. The same pattern shows up in AI agent governance, where the enterprises that moved before the rules landed are the ones now setting the terms.
A framework with a hard start date and not one registered intermediary behind it is not a grace period. It is a deadline you will meet alone, inside your own stack.
Key highlights: what switches on, and when
India's DPDP Rules, 2025 commence in three tranches between November 2025 and May 2027, and only the consent manager tranche carries a build requirement that reaches outside your own systems.
The table below is the version of the schedule worth pinning above a sprint board, because it separates dates that create paperwork from dates that create engineering. Two of these rows describe conditions, not deadlines, and those are the ones that decide your architecture.
| Category | Detail | Insight |
|---|---|---|
| Phase 1 | Board and institutional rules live since 13 Nov 2025 | Sets up the regulator, imposes no duties |
| Phase 2 | Rule 4 and First Schedule from 13 Nov 2026 | Registration opens, interoperability becomes real |
| Phase 3 | Rules 3, 5 to 16, 22 and 23 from 13 May 2027 | Notice, breach and erasure duties start biting |
| Eligibility | Indian incorporation plus the two crore net worth floor | Excludes foreign-domiciled consent vendors outright |
| Retention | Consent records held for a minimum of seven years | Outlives typical CRM and log retention windows |
| Data blindness | Routed personal data must stay unreadable to the manager | Forces token or pointer based integration design |
| Regulator | Board not fully constituted, MeitY applications open in 2026 | No registry means no counterparty to test against |
| Build window | Under 10 weeks from September 2026 to Rule 4 | Design freeze needed by mid-October to land it |
Rows four through six are the ones your architects should argue about. Eligibility decides whether your current privacy vendor can hold the role at all. Data blindness decides your integration shape. Retention decides the storage tier, and seven years is long enough that the answer is probably not your transactional database.
The three commencement points set out in the Digital Personal Data Protection Rules, 2025 as notified by MeitY, running from the institutional framework in November 2025 through to the duties on data fiduciaries in May 2027.
Do Indian companies have to use a consent manager?
No, a data fiduciary is not required to appoint a consent manager, but it must be able to receive and act on consent given, reviewed or withdrawn through one, which makes the integration mandatory even when the appointment is not.
This is where the common advice goes wrong. Plenty of teams have filed the consent manager work under procurement, expecting a vendor to arrive in 2027 with a connector. That gets the direction of the obligation backwards. The consent manager works for the individual, not for you. When it sends a withdrawal, your platform is the party that has to prove it acted, and proving it means an auditable trail that survives seven years and several system migrations. This is the same long-horizon storage problem that shows up in harvest now, decrypt later planning, where data you keep for a decade has to survive threats that do not exist yet.
What happens if no consent manager is registered by November 2026?
Nothing visible happens, and that is the trap. My read is that a quiet Phase 2 will be treated by most boards as evidence that the whole thing slipped, and the build will be deferred into the same quarter as the May 2027 duties. That is a bad bet. The Board can be constituted in weeks once appointments clear, registrations can follow quickly after that, and the first fiduciary asked to honour an external withdrawal will not get a runway. Watch for these before you defer:
- Legacy consent captured before the Rules, with no purpose string attached, which cannot be mapped to a machine-readable record.
- Withdrawal propagation that stops at the primary database and never reaches warehouses, exports, ad platforms or vendor copies.
- Consent state held in a table with no history, so you can show what is true today but not what was true on the day of a complaint.
- Vendor contracts that treat consent as your problem, with no obligation on the processor to accept a withdrawal signal you pass down.
Key takeaways: the four capabilities Rule 4 assumes you already have
1. Purpose-bound records. Every consent stored as a machine-readable object carrying the purpose it was given for, not a boolean flag on a user row.
2. External ingestion. An authenticated endpoint that accepts grants and withdrawals originating outside your product and treats them as binding instructions.
3. Downstream propagation. A fan-out path that carries a withdrawal to every copy of the data, including the ones your analytics team forgot to document.
4. Auditable history. An append-only log that can reconstruct the consent state of any individual on any past date, and hold it for seven years.
Pick the ingestion endpoint and the audit log first, because both are slow and neither depends on a registry existing. The registry is the visible part. The unglamorous part, and honestly the part that will eat your quarter, is propagation. Start the design review this month, freeze it by mid-October, and let the Board catch up to you.
