DPDP Rules 2025: What Enterprises Must Build Before 13 May 2027

Most DPDP conversations we have had this year open the same way: we know it is coming, we have time. Then we ask two questions. Can you produce, today, a list of every system holding personal data of Indian users and the lawful basis for each? And if a data principal asked you to erase them, how many teams would you have to email? The answers usually reframe how much time there is.

Here is the actual position. The DPDP Rules were notified on 13 November 2025 with a phased commencement. Consent Manager registration opens on 13 November 2026. The substantive obligations on every Data Fiduciary — consent, notice, data-principal rights, breach response, retention — become enforceable on 13 May 2027. From today, that is roughly nine months. For anything involving data discovery across a real enterprise estate, nine months is not a comfortable runway.

The date people misread is the first one. Because full obligations land in 2027, many organisations have filed DPDP under "next year". But the Board has been operational since November 2025, which means the complaint channel exists ahead of the compliance deadline. That asymmetry is worth understanding rather than discovering.

Everything else depends on this and it is consistently underestimated. Not a diagram of your main applications — an inventory of where personal data actually lives, including the analytics warehouse, the CRM, the support tool, the marketing platform, the backups, the vendor systems, and the spreadsheet someone maintains for reconciliation. For each: what data, why, on what lawful basis, retained how long, shared with whom, and located where.

If you take one action from this article, start here, because every other obligation reduces to a lookup against this inventory. Rights requests, retention, breach scoping, cross-border questions — all of them are unanswerable without it, and all of them have deadlines.

DPDP consent has to be free, specific, informed, unconditional and unambiguous, with a clear affirmative action — and as easy to withdraw as it was to give. Two engineering consequences follow that most teams have not built for. You need to store consent as a record with enough context to reconstruct what the person agreed to and when, and you need withdrawal to actually propagate to downstream systems rather than flipping a flag in one database while the marketing platform carries on.

A bundled "I agree to the terms and privacy policy" checkbox does not meet this. Neither does consent obtained once and treated as permanent.

Access, correction, erasure and grievance redressal all need a working process with an owner, a route in for the individual, and evidence of the outcome. The failure mode is not refusing a request — it is being unable to fulfil one within a reasonable period because the data is scattered and nobody owns the workflow. Test it before it is tested for you: pick a real customer record and try to answer an erasure request end to end. The gaps surface immediately.

Breaches must be reported to the Data Protection Board within 72 hours. That clock is short and it is not the same clock as your CERT-In obligation, so if you operate in India you are now running two notification regimes with different triggers, timelines and recipients.

Seventy-two hours sounds workable until you account for what has to happen inside it: detection, triage, scoping which personal data of which individuals was affected, and a decision to notify — usually over a weekend. Organisations that meet it have rehearsed it. Ones that have only written a policy tend to spend the first day deciding who is allowed to make the call.

Personal data may be retained only as long as necessary for the stated purpose. This is the requirement that quietly contradicts how most data platforms were designed, because the prevailing instinct for a decade has been to keep everything in case it is useful later. Enforcing retention means deletion routines that actually run, including in backups and analytics copies, and a defensible rationale for each period.

Significant Data Fiduciaries carry additional duties, and two of them have real operational weight: a comprehensive Data Protection Impact Assessment and an independent data-protection audit, at least once every twelve months, with the independent professional reporting key findings and significant observations to the Data Protection Board.

Read that last part carefully. The audit output goes to the regulator, not only to your board. That changes the character of the exercise: it is closer to a regulatory examination than an internal review, and it means the auditor's independence and the evidence quality both matter. Organisations likely to be classified as SDFs should be building toward an auditable evidence base now, not assembling one in the quarter before the first audit.

If you hold ISO 27001, you have the security-controls half of the story and very little of the privacy half. ISO/IEC 27701 — which became a standalone standard in its 2025 edition — maps far more closely, because a Privacy Information Management System makes you build the data inventory, lawful basis, retention and rights machinery that DPDP then asks you to evidence.

To be direct about it: no certification makes you DPDP-compliant. DPDP is law and the standards are voluntary frameworks. But the evidence base overlaps heavily, and building them together is materially cheaper than building them twice — which is the actual argument for doing 27701 now rather than after.

Pick one business process that touches customer data — onboarding is a good candidate — and map it end to end: every system the data enters, the lawful basis, the retention period, the third parties, and how you would erase it on request. One process, done honestly, will tell you more about your DPDP readiness than any gap-assessment template, and it will tell you within a week rather than a quarter.