GDPR vs DPDP: The Complete Comparison for Engineering Teams

India's DPDP Act, 2023 is often called "India's GDPR," which is roughly as accurate as calling a hatchback a sedan because both have four wheels. The two laws share DNA, a data-subject-centric design, a penalty regime, and a consent vocabulary. The differences are where the engineering decisions live.

This comparison is written for teams that build products, because the legal differences translate directly into different data models, different consent UIs, and different operational workflows. It is not legal advice.

The structural difference: legal bases

The biggest divergence is the lawful basis architecture.

GDPR gives controllers six legal bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Consent is one option among six, and in practice many companies process data on legitimate interest without asking anyone.

The DPDP Act does not have six bases. It has consent plus a defined set of "legitimate uses" in Section 7: employment-related processing, state functions, medical emergencies, and data made public by the principal, among others. For a consumer internet company, consent is the ground you will rely on for marketing, analytics, and personalisation.

Engineering translation: GDPR lets you defer consent decisions by leaning on legitimate interest. DPDP pushes far more processing onto the consent path, which makes your consent infrastructure load-bearing.

Notice: when, and in what language

GDPR requires notice at collection, always, with a specified set of information. The DPDP Act ties the notice requirement to consent: when consent is the basis of processing, notice is required.

The Rules add a requirement GDPR does not have: the notice must be in English and in the languages listed in the Eighth Schedule of the Indian Constitution. For a product serving multiple Indian states, notice is a multi-language, versioned system, not a static legal page.

The rights menu

GDPR grants a broad rights suite: access, rectification, erasure, restriction, portability, and objection.

The DPDP Act's rights framework is narrower and more operationally focused. Erasure is the headline right, and the Act's structure suggests deletion is where enforcement energy will concentrate. Other rights exist in the Act's framing, but the operational machinery, verification, fulfilment, evidence, is built around erasure.

| Right | GDPR | DPDP | |-------|------|------| | Access | Yes | Yes | | Rectification | Yes | Yes | | Erasure | Yes | Yes, the operational centre of gravity | | Restriction | Yes | Not a first-class equivalent | | Portability | Yes | Not a first-class equivalent | | Objection | Yes | Not a first-class equivalent | | Withdraw consent | Yes, always as easy | Yes, as easy as giving |

Children's data: 16 vs 18

GDPR sets the child threshold at under 16, with member states free to lower it to 13. The DPDP Act defines a child as anyone under 18, and requires verifiable parental consent for processing a child's data.

There is a sharper edge in the Rules: behavioural monitoring and targeted advertising directed at children are prohibited, not consent-gated. That is a hard product constraint, not a form-filling exercise.

Breach notification: 72 hours and the CERT-In complication

GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a breach. The DPDP Rules require notifying the Data Protection Board within 72 hours and notifying affected individuals.

The complication India adds: CERT-In's incident reporting rules require reporting certain security incidents on a different, shorter timeline. A single breach can trigger two notifications with two clocks and two authorities. Teams need a runbook that covers both, because the DPB clock and the CERT-In clock start at the same event.

Penalties

GDPR fines can reach 4% of global turnover or €20 million, whichever is higher. The DPDP Act caps at ₹250 crore per violation under Section 33, with the Board determining the amount by gravity, duration, and cooperation.

For an Indian startup, the DPDP ceiling is the more relevant number, and it is high enough to matter. The penalties post goes deeper on how the regime is likely to be enforced.

Extraterritorial scope

GDPR applies to any organisation processing data of EU residents, wherever the organisation is. The DPDP Act applies to processing of Indian data principals' data, with carve-outs including publicly available data. If you are an Indian company with EU users, or an EU company with Indian users, you can be inside both regimes, which is its own engineering problem. Our GDPR for Indian companies post covers that intersection.

The comparison table

| Dimension | GDPR | DPDP | |-----------|------|------| | Lawful bases | Six | Consent + defined legitimate uses | | Notice | Always at collection | When consent is the basis | | Notice language | Member state languages | English + Eighth Schedule languages | | Consent test | Freely given, specific, informed, unambiguous | Free, specific, informed, unconditional, unambiguous | | Child threshold | Under 16 (13-16 by state) | Under 18 | | Parental consent | Required under threshold | Verifiable parental consent | | Breach notification | 72 hours to authority | 72 hours to Board + individuals; CERT-In adds a separate clock | | Rights | Access, rectification, erasure, restriction, portability, objection | Erasure-centric operational framework | | Penalty ceiling | €20m or 4% global turnover | ₹250 crore per violation |

What the differences mean for building

For a product team, the differences resolve into a few concrete decisions:

1. Consent infrastructure is load-bearing under DPDP because there is no legitimate-interest fallback for most consumer processing
2. Notice needs versioning and multi-language support from day one
3. Erasure is the right to build for first, with verification and evidence
4. The breach runbook must cover DPB and CERT-In clocks together
5. If you have EU users, you are building for both regimes, and the overlap is not 1:1

That is the shape Erasure is built in: Accord for consent with versioned notice and receipts, Rights for erasure with verification and durable jobs, Data Maps for inventory, Systems for fulfilment across Postgres, MySQL, HTTP, and Webhook, and Evidence for exportable proof.

The bottom line

GDPR and DPDP are cousins, not twins. The DPDP Act is narrower on legal bases, stricter on consent, different on children, and erasure-centric on rights. Teams that build to the DPDP test, rather than porting a GDPR design, will spend less time retrofitting.

The compliance checklist turns the DPDP side into work items, and the consent under DPDP post covers the consent test in detail.