For two years "DPDP compliance" had no deadline you could put in a sprint plan — the Act was passed in 2023 but the operative Rules weren't out, so the obligations were abstract. That changed on 13 November 2025, when the Ministry of Electronics and IT notified the Digital Personal Data Protection Rules, 2025 (Gazette G.S.R. 846(E)). The clock is now real, and it's phased over 18 months.

Here's the part that trips people up: the date everyone quotes — "May 2027" — is the final phase, and treating it as one big deadline is how teams end up cramming. The Rules roll out in three stages, and the engineering work splits across them. Below is the actual timeline and the build list mapped to each phase, with links to the deep-dives where each obligation gets technical.

The three phases (the real timeline)

The notification set an eighteen-month phased schedule, not a single switch (PIB press note):

Phase	When	What activates
Phase 1	from 14 Nov 2025 (now)	Procedural: definitions, the Data Protection Board of India, administrative machinery
Phase 2	~Nov 2026 (1 year)	Consent Manager registration + obligations become operational
Phase 3	~May 2027 (18 months)	Core duties: notice to Data Principals, breach reporting, and Data-Fiduciary compliance obligations

The practical read: Phase 1 is the government standing up its enforcement body, not work for you. Your engineering deadlines are Phase 2 (consent) and Phase 3 (the rest) — and because Phase 3 is "everything that touches user data," you want most of it built well before May 2027, not in Q1.

What to build, by phase

The Rules operationalise consent: it must be specific, informed, and withdrawable, with a clear record of what was granted, when, and on what notice. If you currently capture a single "I agree" checkbox, that's not it. You need per-purpose consent, a withdrawal path that's as easy as granting, and an auditable record per consent — and, where you rely on a registered Consent Manager, integration with one. The technical shape of that is in our consent manager framework.

Notice + Data-Principal rights — build for Phase 3 (~May 2027)

Two obligations, both engineering work:

Notice. Every collection needs a clear notice describing the data, purpose, and the rights available — served at the point of collection, in the languages the Rules expect.
Rights fulfilment. Data Principals can request access, correction, and erasure. That means a real export of a user's data and a deletion path that actually cascades (and leaves a tombstone for the audit record) — not a manual SQL query when a request comes in.

Breach reporting — build for Phase 3

The Rules require notifying affected Data Principals and the Board on a tight clock. Build the detection-to-notification pipeline now, because you can't improvise it during an incident — the mechanics, including the 72-hour report, are in breach notification under DPDP.

Audit trail — the spine under all of it

Notice, consent, rights requests, breaches — every one of them is a question a regulator can ask you to answer with evidence. That requires an append-only audit log of who did what, when, and under whose consent. If you bolt this on later you'll have gaps exactly where you need proof; build it as the system of record. See DPDP audit-trail requirements.

Children's data — if you have under-18 users

Processing a child's data needs verifiable parental consent. The Rules lean on India's existing identity rails to make that practical rather than theatrical — the DigiLocker-based verifiable parental consent approach is the realistic path.

Know your role first

None of the above lands correctly if you've mis-identified whether you're the Data Fiduciary or a Data Processor — the duties differ, and a processor inherits its fiduciary's instructions. Settle that before you build: Data Fiduciary vs Data Processor.

What the Rules did not settle (so you don't over-build)

Honesty matters more than a tidy checklist here. A couple of things remain open, and building for a stricter regime than exists wastes effort:

Cross-border transfers still follow the Act's Section 16 "negative list" model — transfers are allowed except to countries the government restricts, and no restricted-country list has been notified. Sectoral rules (e.g. RBI payment-data localisation) still prevail where they apply. More in data localization under DPDP.
Significant Data Fiduciary thresholds and the extra duties that attach to them are case-by-case via government notification — don't assume you're an SDF unless you're told.

The one-line plan

Map your work to the phases, not the headline date: consent for Phase 2 (~Nov 2026), and notice + rights + breach reporting + audit for Phase 3 (~May 2027) — with the audit log built first, since everything else has to be provable on top of it. The full ground-level list is in our DPDP compliance checklist for SaaS.

NamoID was built compliance-first for exactly this: per-connection consent capture with timestamp, IP, and scope; an append-only event log as the system of record; data-subject export and a deletion path that cascades to a tombstone. The Rules being notified didn't change our architecture — it just put dates on the things it was already designed to prove.