DPDPA vs GDPR: seven differences that change what you build

Most DPDPA-versus-GDPR comparisons are written for lawyers and stop at the statutory contrast. That is useful once. What teams actually need is the shorter list: the places where the two regimes differ enough that the same system cannot satisfy both without a change.

There are seven. Everything else is close enough that a well-built GDPR programme transfers.

1. No legitimate interest basis#

This is the difference with the largest engineering consequence, and it is routinely underestimated.

GDPR gives you six lawful bases, and legitimate interest carries an enormous amount of real-world processing: fraud detection, network security, product analytics, direct marketing to existing customers, internal administration. You complete a balancing assessment, document it, and proceed.

DPDPA has no equivalent. You process on consent, or you fall within a listed legitimate use — a narrower, enumerated set covering things like the data principal voluntarily providing data for a specified purpose, employment purposes, medical emergencies, and compliance with law.

The practical effect: processing that sat comfortably under legitimate interest in your GDPR programme now needs either a consent path or a defensible fit within a listed use. That is not a policy change. It is a change to what your consent screen asks for, what your consent record stores, and what happens downstream when the answer is no.

2. Notice is a product surface, not a document#

GDPR transparency is satisfied by a well-structured privacy notice: layered, narrative, usually one language with translations available.

DPDPA requires the notice to be itemised — a clear enumeration of the personal data collected and the specific purpose for each — and available in English or any language in the Eighth Schedule to the Constitution, at the data principal's option.

That final phrase does the work. The choice belongs to the individual at the point of collection, which means your application must offer it. A footer link to a translated PDF does not satisfy this.

Building it properly means notice content stored as structured data keyed by purpose and language, a language selector present wherever consent is captured, a release process that blocks a new data field shipping before its notice entry exists in every offered language, and version pinning so you can prove what a specific person saw on a specific date.

3. The children's threshold is 18#

GDPR sets the digital consent age between 13 and 16 depending on the member state. DPDPA sets it at 18 and requires verifiable parental or guardian consent below it.

For an Indian consumer platform this is a materially larger affected population, and it forces four capabilities most products do not have: reliable age determination, identification of a parent or lawful guardian, a verification mechanism that is genuinely verifiable rather than a self-declaration checkbox, and a retained auditable record of that verification.

Additionally, tracking, behavioural monitoring and targeted advertising directed at children are prohibited outright. For an ad-funded product that is a product architecture question, because you must be able to suppress those systems reliably for a subset of users.

4. The breach duty has no materiality filter#

Under GDPR Article 33 you notify the supervisory authority unless the breach is unlikely to result in a risk to rights and freedoms. Article 34 requires notifying individuals only where there is a high risk. Two thresholds, both filtering.

DPDPA's obligation to intimate affected data principals is not conditioned on a risk assessment. A lost encrypted laptop with 400 customer records that you would have documented-and-closed under GDPR should, on the safe reading, be notified under DPDPA.

That changes three things beyond the privacy team: notification volume, the need for pre-approved customer communications because low-severity notifications become routine, and detection coverage — if you must notify on everything, incomplete logging becomes a compliance exposure rather than an operational inconvenience.

And it sits on top of CERT-In's separate six-hour reporting window, with its own trigger list and recipient.

5. The rights sets are not the same#

DPDPA gives data principals access to a summary of processing, correction and completion, erasure, grievance redressal, and nomination — the right to appoint another individual to exercise rights in the event of death or incapacity. That last one has no GDPR equivalent and needs a data model change: a nominee record, a verification path, and an activation trigger.

GDPR gives data subjects several rights DPDPA does not: portability in a structured machine-readable format, restriction of processing, objection including to profiling, and rights relating to solely automated decision-making with legal or similarly significant effects.

If you built for GDPR, you have surplus capability plus one gap. If you built for DPDPA and then expand into the EU, you have four capabilities to add — and portability in particular is real engineering work.

6. Cross-border transfer runs the opposite way#

GDPR restricts transfers by default and permits them by exception — adequacy decision, Standard Contractual Clauses plus a transfer impact assessment, binding corporate rules.

DPDPA permits transfers by default and restricts by exception: transfer is allowed to any country other than those the Central Government restricts by notification. That is a permissive baseline, and organisations often relax at this point.

They should not, for two reasons. Sectoral regulators impose their own localisation rules that continue to apply independently — RBI for payment data, IRDAI for insurance, and others. And the permissive list can change by notification, so an architecture that assumes a specific destination remains available is carrying a risk nobody has priced.

7. Accountability is documented differently#

GDPR's accountability principle requires you to demonstrate compliance, and Article 30 prescribes the records format. That single provision is why GDPR programmes are documentation-heavy.

DPDPA places its heaviest accountability obligations on Significant Data Fiduciaries specifically: an India-based DPO accountable to the board, an independent data auditor, and periodic Data Protection Impact Assessments and audits. Below that designation the documentation burden is lighter.

The practical consequence is that a GDPR-grade documentation set over-satisfies DPDPA for most organisations, while a DPDPA-minimum set will not survive a GDPR accountability challenge.

Building one programme for both#

The temptation is to build to the intersection. That produces a programme compliant with neither.

Build to the union, with these decisions:

What actually transfers#

If you already run a mature GDPR programme, roughly 70% carries across directly: data inventory, rights operations infrastructure, processor contracts, security safeguards, breach response mechanics and DPIA methodology.

The 30% that does not is concentrated in exactly the places above — consent scope, multilingual notice, age verification, breach triggers and nomination. That is a real programme of work, typically eight to fourteen weeks of engineering, and it is the part organisations discover late because the legal analysis says "broadly similar."

It is broadly similar. It is not the same, and the differences sit in the product rather than in the policy.

Our Privacy Engineering & Data Protection practice runs dual-regime programmes, and the DPDPA Readiness Checklist sets out 96 operational checkpoints with the evidence each one requires.