DPDP Rules 2025: a compliance map for engineers, not lawyers

India’s DPDP Rules 2025 — the Digital Personal Data Protection Rules — were notified on November 13, 2025. Most coverage since then has been legal analysis: what “Data Fiduciary” means, how the consent framework maps to GDPR, whether the rules adequately protect individual rights.

What’s missing is an engineering view. What does a backend team at an Indian SaaS company actually need to build, and by when? This piece maps those obligations with enough specificity to turn into a project plan. It is not legal advice.

The DPDP Rules 2025 compliance timeline

The rules implement in phases. Two dates govern most of the engineering work:

• November 13, 2026 — the Consent Manager framework becomes operational. Products that integrate with external consent platforms must be ready to receive consent signals through interoperable APIs.
• May 13, 2027 — the full compliance deadline for all Data Fiduciaries. Consent records, erasure workflows, breach notification pipelines, and data minimisation practices must all be in place.

That is 18 months from now for the harder deadline. It sounds comfortable until you account for how long it takes to retrofit consent management onto an existing data model, or design an async deletion job across 40 tables.

Who counts as a Data Fiduciary

A Data Fiduciary is any entity that determines the purpose and means of processing personal data. If your product collects, stores, or processes personal data of Indian users — email addresses, phone numbers, names, device identifiers, and behavioural logs: you are a Data Fiduciary under the DPDP Act.

The rules also define Significant Data Fiduciaries (SDFs): large platforms designated by the government for additional obligations, including Data Protection Impact Assessments, a dedicated Data Protection Officer, and periodic audits. Designation as an SDF hasn’t happened at scale yet. Most startups are not SDFs today, but track whether that changes as the government starts publishing designations.

Consent: from checkbox to audit table

The Act requires consent to be free, informed, specific, unconditional, and unambiguous. A single “I agree to Terms and Privacy Policy” checkbox that bundles account creation with marketing opt-in does not meet this standard.

The practical implication: each distinct purpose for which you process personal data needs a discrete consent record. If you collect an email for login and also want to use it for newsletters, those are two separate consents, each with its own timestamp, notice version, and withdrawal state.

The consent table you’ll need captures: user identifier, purpose code, consented_at, notice_version, and withdrawn_at. Withdrawal must be as easy to execute as giving consent — a preferences page buried four menus deep won’t satisfy the requirement.

If you’ve never done a consent audit — a list of every place in your product where personal data is collected, and what the user specifically agreed to at each point — that is the first piece of work. It almost always turns up collection points that nobody remembers adding.

Erasure and the 48-hour pre-deletion notice

The right to erasure means Data Principals can request deletion of their personal data, and the Data Fiduciary must delete it when the original purpose is fulfilled or consent is withdrawn.

The engineering challenge is that “delete the user’s personal data” rarely means removing a single row. It means identifying every table that holds personal data linked to that user (orders, events, support tickets, audit logs, analytics) and deciding, for each, whether to delete or anonymise. Anonymising a record removes identifiability while preserving aggregate integrity: a support ticket can usually retain its text if the user’s name and email are replaced with a pseudonym.

This work needs to be asynchronous. A deletion request spanning 40 tables can’t complete in a synchronous API call. You’ll need a job queue, a record tracking deletion progress per table, and an audit log of what was deleted and when, so you can demonstrate compliance if asked.

Breach notification: 72 hours to the Data Protection Board

A personal data breach must be reported to the Data Protection Board of India within 72 hours of the Data Fiduciary becoming aware of it. Affected Data Principals must also be notified.

The 72-hour window starts when you become aware, not when the breach occurred. Detection coverage matters: if a breach surfaces through a third-party security researcher at 11pm on a Friday, the clock starts then.

What you need before an incident: a breach response runbook specifying who to escalate to, what information to assemble (data affected, user count, probable cause, containment steps), and how to submit to the DPBI. A template notification for affected users reduces the time between “we found something” and “messages sent.” The affected-user identification step (figuring out exactly which accounts are in scope) requires the same data mapping that underpins the erasure workflow.

Data minimisation: only collect what you can justify

The minimisation principle says you should only collect personal data necessary for the specified purpose. In practice, most products collect more than they actively process.

The value of minimisation is that it shrinks every other compliance surface. Less data to secure, less data to include in erasure workflows, less data to account for in a breach notification. A lightweight data inventory (a list of each personal data element, its stated purpose, and which system stores it) makes every other DPDP obligation easier and is useful if you’re ever audited.

The process change is: at any new feature that introduces personal data collection, document the purpose at build time. That decision is much harder to reconstruct six months later, and “we collect it because we might want it someday” is not a valid purpose under the Act.

Consent Manager interoperability by November 2026

Consent Managers are registered intermediaries that let users manage their consents across multiple Data Fiduciaries from a single platform, similar in concept to the Account Aggregator framework in financial data sharing. From November 2026, users may exercise consent rights through a Consent Manager rather than directly in your product’s interface.

The technical implication: your consent management layer needs to be externally callable, not only accessible through your own UI. The interoperability API specification hasn’t been finalised yet, but building a clean consent API (endpoints to record consent, check status, and process revocations) positions you to add external access when the standards land. If consent logic is currently scattered across view code and background jobs, untangling it takes longer than the integration itself.

Where to start

In order of priority:

1. Data mapping. Before you can design erasure, minimisation, or breach response, you need a list of what personal data you process and where it lives in your systems. A spreadsheet is fine to start.
2. Consent audit. Walk through every collection point in your product. Does each have a specific, documented purpose? A discrete consent record? A working withdrawal path?
3. Erasure design. Identify every table that holds personal data. Decide what gets deleted versus anonymised. Design the async job, the progress tracking, and the audit log.
4. Breach runbook. Write the escalation path, the template notification, and the DPBI submission process now, before you need it.
5. Inactivity tracking. Add last_active_at to user records and model the deletion notification flow, even if you are below the Third Schedule thresholds today.
6. Consent API layer. Move consent management into a callable API so you are ready for Consent Manager integration by November 2026.

The rules are live. The deadline is fixed. The teams that map this work now are the ones that won’t be running a compliance sprint in Q1 2027.