India's Digital Personal Data Protection Rules were notified on 14 November 2025, starting an eighteen-month transition that ends on 13 May 2027. Between those two dates sit deadlines that most companies have not put in a plan, and penalties at the end of it reaching up to ₹250 crore for serious violations. The reason to act now is not the final date - it is that the engineering work involved has a longer lead time than the calendar suggests.
The nearest deadline is this November. The one-year mark on 13-14 November 2026 ends the soft-enforcement phase, and the specific obligation attached to it is legacy data revalidation: personal data you already hold must be supported by notice and consent that meet the standard of the Act. That is the requirement teams consistently underestimate. It is not a policy document - it means going through data collected under older terms and establishing, record by record, whether you have a lawful basis to still be holding it. If the honest answer for some of it is no, deletion is part of the work, and deletion is difficult in systems that were built assuming data is kept forever.
Before that, through mid-2026, the Consent Manager framework becomes operational. If your product collects personal data from Indian users, your systems need to be able to talk to Consent Manager APIs - which for most teams means consent stops being a checkbox stored in a user record and becomes a service with its own state, history and audit trail.
Then in the first quarter of 2027, the first mandatory audit cycle begins for Significant Data Fiduciaries, requiring independent data auditors and Data Protection Impact Assessments. Whether you are classified as one depends on volume and sensitivity, but the practical point is that if there is any chance you qualify, the evidence has to already exist by then. Audits do not accept retrospective documentation.
Translated into engineering terms, four things need to be true of your systems, and none of them is quick. You need a data inventory that says where personal data lives, including the copies in analytics warehouses, log files and backups that inventories usually miss. You need deletion that actually works end to end, including those same downstream copies. You need retention policy enforced by code rather than by intention. And you need access logging good enough to answer who looked at a given person's record, and when.
The sequencing we would suggest, if you are starting now: inventory first, because you cannot make promises about data you cannot locate. Then retention and deletion, because they are the longest lead-time items and they reduce the size of every other problem - data you no longer hold is data you no longer have to revalidate, audit or protect. Consent architecture next, then the audit evidence layer. Teams that start with a policy document and leave the engineering until the end tend to arrive at the deadline with excellent documentation of systems that cannot do what the documentation claims.
One reassurance worth stating: if you have already built to GDPR, a substantial amount of this maps across - lawful basis, data subject rights, breach notification and purpose limitation are recognisably the same concepts. The gaps are typically consent manager interoperability and the legacy revalidation requirement, which has no direct GDPR equivalent.
