DPDP Rules 2025 Explained: What Changed and What You Must Do

The Digital Personal Data Protection Rules, 2025 were notified on November 13, 2025 (G.S.R. 846(E)). They turn the DPDP Act, 2023 from a framework into an operating manual, and they arrived with a phased timeline that ends in penalty enforcement. If you have been treating the Act as a future problem, the Rules are the point where it became a current one.

This post translates the Rules into concrete engineering and product work. It is not legal advice; it is an operational reading, grounded in what the Rules actually say and what a product team can build this quarter.

The phased rollout

The Rules did not all switch on at once. The government staged them:

| Phase | What takes effect | When | |-------|-------------------|------| | 1 | Data Protection Board constituted; core framework live | November 13, 2025 | | 2 | Consent Manager registration window opens | November 13, 2026 | | 3 | Full operational provisions, including penalties | Expected May 2027 |

That eighteen month runway between notification and enforcement is the window every Indian product company gets to build the machinery. It sounds generous until you price the work: notice redesign, consent re-architecture, data inventory, deletion workflows, audit logs. None of it is a weekend task.

Rule 3: notice requirements

Notice under the DPDP Act is only required when consent is the basis of processing, but when it is required, it has specific content: identity of the fiduciary, purposes of processing, the data principal's rights, and how to make a complaint.

The Rules add a practical wrinkle: the notice must be in English and in the languages listed in the Eighth Schedule of the Constitution. For a product shipping across India, that means notice is a localisation exercise, not a legal drafting exercise. Your consent infrastructure needs to serve the right language to the right user and record which version they saw.

Section 6: the five conditions of consent

Consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action. The Rules tighten the practical details:

• Pre-ticked boxes are out
• Consent for one purpose cannot be bundled into consent for another
• Withdrawal must be as easy as giving consent
• Separate, specific consent is needed for separate purposes

Engineering translation: your cookie banner or consent widget cannot be a single "Accept" button anymore. It needs purpose-level granularity, per-purpose toggles, a withdrawal path that is equally reachable, and a record of each choice that survives audits.

Rule 6: security safeguards

The Rules require reasonable security safeguards, and they get specific about what that means: encryption, access controls, and a retention floor of one year for logs of systems processing personal data.

For most startups this is not exotic. It means TLS everywhere, secrets management instead of env-file sprawl, role-based access control on your internal tooling, and log retention that does not rotate personal-data-processing logs after thirty days.

Rule 7: breach notification

When a personal data breach occurs, the Rules require notifying the Data Protection Board within 72 hours and notifying affected individuals. The clock runs from knowledge of the breach.

There is a coordination problem here that nobody talks about enough: CERT-In's incident reporting rules have their own six-hour timeline for certain incidents. A breach can trigger two notifications with two different clocks and two different authorities. Product teams need a runbook that handles both, not one.

Rule 13: Significant Data Fiduciaries

The central government can designate certain fiduciaries as Significant Data Fiduciaries (SDFs) based on volume, sensitivity, and risk factors. SDFs carry extra duties:

• Data Protection Impact Assessments (DPIAs)
• Periodic data audits
• An India-based Data Protection Officer
• Algorithmic due diligence for systems that use personal data

If you are a healthtech platform, a large consumer app, or a fintech with substantial volumes, plan for SDF status even before designation. The evidence trail you build for it, DPIAs, audits, DPO appointment, is useful regardless of whether the government names you.

What this means for your roadmap

Lay the Rules next to your product roadmap and the honest list looks like this:

1. Notice builder that supports multiple languages and versioned publication
2. Consent collection with per-purpose granularity and withdrawal parity
3. Receipts that pin what the user saw and chose, stored immutably
4. A data inventory: which systems hold personal data, and what identifiers map to a person
5. A deletion request workflow with verification, fulfilment, and audit
6. Security basics: encryption, access control, one-year log retention
7. A breach runbook that covers both the DPB 72-hour clock and CERT-In

That is a substantial build. It is also exactly the kind of infrastructure that does not belong in a spreadsheet. This is why we built Erasure: notice and consent in Accord, deletion and evidence in Rights, inventory in Data Maps, and durable fulfilment across Postgres, MySQL, HTTP, and Webhook systems.

The honest bottom line

The Rules are not a suggestion. The phased timeline means enforcement is coming, and the penalty regime caps at ₹250 crore under Section 33 of the Act. Startups do not need an enterprise compliance team to act, but they do need the operational machinery in place before the clock runs out.

If you want the itemized version, our DPDP compliance checklist turns this into a tick-box list. For the enforcement dates themselves, see our DPDP timeline post. And if you are weighing this against GDPR obligations, the GDPR vs DPDP comparison shows where the two laws diverge.