India's DPDP Act and What It Means for Your Compliance Stack

The Digital Personal Data Protection Act, 2023 is no longer a future problem — the rules are being phased in and enforcement is coming. Here's what actually changes for the tools and processes you rely on today.

If you have been postponing discussing the data protection law in India due to the purported incompleteness of the law, you can stop doing that. The Digital Personal Data Protection Act, which was passed in August 2023, is India's first real personal data law, and the Ministry of Electronics & IT is consistently releasing the DPDP Rules in order to implement the legislation. Any company interacting with the personal data of Indian citizens, whether you are based in Bengaluru or Boston, must start considering such law because it defines everything from how to collect phone numbers and keep photographs to how to act when someone contacts you to delete their accounts.

The DPDP Act differs from endless compliance checklists many companies know, in that it demands more than just writing better privacy policies; it also requires the company to prove that the consent was valid, the data is used only according to its purpose, and that it is able to react quickly when any violation occurs. That's a different problem, and it lives in your compliance stack, not just your legal drawer.

What the DPDP Act Actually Covers

Strip away the legal language and the DPDP Act rests on a few simple ideas. It applies to any "digital personal data" — information about an identifiable person that's processed in digital form, or collected offline and later digitised. It applies inside India, and outside India too, if the processing relates to offering goods or services to people in India. There's no revenue threshold and no small-business carve-out for the core consent obligations, which surprises a lot of startups who assume the law is aimed only at Big Tech.

The Act organises everyone into roles, and your obligations depend entirely on which one you are:

• Data Principal — the individual the data is about, who now has enforceable rights to access, correct, and erase their data.
• Data Fiduciary — the organisation that decides why and how personal data is processed. This is most businesses reading this article.
• Significant Data Fiduciary (SDF) — a category the government can designate based on data volume, sensitivity, or risk to sovereignty, which triggers extra duties like appointing a Data Protection Officer based in India and running periodic audits.
• Consent Manager — a new, registered intermediary role that lets individuals manage and withdraw consent across multiple companies from one place.

The Core Obligations, in Plain Terms

Most of the law comes down to five operational demands. None of them are exotic on their own, but stacked together they require real engineering and process work, not just a rewritten privacy notice.

Table 1 — Core DPDP obligations and what they demand in practice

What This Means for Your Compliance Stack

Here's the part legal teams often miss: the DPDP Act can't be satisfied with policy documents alone. Regulators and courts will ask for evidence — logs, timestamps, audit trails — and that evidence has to come from your systems. In practice, this means rethinking five layers of your stack.

1. Consent infrastructure

A cookie banner isn't consent management anymore. You need a system that captures granular, purpose-specific consent, timestamps it, lets people withdraw it as easily as they gave it, and propagates that withdrawal to every downstream system — your CRM, your analytics tools, your marketing platform — not just your website.

2. Data mapping and discovery

You cannot honour a deletion request for data you don't know you have. Before anything else, most teams need an honest inventory of where personal data lives: production databases, data warehouses, support tickets, backups, and the dozen SaaS tools that quietly collect emails and phone numbers.

3. Rights-request DSAR workflows

Access, correction, and erasure requests need a defined intake, verification, and fulfilment process with a service-level clock running. Manually hunting through spreadsheets when a request lands is not a strategy once volumes grow.

4. Breach detection and response

Because notification windows are short, detection has to be fast and the escalation path has to be rehearsed, not improvised. This is where security tooling and privacy tooling finally have to talk to each other.

5. Vendor and processor governance

Every processor handling data on your behalf needs a contract that mirrors your DPDP obligations, plus some way to actually verify they're keeping their end of it — not just a signature on file.

DPDP Act vs. GDPR: How Different Is It, Really?

Teams that already built a GDPR programme have a head start, but the two laws aren't identical twins. A few differences matter enough to change your roadmap.

Table 2 — Quick comparison for teams migrating a GDPR programme to DPDP

Building a Practical Roadmap

None of this needs to happen overnight, but it does need to start now. A workable sequence looks like this: first, run a data-mapping exercise so you know exactly what personal data you hold and where. Second, audit your current consent flows against the "clear, itemised, revocable" standard and fix the gaps. Third, stand up or formalise a DSAR process with a real turnaround clock. Fourth, pressure-test your breach response plan with a tabletop exercise. Finally, work through your vendor contracts one by one, starting with whoever handles your most sensitive data.

The organisations that treat this as a one-time documentation exercise will be the ones scrambling when the Data Protection Board starts asking for evidence. The ones that treat it as infrastructure — something that lives in code, logs, and workflows, not just policy PDFs — will find that DPDP compliance becomes close to automatic.

The Bottom Line

The DPDP Act rewards teams that build privacy into their systems rather than bolting it on afterward. Start with knowing your data, then work outward — consent, rights requests, breach response, vendors. Everything else follows from that foundation.