Why India's DPDPA Is Stricter on Consent Than GDPR — and What That Means for Your Business
If your organisation has done GDPR compliance, you might treat India's DPDPA as a near-equivalent. That assumption will cost companies dearly. The DPDPA is consent-first in a way GDPR never was.
If your organisation has already done GDPR compliance work, you might be tempted to treat India’s Digital Personal Data Protection Act as a near-equivalent — a familiar framework with local flavour. That assumption is going to cost companies dearly.
The DPDPA is consent-first in a way that GDPR never was. And that distinction, seemingly academic, has very concrete operational consequences for every business processing personal data of Indian users.
Let’s break this down plainly.
Under GDPR, Consent Is One of Six Legal Bases. Under DPDPA, It’s Almost the Only One.
The General Data Protection Regulation gives organisations six legal grounds for processing personal data: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The last of these — legitimate interests — is the most flexible and the most used by businesses to avoid collecting explicit consent for data processing they believe to be routine and proportionate.
The DPDPA does not offer this flexibility. Its list of non-consent grounds for processing — what the Act calls “legitimate uses” — is narrow and specific: medical emergencies, safety threats, fulfillment of legal obligations, and a small number of similarly well-defined scenarios.
There is no legitimate interests basis under the DPDPA. If you want to process personal data of Indian users for purposes like behavioural analytics, retargeting, personalisation, or any commercial use not directly tied to a service the user has explicitly signed up for — you need consent. Specific, informed, freely given, unconditional, and unambiguous consent.
For businesses that have built their data strategy on GDPR’s legitimate interests as a catch-all, this is a significant architecture change, not a paperwork update.
Consent Withdrawal Triggers Deletion — Automatically
Under GDPR, when a user withdraws consent, an organisation must stop processing personal data on that basis. But data already collected and processed under that consent may still be retained if another legal basis applies.
Under the DPDPA, the moment a data principal withdraws consent, the data fiduciary is legally obligated to delete the data — unless retention is specifically required by another Indian law.
This is not a minor distinction. It means that your systems must be capable of receiving a withdrawal signal and automatically initiating a deletion workflow. It means your data architecture cannot be a monolith where user data is blended across use cases without traceability. And it means your consent management infrastructure must be deeply integrated with your data storage layer — not sitting on top of it as a visual layer.
Consent management, in the DPDPA’s design, is operational infrastructure — not a compliance notice on a web page.
Privacy Notices Must Be Itemised, Not Categorical
GDPR requires organisations to disclose the categories of personal data being collected and the categories of third parties with whom data is shared. This level of abstraction has allowed privacy policies that are technically compliant but practically uninformative — “we may share your data with advertising partners” tells a user very little.
The DPDPA requires an itemised description of the specific personal data being collected, the specific purposes for processing, and the identities of all third parties with whom data is shared — not categories, but actual entities. This level of specificity requires organisations to genuinely understand their own data flows, vendor relationships, and processing activities before they can write a compliant privacy notice.
For many businesses, this exercise alone will be revelatory. Organisations that have never comprehensively mapped what data they collect, who processes it, and why will need to do that work before they can produce a DPDPA-compliant notice. There is no shortcut around this.
Children’s Data: Verifiable Parental Consent Is Non-Negotiable
The DPDPA mandates verifiable consent from parents or legal guardians before processing personal data of minors. The word “verifiable” is doing significant work here — it means organisations cannot simply present a checkbox asking users to confirm they are over 18. They must implement processes that genuinely verify the age of the user and, for minors, obtain authenticated parental consent.
This is an operational challenge that will require integration with identity verification systems and careful UX design. It also has implications well beyond children’s apps — any platform that cannot age-gate its user base needs to think carefully about how it handles this requirement.
What the DPDPA Compliance Stack Actually Looks Like
Given these requirements, here is what organisations genuinely need to build before May 2027 (the date full enforcement begins):
- Consent Infrastructure — A system capable of collecting granular, purpose-specific consent, storing it as an auditable artefact with timestamping, and executing withdrawals and deletions on demand. This is not a cookie banner. This is infrastructure.
- Privacy Notice Redesign — Notices that itemise data collected, purposes, and third-party recipients. This requires a data audit first.
- Automated Deletion Workflows — Systems that can receive a consent withdrawal or a deletion request and propagate it across all storage layers where that user’s data exists.
- Consent Records Management — Seven-year retention of consent artefacts in machine-readable format, accessible to users on request.
- Rights Management — Systems for handling data principal rights requests (access, correction, nomination of a representative) within the 90-day maximum timeframe specified under the Rules.
The DPDPA as a Trust Architecture, Not Just a Legal Obligation
Here is the reframe that matters most: the DPDPA’s consent-first design is not a burden that organisations must tolerate. It is a description of the kind of relationship Indian businesses should be building with their users anyway.
India’s digital economy is entering a new phase. Consumers are more aware of their data rights than they were five years ago. Businesses that build genuine consent-respecting data practices will earn trust that translates into retention, referral, and resilience against regulatory risk. Those that treat compliance as a form-filling exercise will face enforcement — and a brand trust deficit that is harder to recover from than a fine.
The consent-first framework is, at its core, a demand that businesses earn the right to use their customers’ data. That is not a bad standard to build around.
At Consently, we designed our platform for exactly this environment. Built in India, for India’s data protection law — with DPDPA-native consent flows, automated consent lifecycle management, and audit-ready records infrastructure. We are not a GDPR tool with an Indian flag on it.
If your organisation is beginning to work through what DPDPA compliance actually requires — not just the headline obligations, but the operational architecture — we’d be glad to have that conversation.
The DPDPA is not GDPR. It is stricter in the ways that matter most. The organisations that understand this distinction now will be better prepared, better trusted, and more resilient when enforcement arrives.
Want a DPDPA gap assessment for your organisation? Talk to the Consently team →