India's DPDP Act for teams shipping software

There is a particular kind of compliance article that lists penalties, quotes the biggest number it can find, and tells you to act now. The DPDP Rules have generated a great many of them. They are mostly wrong about timing, and being wrong about timing is expensive in both directions — teams spend this quarter on consent banners that are not due for eighteen months, and spend none of it on the retention work that genuinely needs that long.

This is not legal advice. It is an engineering read on what the Rules ask you to build. Have counsel confirm how they apply to your organisation before you plan around any of it.

One caveat on dates, stated up front because the sources disagree. The Rules commence by reference to a period — "eighteen months after the date of publication in the Official Gazette" — not a calendar date. The publication date is reported as both 13 and 14 November 2025 depending on the source, so every computed date below carries a day of uncertainty. Nothing in the planning changes; just do not build a cutover around a specific afternoon.

Almost none of it is in force

Rule 1 does the thing most readers skip, which is to stage the entire instrument. Three sub-clauses, three tranches, and the split is not arbitrary — it tracks who has to do the work.

The first tranche commenced on publication: the short title and definitions, and the rules covering the Data Protection Board's constitution, its proceedings, the terms of its members, and appeals to the Appellate Tribunal. That is the machinery of enforcement. It created the regulator. It asked nothing of anyone building product.

The second tranche is a single rule, commencing one year after publication, which falls this week. It governs the registration and conduct of Consent Managers — the intermediaries through which a person can give, manage, review and withdraw consent across the fiduciaries they deal with. If you are registering as one, this is your date. If you are a bank, a retailer, a SaaS company or a development partner, it is not. The distinction is routinely lost in coverage that reports "DPDP obligations begin in November".

The third tranche is everything else, and it is where the engineering lives.

The seventy-two hours everyone quotes

The breach rule is the most frequently misdescribed provision in the whole instrument, in two separate ways.

First, it is not in force. It sits in the eighteen-month tranche with the rest of the substance. An organisation that suffers a breach today has no DPDP reporting duty, because the duty does not yet exist.

Second, the seventy-two hours does not mean what the shorthand implies. The rule has two limbs on two different clocks. To affected individuals, you owe an intimation without delay — not within seventy-two hours, without delay — describing the nature, extent and timing of the breach, the consequences likely to arise, what you are doing about it, what they can do to protect themselves, and a named contact who can actually answer. To the Board, you owe an immediate description without delay, and then a detailed report within seventy-two hours of becoming aware, or longer if the Board allows it on a written request.

So the famous number governs the regulator's paperwork, and the stricter obligation — the one with no clock at all, which in practice means faster — governs what you tell your users. Teams that build to the seventy-two hours will have built the wrong thing.

Worth separating from all of this: CERT-In's six-hour incident reporting direction is already in force and has been since 2022. It is a different obligation, to a different body, on a much shorter clock. If you operate in India you are likely subject to it today, and no amount of DPDP readiness addresses it.

Two clocks that pull against each other

Here is the part that justifies an eighteen-month runway, and it is not the consent screen.

The security rule requires, as a minimum, that you encrypt, obfuscate, mask or tokenise personal data; control access to the computer resources involved; maintain visibility over who accessed personal data through logs, monitoring and review; keep backups sufficient for continued processing; push equivalent obligations down into your contracts with processors; and retain those logs and that personal data for one year.

The retention rule requires you to erase personal data once the specified purpose is no longer being served, and — a detail that quietly implies a scheduler, a notification pipeline and a queryable prediction of future deletions — to tell the person at least forty-eight hours before the erasure happens.

Read together: keep the evidence, delete the data. Both are mandatory, both are in the same tranche, and reconciling them is a data architecture problem rather than a policy one. The resolution is that erasure has to be selective — the personal data goes, the access log proving who touched it stays, with the log itself held to its own one-year clock. That is straightforward to say and genuinely difficult to build, especially in a system where personal data has leaked into analytics tables, search indexes, cached aggregates, support tickets, exports and model training sets.

If you want a single sentence to take to a planning session: consent is a feature, erasure is an architecture. One of those fits in a sprint.

The three-year clock has thresholds

A specific erasure period appears in the Third Schedule, and it is widely reported as though it binds everyone. It does not. It attaches to three named classes at stated scale: e-commerce entities with at least two crore registered users in India, social media intermediaries at the same threshold, and online gaming intermediaries with at least fifty lakh. For those, personal data is erased three years after the person last approached the fiduciary or exercised a right, with carve-outs that let someone still reach their account and any virtual tokens.

If you are below the thresholds, or outside the classes, that particular clock is not yours. The general duty — erase when the purpose is served — still is, and it is the harder one to engineer precisely because no number tells you when.

What the Rules do not say about leaving India

This matters for anyone whose development, hosting or support sits across borders, and it is the point most often reported backwards.

The cross-border rule is permissive. It allows personal data processed under the Act to be transferred outside India, subject to such requirements as the Central Government may specify regarding making that data available to a foreign State or an entity under its control. It is a national-security-shaped restriction on disclosure to foreign governments, not a residency mandate.

There is one localisation provision, and it is narrow: a Significant Data Fiduciary must ensure that personal data specified by the Central Government, on a committee's recommendation, is not transferred outside India, along with the traffic data about its flow. That is a targeted list that does not yet exist, applying to a class of organisation that is designated rather than self-declared.

So: no general data residency requirement, and a vendor telling you DPDP forces your data to stay in India is describing something the Rules do not contain. The reverse question — whether your own regulator permits the transfer — is a real one, and for European controllers it is the GDPR analysis, not the DPDP one.

A sequence that fits the runway

1. Map personal data first. Not a policy, an inventory: every store, index, log, export and third party that holds it. Everything below depends on this and nothing else can start without it.
2. Decide what erasure means in your system — which fields go, which logs stay, what happens to derived data and backups. This is the long pole; start it this quarter even though the duty is eighteen months out.
3. Build consent per purpose, with withdrawal that propagates. A consent record that cannot be revoked downstream is not a consent record.
4. Instrument access logging to the one-year standard, and verify the retention actually holds rather than being rotated away at ninety days by a default nobody set deliberately.
5. Write the breach runbook against the right clocks — without delay to individuals, seventy-two hours to the Board — and rehearse it, because the hard part is detection, not the form.
6. Build the rights endpoints: access, correction, erasure, nomination, grievance. These are product surface, not legal text, and they need owners.
7. Re-check the commencement position before you plan a cutover. There has been persistent reporting that the eighteen-month runway may be shortened to twelve; as of writing no instrument doing so appears to have been notified, but this is the one item on the list worth watching monthly.

The teams that handle this well will not be the ones who moved first. They will be the ones who correctly identified that the deadline is long, that the urgency is misreported, and that the single item needing the full runway is the one with no screen attached to it.

Questions we get asked

If you are planning an Indian build and want the retention and erasure design settled before it becomes a retrofit, that is a conversation worth having early on any offshore engagement — it is far cheaper than discovering in 2027 that personal data reached six places nobody mapped.