Nine and a Half Months: The DPDP Engineering Critical Path to 13 May 2027

Two clocks are running on the DPDP Act, and most readiness plans I have seen merge them. Nothing general commences on 13 November 2026 — three provisions do, and they concern Consent Managers registering themselves. The date that should drive engineering plans is 13 May 2027, and the items on that critical path have lead times measured in quarters.

The November date is not your deadline

The Act received assent on 11 August 2023. The Rules followed two years on: G.S.R. 846(E) is dated 13 November 2025, while the Government’s own PIB explainer describes them as notified on 14 November 2025. Both dates get cited, and both are defensible: the commencement clock runs from publication in the Official Gazette, not from the date on the notification.

Rule 1 splits commencement three ways: Rules 1, 2 and 17 to 21 on publication; Rule 4, Consent Manager registration and obligations, at one year; the rest at eighteen months. G.S.R. 843(E) did the same to the Act, commencing only Section 6(9) and Section 27(1)(d) at twelve months and holding Sections 3 to 5, Section 6(1)–(8) and (10), Sections 7 to 17 and Sections 28 to 34 back to eighteen.

A dozen trackers call 13 November 2026 “the first compliance deadline”, and several tell Data Fiduciaries they must “register with a Consent Manager” by then. Both are wrong. Consent Managers register themselves with the Board under Section 6(9) and Rule 4, and Section 6(7) says a Data Principal may give, manage, review or withdraw consent through one — a channel offered to the individual, not a compulsory integration.

13 May 2027 is different in kind: the substantive obligations and the Board’s power to inquire and impose penalties commence together, so there is no ramp on the far side. The Schedule sets fixed rupee ceilings rather than a share of turnover — up to ₹250 crore for failing to take reasonable security safeguards under Section 8(5), ₹200 crore for breach-notification failures. GDPR’s 4 per cent of global revenue does not transfer, and nor does a single headline maximum, because the entries are per-breach.

Nine and a half months is four usable quarters

Deadlines are not delivery dates. If you want two months of new behaviour running in production before the penalty power arrives — and you do, since it arrives with the obligation — the last functional merge is early March 2027. Take out December, an audit window and a pen-test, and a team starting in August 2026 has four usable quarters.

EY India’s January 2026 survey found more than 83 per cent had not begun comprehensive implementation, and only 38 per cent had categorised their personal data and identified third-party processors.

Discovery, the item with no shortcut

Rule 3 makes the notice a standalone artefact: understandable independently of anything else the fiduciary has published, and carrying an itemised description of the personal data and the specified purposes.

“Itemised” is load-bearing, and it means the notice cannot be written until discovery finishes. The work is in the columns that lie — a cust_ref field holding a PAN in 3 per cent of rows because a 2019 integration wrote through whatever the upstream sent, a nightly CSV drop to a collections vendor nobody in IT owns any more. Content sampling finds those; name matching does not. Each classification then needs a named human to confirm it, because a false positive is a promise you never had to make and a false negative is the line that ends up in front of the Board. Past forty-odd data stores, that loop is a two-to-four quarter job.

Consent as evidence, not a checkbox

Section 6(10) reverses the burden of proof. Where consent is the basis of processing and a question arises in a proceeding, the fiduciary must prove that notice was given and that consent was given in accordance with the Act — per principal, per purpose, possibly three years later, to a Board whose inquiry must conclude within six months under Rule 19(9).

MeitY’s non-binding Business Requirement Document for Consent Management, published on 6 June 2025, states the engineering plainly: no bundled consent, per-purpose granularity, no pre-checked defaults, immutable and tamper-proof consent artifacts, and metadata logging of timestamp, purpose IDs, consent status and language preference.

Consent has to point at an immutable, content-addressed version of the rendered notice, not at the notice. We learned that the expensive way, and it is a longer story than this post: the failure is silent for years and then unfixable.

The second was erasure that deleted the consent record along with the personal data, destroying the evidence Section 6(10) demands. Rule 8(3) makes the same point from the other side: personal data, associated traffic data and processing logs must be kept at least a year from the date of processing, even where the user has deleted her account. So erasure is selective — the payload goes, the artefact stays, joined to a pseudonymous principal ID whose derivation key must never be rotated. Rotate it and you cannot connect a person to her own consent history to answer her own grievance.

Withdrawal needs the same discipline: a new artefact, not an UPDATE that flips a boolean, or “what was this person’s consent state at 14:20 on 4 February 2027” has no answer. Where collection points sit inside shipped mobile apps, count the release trains backwards from May 2027.

The existing user base, correctly scoped

The most expensive myth is that the Act forces you to re-collect consent from every existing user. Section 5(2) requires a notice “as soon as it is reasonably practicable” for consent given before commencement, and Section 5(2)(b) expressly permits processing to continue until the Data Principal withdraws consent. Fresh consent arises for a new or changed purpose, and there Section 6(1) is strict — a clear affirmative action, so silence and continued use are not consent.

The real problem is deliverability. A dormant account with a bounced email and a mobile number recycled to someone else is the hard case, and a large slice of most Indian consumer bases. We record delivery outcome per attempt per channel, because that is the only thing that will ever evidence “reasonably practicable”.

Retention pulls in two directions

The three-year erasure clock is over-generalised almost everywhere. Rule 8(1) and the Third Schedule reach only an e-commerce entity with at least two crore registered users in India, an online gaming intermediary with fifty lakh, and a social media intermediary with two crore. Everyone else lives under the general Section 8(7) test — erase on withdrawal, or when it is reasonable to assume the purpose is no longer being served.

Where the Third Schedule does bite, Rule 8(2) requires the principal to be told at least forty-eight hours before erasure so she can log in and reset the clock. The failure mode is two jobs computing that deadline independently and drifting apart. One row owns the truth — erasure_schedule(principal_id, due_at, notified_at) — the notifier reads due_at, and the eraser refuses any row whose notified_at is null. Refusing is the important half: the safe failure is not erasing.

Pulling the other way are Rule 8(3)‘s one-year floor and Rule 6(1)‘s one-year retention of logs and personal data for breach detection. A design that only deletes is non-compliant in the opposite direction.

Cascade is the unsolved part. We crypto-shred: a per-principal data encryption key, destroyed on erasure, leaves ciphertext inert wherever it has been copied, backups included. That covers the primary store and nothing past it — not a warehouse aggregate computed before the erasure, not a model already trained on the data, and not a processor whose deletion guarantee is contractual rather than technical. I have no good answer to the training-data question and have not seen one elsewhere.

The breach drill runs on three clocks

Seventy-two hours is not “the breach notification deadline”, and calling it that has built the wrong playbook in many organisations. Rule 7(1) requires intimation to each affected Data Principal without delay, carrying five specified elements including the consequences relevant to her and contact details of a person who can answer her questions. Rule 7(2)(a) requires an initial description to the Board without delay. The 72 hours in Rule 7(2)(b) covers only the detailed follow-up report.

Before any of that sits CERT-In’s direction of 28 April 2022, requiring any body corporate to report specified cyber incidents within six hours of noticing them and to keep ICT logs for a rolling 180 days inside Indian jurisdiction. A DPDP playbook that starts at 72 hours is already 66 hours late under a different statute.

All three clocks start on becoming aware. IBM’s 2025 research put India’s mean time to identify and contain a breach at 263 days, against a record average cost of INR 220 million, up 13 per cent from INR 195 million. Detection engineering is part of the breach obligation whether or not the Rules say so.

What can safely be done late

Policy text, the DPO appointment, vendor addenda and grievance workflow configuration are genuinely last-quarter work — Inc42 costs an in-house DPO at ₹25–40 lakh a year against ₹2–8 lakh fractional, inside a market it sizes at roughly ₹10,000 crore over three years.

Four things get underestimated. Languages first, and the requirement is not “notices in 22 languages”: Section 5(3) gives the Data Principal the option to access the notice and every consent request in English or any language in the Eighth Schedule, which lists 22. Operationally, translation state belongs to the notice version — edit one English purpose description and twenty-two translations go stale silently unless publishing is gated on translation currency or a recorded fallback.

Second, Rule 14(3)‘s ninety-day ceiling on grievance responses is a staffing commitment, not a config flag. Third, Rule 13’s twelve-monthly DPIA and audit for Significant Data Fiduciaries runs from the date an entity is notified as such — and no SDF list had been notified as of mid-2026, so nobody has a start date. Fourth, the First Schedule wants a Consent Manager to be an Indian company with net worth of at least two crore rupees, certified against standards “as may be published by the Board”, and unable to read the data it moves. Those standards were unpublished as of mid-2026, and as of April 2026 the Board’s Chairperson and Members had not all been appointed.

The calendar, worked backwards

Exit by	Finished
End Sep 2026	Discovery pass one across every store, log sink and processor
End Nov 2026	Purpose catalogue frozen, each purpose with an itemised data list
End Jan 2027	Versioned, hashed notice and consent artefacts live; all collection points migrated, mobile release cut
End Feb 2027	Retention encoded per purpose with the one-year floors; pre-erasure pipeline in dry-run
Early Mar 2027	Last functional merge; rights and grievance workflows live, 90-day SLA instrumented
Apr 2027	Freeze. Breach drill on all three clocks; erasure tested against a restored backup

One risk sits over the schedule. On 23 January 2026 MeitY proposed compressing the timeline from eighteen months to twelve, moving it to 13 November 2026, with comments sought by 4 February 2026. Nothing has been notified, so 13 May 2027 stands. The risk is asymmetric: a plan built for May 2027 that has to become November 2026 loses six months, while one built for November 2026 that does not move is merely early.

Knowing what you hold, proving notice and consent, and enforcing retention in running code are worth building on their own merits, deadline or not. If you would rather not build the consent evidence layer yourself, that is the part we make.