India’s Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, starting an 18-month phased rollout of the Digital Personal Data Protection Act, 2023. Some provisions took effect immediately. The most operationally disruptive one lands on 13 November 2026. The rest becomes enforceable on 13 May 2027.

This site has covered the DPDP Act and the draft Rules and what makes the Indian regime structurally different from GDPR. With under three months to the Phase 2 date, this is a narrower question: what actually changes on 13 November 2026, who it changes for, and what an organisation with an Indian user base or Indian operations should have in place.

The three-phase structure

The rollout is worth stating precisely, because the phases are commonly conflated.

Phase 1 — from 13 November 2025. The Rules relating to the establishment and functioning of the Data Protection Board of India came into force, along with the definitional provisions. This phase is institutional, not operational for data fiduciaries.

Phase 2 — from 13 November 2026. Rule 4 and the associated First Schedule become operative: the Consent Manager registration framework and the obligations attaching to registered Consent Managers.

Phase 3 — from 13 May 2027. The remaining substantive obligations become enforceable: notice requirements, consent standards, reasonable security safeguards, personal data breach intimation, data principal rights fulfilment, retention and erasure, obligations of Significant Data Fiduciaries, and processing of children’s data.

The penalty structure sits behind all of it. The DPDP Act’s Schedule provides penalties up to INR 250 crore for failure to take reasonable security safeguards, up to INR 200 crore for failure to notify a personal data breach or for breach of children’s data obligations, and up to INR 150 crore for breach of Significant Data Fiduciary obligations. There is no indication of an extended grace period beyond the phased dates themselves.

This is the part that does not map onto GDPR, and the mapping failure causes most of the confusion.

A Consent Manager under the DPDP Act is not a consent management platform in the cookie-banner sense. It is a registered intermediary that enables a Data Principal to give, manage, review and withdraw consent across data fiduciaries, through an accessible, transparent and interoperable platform. The statute places it in a fiduciary relationship with the Data Principal — it acts on the individual’s behalf, not the business’s.

The First Schedule conditions are demanding:

  • Incorporated in India, with a minimum net worth of INR 2 crore
  • Fiduciary capacity toward the Data Principal, with obligations to act in the Data Principal’s interest
  • Technical and organisational capability to enable Data Principals to give, manage, review and withdraw consent, including interoperability with data fiduciaries
  • Data blindness — the Consent Manager must ensure that personal data routed through its platform is not readable to it
  • Consent record retention for at least seven years
  • Obligations relating to governance, control of the entity, conflict of interest, and reporting to the Board

That last cluster is why very few organisations will become Consent Managers, and why almost every organisation will need to interoperate with them.

The distinction that determines your workload

There are two entirely different compliance postures here, and organisations should establish which one they are in before doing anything else.

If you intend to register as a Consent Manager, you are undertaking a regulated-entity project: Indian incorporation, capitalisation, a data-blind architecture, seven-year consent record retention, governance and conflict-of-interest controls, and a registration application to the Board. That is not a three-month project.

If you are a Data Fiduciary — which covers essentially every organisation processing digital personal data of individuals in India, and every foreign organisation offering goods or services to individuals in India — your obligation is interoperability. When a Data Principal chooses to manage consent through a registered Consent Manager, you must be able to receive, honour and reflect that consent, including withdrawal, through the Consent Manager’s platform.

Practically, that means your consent architecture must support:

  • Machine-readable consent records with a stable identifier per Data Principal per purpose
  • Ingestion of consent grants and withdrawals from an external party, propagated to every downstream system that relies on that consent
  • Purpose-level granularity, because consent under the DPDP Act is specific to the purpose for which data is processed
  • Withdrawal that is as easy as giving consent — a statutory requirement under Section 6(6) — and that propagates promptly
  • Auditable consent history, because the burden of demonstrating consent sits with the Data Fiduciary

Most organisations’ consent systems today store consent as a boolean or a set of flags in a marketing platform, with no external ingestion path and no propagation guarantee. That is the gap.

The regulator problem

Here is the structural difficulty that makes this deadline unusual.

Consent Managers must be registered with the Data Protection Board of India. The Board’s establishment provisions came into force in November 2025. As of August 2026, reporting indicates the Board has not been fully constituted and the registration process is not operating.

That produces a genuinely awkward position for November 2026: a framework becomes operative on a date when the registry that gives it effect may not be functioning. Aspiring Consent Managers cannot register with a body that is not accepting applications. Data Fiduciaries cannot integrate with registered Consent Managers if none are registered.

Two things follow, and organisations should hold both.

Do not read the regulator gap as a deferral. The date is set in a notified rule. Institutional readiness has historically been a poor predictor of whether obligations are treated as live — and the practical exposure is not primarily to the regulator on day one. It is to the contractual and commercial expectations of Indian counterparties, to enterprise customers running vendor due diligence against the DPDP timeline, and to the possibility that registration opens with little notice and integration is expected quickly.

Do build for interoperability rather than for a specific counterparty. Since no registered Consent Manager exists to integrate with, the correct engineering objective is an abstraction: a consent service inside your architecture that can accept externally-sourced consent events through a defined interface, and that propagates grants and withdrawals to downstream consumers. Which specific Consent Manager sits on the other end of that interface becomes a configuration problem rather than a re-architecture.

What the May 2027 phase adds, and why it changes the November plan

It is tempting to treat November 2026 as the near deadline and May 2027 as a later problem. That sequencing is wrong, because the November obligation is an interface onto capabilities that the May obligations require you to build anyway.

The May 2027 phase brings:

Notice. A DPDP notice must be in clear and plain language, itemise the personal data and the purpose, and describe how to withdraw consent, exercise rights and complain to the Board. It must be available in English and in the languages specified in the Eighth Schedule to the Constitution at the Data Principal’s option — a translation and localisation workload that organisations consistently underestimate.

Consent standards. Free, specific, informed, unconditional, unambiguous, with clear affirmative action, and limited to the personal data necessary for the specified purpose.

Reasonable security safeguards. Rule 6 specifies these with more particularity than most privacy statutes: encryption, obfuscation, masking or virtual tokens; access control; logs and monitoring retained for at least one year; backup and continuity provisions; and contractual imposition of equivalent obligations on Data Processors.

Breach intimation. Notification to affected Data Principals without delay, and to the Board — initially without delay with the described facts, and with a detailed report within 72 hours. Note the shape: the individual notification obligation is not gated on a risk threshold as under GDPR.

Data principal rights, including access, correction, erasure and grievance redressal, with published timelines.

Children’s data. Verifiable parental consent for anyone under 18 — a materially higher age threshold than COPPA’s 13 or the GDPR’s 13-to-16 range — plus prohibitions on tracking, behavioural monitoring and targeted advertising directed at children.

Significant Data Fiduciary obligations for entities so designated: annual Data Protection Impact Assessment, annual audit, appointment of an India-based Data Protection Officer, and algorithmic due diligence.

The relevant point for the November plan: the consent record structure, the purpose taxonomy and the withdrawal propagation mechanism required for Consent Manager interoperability are the same artefacts the May obligations require. Building them for November means the May work is largely integration rather than construction. Deferring them means doing both under compressed time.

A three-month plan for Data Fiduciaries

Establish whether you are in scope, and record the reasoning. The DPDP Act applies to processing of digital personal data within India, and to processing outside India where it is in connection with offering goods or services to Data Principals within India. Organisations with an Indian user base but no Indian entity are frequently in scope and frequently assume they are not.

Build the purpose taxonomy. Enumerate every purpose for which you process personal data of Indian Data Principals. This is the foundation for notice, for consent granularity and for the Consent Manager interface. It is also the item that takes longest, because it requires the business to state plainly what it does with data.

Build the consent abstraction. A consent service with a defined external interface for grant and withdrawal events, a stable per-principal per-purpose record, an auditable history, and reliable propagation to downstream consumers. Design it to accept events from a party you have not yet met.

Test withdrawal propagation end to end. Withdraw a consent and verify that every downstream system — marketing automation, analytics, data warehouse, ML feature store, third-party enrichment — stops processing on that basis. In most organisations this test fails the first several times, and the failures are in the systems nobody remembered were consuming the data.

Start the notice translation work. Multi-language notice under the Eighth Schedule is a long-lead item involving legal review in each language. Beginning it in April 2027 will not work.

Map your Data Processor contracts. Rule 6 requires equivalent obligations to be imposed contractually. That is a renegotiation cycle, and renegotiation cycles run in quarters.

Assess Significant Data Fiduciary likelihood. If designation is plausible for your organisation, the DPO must be based in India and the audit and DPIA obligations are annual. Recruitment and audit-firm engagement are not May 2027 activities.

The framing that helps

India’s regime is not a GDPR clone with different numbers. The Consent Manager construct in particular has no European analogue: it is an intermediary that stands between the individual and every business, holds a fiduciary duty to the individual, and is deliberately blind to the data it routes.

An organisation that treats DPDP compliance as re-labelling its GDPR programme will build a consent system that cannot accept an instruction from a third party acting for the data subject — which is the one thing Rule 4 requires it to do.

Three months is enough to build the interface. It is not enough to discover on 13 November that the interface was the point.

This article is provided for informational purposes only and does not constitute legal advice.