DPDP Rules 2025 The complete compliance checklist for companies to follow.

There's a pattern that repeats itself every time India releases major regulatory guidance. Legal teams file it away. Compliance teams put it on the next quarter's agenda. Product and tech teams hear about it in a forwarded email. And somewhere in the middle, nobody is actually doing anything.

The DPDP Rules, 2025 deserve a different treatment — not because they're more complex than previous regulations (they aren't), but because the obligations they introduce are operational, not just documentary. You can't satisfy them with a PDF policy uploaded to a dark corner of your website. You need working systems, starting with real DPDP consent management 

This is a plain-language checklist of the 10 obligations that matter most for DPDP compliance, written for the people who actually have to build or procure what compliance requires, not just the ones who sign off on it.

What are the top 10 Key Obligations Every Data Fiduciary Must Know

Obligation 01

Consent notices must be readable by actual humans

The Rules are specific: consent notices must be written in plain language. Not "plain language" as lawyers define it — plain language as an ordinary user on a mobile app would understand it. No passive voice constructions. No definitional cross-references. No phrases like "as may be applicable under the Act."

This matters more than organisations seem to realise. The default instinct when writing consent notices is to protect the company, which leads to dense, defensively drafted language that users scroll past without reading. The Rules flip that. A notice that users can't understand isn't a valid notice at all.

Language requirement: If your platform serves users across linguistic regions in India, the Rules require notices in all 22 Scheduled languages. For most large consumer apps, this isn't optional — it's a baseline. And it needs to include what data is collected, the purpose, and who will process it.

Worth asking: when was the last time someone on your team actually read your consent notice as a user — not as a legal reviewer?

Obligation 02

One checkbox for everything is gone

The blanket consent model — where ticking a single box on signup implies agreement to marketing, fraud prevention, analytics, and everything else — doesn't work anymore. The Rules require per-purpose consent. Each distinct processing purpose needs its own consent item, individually grantable and individually revokable. This is the core of what real DPDP consent management looks like operationally, not just as a policy statement. 

This changes product design in a meaningful way. Most consent flows were built for legal coverage, not for user granularity. Rebuilding them means disaggregating purposes that were previously bundled, creating separate consent records per purpose, and figuring out what happens to existing data when a user revokes one purpose but not another.

Real implication: If you collect data for marketing, order fulfilment, and fraud detection, those are three separate consent decisions — not one. And each one must be toggleable independently. For a closer look at how this plays out in a high-volume retail context, see DPDPA for e-commerce: customer data, marketing consent, and checkout compliance. 

Obligation 03

Consent withdrawal must be effortless — not buried

The Rules are precise here in a way that's hard to wriggle around: the mechanism to withdraw consent must be as easy to use as the mechanism to give it. If consent is given with a single tap at signup, withdrawal must also be a single tap — not a support ticket, not a settings screen buried four levels deep, not a form that requires email confirmation.

This is one of the obligations where the gap between what platforms currently have and what they need is widest. Most apps have a buried "manage preferences" page that was built to technically satisfy GDPR-influenced thinking and was never really designed to be found. That won't cut it here.

The "immediate effect" clause is also worth taking seriously. When consent is withdrawn, the processing must stop. Not at the next batch cycle. Not when the data warehouse is refreshed. Immediately  which means the architecture needs to support real-time consent state propagation across every system that touches that data.

This is the one most engineering teams underestimate. The UI change is straightforward; the backend propagation across multiple systems is not.

It's also closely tied to a Data Principal's broader rights under the Act — see our breakdown of Data Principal rights under DPDPA: access, correction, erasure, and nomination explained for the full picture of what withdrawal connects to. 

Obligation 04

Self-declared age isn't consent for children's data

For users under 18, the requirement is verifiable parental or guardian consent before any personal data is collected. The word "verifiable" is doing a lot of work here. Asking "Are you over 18?" with a yes/no button is not verification. It never was. The Rules explicitly close this loophole.

What counts as verifiable is going to be a contested question as enforcement develops. But the direction is clear: platforms need actual mechanisms — not declarations — before they collect data from minors. For consumer brands that have historically relied on age gates, this means a genuine rethink of onboarding flows.

Which sectors feel this most: Gaming, social media, ed-tech, fast fashion, and any brand-to-consumer platform with a broad demographic reach. If minors are plausibly using your product, you need a plan.

Obligation 05

Breach notification: two audiences, specific timelines

Under the DPDP Rules, 2025, breaches must be reported to two parties: the Data Protection Board of India, and each affected Data Principal individually.

The Rules specify both the timelines and the required content of those notifications. Getting either wrong  too late, wrong format, missing required information  is itself a separate violation.

The instinct during a breach is usually to buy time: understand the full extent, run legal review, coordinate PR. The Rules don't accommodate that instinct. They require reporting based on what is known at the time, not after full forensic investigation. This means the incident response process needs to be documented in advance  not improvised in the moment.

Individual notification is the part most organisations haven't thought through. If 200,000 customers were affected, that's 200,000 notifications to send  in plain language, with specific content. The operational infrastructure to do that, at scale, quickly, needs to exist before the breach happens. This is especially acute in sectors handling sensitive data — see DPDPA for healthcare: sensitive personal data, patient consent, and DSAR rights for how breach exposure compounds when the data itself is sensitive. 

Obligation 06

Security safeguards are technical requirements, not policy statements

The Rules specify what security safeguards must include: access controls, encryption, and regular security audits. This is important because "we have a security policy" has historically been considered good enough for compliance purposes. It isn't anymore — the requirement is for implemented controls, not documented intentions.

Access controls means role-based access with audit logs. Encryption means at-rest and in-transit, across all systems that hold personal data — including the CRM, the analytics tool, the legacy ERP, and the backup storage that nobody's touched in three years. Regular audits means a schedule, not "we'll do it when something goes wrong."

The common gap: Most organisations have good security on their primary systems and almost no controls on the peripheral ones — the shared drives, the email exports, the data handed to third-party marketing platforms.

Obligation 07

You cannot keep data indefinitely because it might be useful later

Personal data may only be retained for the period necessary for the stated processing purpose. Once the purpose is fulfilled — or consent is withdrawn — deletion is required. The only exception is a specific legal obligation requiring retention.

This sounds straightforward until you map it onto most organisations' actual data infrastructure. Data sits in warehouses without timestamps for when it was originally collected for what purpose. Customer records from ten years ago exist in systems nobody has a clear mandate to delete. Marketing lists were built, never cleaned, and have been handed to three different platforms.

The operational challenge here is purpose-tagging at the point of collection and building retention schedules that actually execute. Not a policy that says "we retain data for three years" but a system that automatically flags and deletes data when the retention period expires. Most data teams have never been asked to build something like that.

This is arguably the obligation that requires the deepest architectural change  not because the rule is complex, but because most organisations genuinely don't know where all their data is.

Obligation 08

The Grievance Officer is a real person, with a real name, and real deadlines

Every Data Fiduciary must designate a Grievance Officer  not a department, not an email alias, but a named individual with published contact details. That officer must acknowledge complaints within 48 hours and resolve them within a defined timeline.

This one is often underestimated because it feels administrative. It isn't. A complaint that goes unacknowledged, or that sits without resolution past the required timeline, becomes an enforcement event. The Grievance Officer function also shapes your relationship with the Data Protection Board  complaints that aren't resolved internally tend to escalate.

Practical note: The 48-hour acknowledgement clock starts the moment the complaint is received  not when it's opened, reviewed, or assigned. Automated acknowledgements don't satisfy the requirement if they're not paired with a real follow-up process.

Obligation 09

Significant Data Fiduciaries carry a heavier load 

Organisations designated as Significant Data Fiduciaries a classification the Central Government will assign based on data volume, sensitivity, and potential harm  face a further tier of requirements: a Data Protection Officer appointment, annual Data Protection Impact Assessments, and independent data audits.

The DPO role here is meaningfully different from a compliance officer who also handles data matters. It's a senior, independent function with a direct reporting line to leadership and actual authority to halt processing decisions that carry unacceptable risk. The DPA model from GDPR jurisdictions gives a rough idea of what this looks like in practice.

Annual DPIAs  covering new processing activities, new products, new partnerships  mean that data protection assessment becomes part of the product development cycle, not something done retrospectively when regulators ask. For organisations that haven't built this into how they work, it's a genuine structural change. This tier of obligation is especially relevant for regulated sectors like financial services  see DPDPA for BFSI: how banks and NBFCs must restructure their consent frameworks. 

Obligation 10

Cross-border transfers require approved jurisdictions — and mapped flows

Personal data can only leave India if it's heading to a jurisdiction approved by the Central Government. The approved-jurisdiction list hasn't been finalised yet  but that's not a reason to delay. The preparatory work you can do right now is to map every cross-border data flow in your organisation.

Most companies operating internationally are surprised by what this exercise reveals. Data flows to AWS or GCP regions outside India. Analytics platforms processing user behaviour data on international servers. Customer service platforms routed through global infrastructure. Marketing tools syncing to US-based CRMs. None of these are inherently prohibited  but none of them are currently mapped, either.

When the approved-jurisdiction list lands, organisations with mapped flows will be able to assess their compliance position quickly. Everyone else will be starting from scratch under pressure.

The only sensible move right now: Start the mapping exercise before you know the final rules. Knowing where your data goes is valuable regardless of what the final list looks like.

Where does this leave most organisations?

Behind, if we're honest.

Not because the DPDP Rules, 2025 are unclear  they're actually more specific than most DPDP guidelines or compliance frameworks India has seen, but because the window between "Rules are published" and "enforcement is active" tends to encourage delay. That window is shorter than organisations tend to assume.

The obligations that are hardest to meet aren't the ones requiring policy documents or officer appointments. Those can be done quickly. The hard ones are the technical obligations: real-time consent propagation, automated data retention and deletion, per-purpose consent records at scale, cross-system security controls, breach notification infrastructure. These require lead time to build, procure, and test.

The question worth asking internally isn't "are we compliant?"  it's "which of these ten obligations would we fail if we were audited tomorrow?" Starting from that answer tends to focus minds in a way that reading the Rules in the abstract does not.