DPDP Act vs GDPR

DPDP Act vs GDPR: What Your Existing Programme Doesn't Cover

By Yatin Chaudhary, SEO Specialist at ProtectComply · Last updated 5 August 2026 · 13 min read

Quick answer

GDPR compliance gets you a meaningful head start on DPDP — and leaves seven things you must build from scratch.

The philosophical alignment is real. Both laws treat privacy as a right, place accountability on the organisation, and require notice, consent and rights fulfilment.

But six artefacts in a mature GDPR programme are invalid under the DPDP Act, not merely incomplete:

1. Any processing justified on legitimate interest
2. Your sensitive data classification tiers
3. Your children's data threshold
4. Your breach materiality filter
5. Your notice, in every language you have it in
6. Your cross-border transfer mechanism

Plus one thing GDPR has no equivalent for at all: Consent Manager interoperability.

Everything else — your RoPA discipline, DPIA methodology, processor contract framework, rights request workflows, security safeguards — carries over with adjustment rather than replacement.

Below is what to rebuild and why.

Rebuild 1: Legitimate interest processing

This is the largest single item, and most teams underestimate it.

GDPR gives you six lawful bases. Legitimate interest is the flexible one, and mature programmes lean on it heavily — fraud prevention, direct marketing to existing customers, network security, internal analytics, group-company data sharing.

The DPDP Act has no legitimate interest basis. Processing rests on consent, or on specific "legitimate uses" the Act enumerates — things like state provision of benefits, medical emergencies, employment purposes, and a defined set of others.

Note the difference in kind. GDPR's legitimate interest is a balancing test you apply to novel situations. DPDP's legitimate uses are a closed list. If your processing does not fit an enumerated use, you need consent. There is no argument to make.

What to do: pull every processing activity in your RoPA where the lawful basis is legitimate interest. For each, determine whether it maps to an enumerated legitimate use. If it does not, you need a consent flow — which means a purpose in your notice, a capture mechanism, an artefact, and a withdrawal path.

This is usually the single largest work item in a GDPR-to-DPDP transition, and it is the one that most often gets discovered late because "we have a lawful basis for everything" feels like a solved problem.

Rebuild 2: Sensitive data classification

GDPR defines special categories — health, biometrics, religious belief, political opinion, sexual orientation, trade union membership — with heightened conditions attached.

The DPDP Act has no equivalent taxonomy. All personal data is personal data.

Two consequences, pulling in opposite directions.

Processing you treated as high-friction under GDPR because it touched special categories is not automatically more restricted under DPDP. But processing you treated as routine gets no relief either — the obligations apply uniformly.

What to do: your GDPR data classification tiers do not map to DPDP obligations. You still want risk-tiering internally, because harm to individuals is not uniform and your security safeguards should reflect that. But do not assume DPDP obligations scale with your GDPR sensitivity labels. They do not.

Rebuild 3: Children's data threshold

Under GDPR, the digital consent age is 16, with member states permitted to lower it to 13. Most GDPR programmes are built around 13 to 16 depending on market.

Under the DPDP Act, a child is anyone under 18, uniformly.

For an Indian consumer business this is an enormous cohort shift. Users who are ordinary data principals under GDPR require verifiable parental consent under DPDP. Tracking, behavioural monitoring and targeted advertising directed at them are restricted.

Children's data violations sit near the top of the penalty schedule.

What to do: re-run your age-gating logic against an 18 threshold. Build verifiable parental consent, which is a harder engineering problem than age declaration. And audit your advertising and analytics stack for what fires on users you now classify as children.

Rebuild 4: Breach materiality filter

Under GDPR you notify the supervisory authority within 72 hours unless the breach is unlikely to result in risk. You notify affected individuals only where risk is high. That risk assessment is a real filter — most breaches never reach individual notification.

Under the DPDP Act, affected individuals must be notified of breaches — the risk-based filter GDPR gives you is not available in the same form.

What to do: your breach playbook's decision tree is the artefact to rebuild. The GDPR version optimises for deciding whether to notify. The DPDP version has less to decide and more to execute, at higher volume, faster.

Note also that CERT-In's directions run in parallel and require certain cyber incidents to be reported within six hours. Your incident response has two clocks, not one.

Rebuild 5: Notice, in every language

GDPR requires notice in clear, plain language. It does not impose a multilingual constitutional requirement.

The DPDP Act requires notice available in English or any language in the Eighth Schedule to the Constitution — 22 languages — at the Data Principal's option.

This is not a translation project you bolt on at the end. It is a product requirement. Your notice must be deliverable in the chosen language, at the point of collection, and you should be recording which language was actually served against each consent artefact. Most global consent platforms ship English and a handful of European languages.

What to do: treat language coverage as a platform capability when evaluating tooling, and as a field in your consent record. Ask vendors to count the supported languages. "Multilingual" is not an answer.

Rebuild 6: Cross-border transfer mechanism

Here the DPDP Act is more permissive than GDPR — which creates its own trap.

GDPR restricts transfers to third countries without an adequacy decision, requiring SCCs, BCRs or a derogation.

The DPDP Act permits transfers by default and empowers the Central Government to restrict transfers to notified territories. A blacklist rather than a whitelist.

The trap: your GDPR SCCs are a GDPR instrument. They do not automatically discharge DPDP transfer obligations, and mechanisms recognised under one regime are not assumed under the other.

What to do: do not assume your existing transfer paperwork covers India. And note that DPDP's permissiveness does not override sectoral requirements — RBI's payment data localisation mandate continues to apply within its own scope regardless.

Build from nothing: Consent Manager interoperability

GDPR has no analogue. India built a federated consent ecosystem, drawing on the Data Empowerment and Protection Architecture framework and the Account Aggregator model already running in Indian finance.

A registered Consent Manager gives individuals one interface to grant, review and withdraw consent across many organisations. Registration opens 13 November 2026.

You will almost certainly never register as one. You will need to interoperate with them — accepting and honouring consent signals that originate outside your own interface.

What to do: treat this as a roadmap item now rather than an integration scramble in 2027. Ask consent platform vendors what their interoperability plan is.

What carries over

Not everything is rebuild. Your GDPR investment holds real value here.

Your RoPA discipline. GDPR Article 30 records need India-specific fields added — Eighth Schedule language coverage, consent artefact location, withdrawal propagation path — but the register itself and the practice of maintaining it transfer directly. Our RoPA guide covers what to add.

Your DPIA methodology. The analytical approach transfers. The trigger does not — GDPR triggers on high-risk processing, DPDP on entity classification as a Significant Data Fiduciary. Which means the scope is potentially far larger. Our DPIA guide covers that difference.

Your processor contract framework. Terms need reviewing against DPDP obligations, but the vendor governance discipline is the same discipline.

Rights request workflows. DPDP grants access, correction and erasure. It has no data portability right and no explicit right to be forgotten in GDPR's broad form. But it adds one GDPR lacks — the right to nominate another individual to exercise your rights in the event of death or incapacity. Small, easily missed, and genuinely novel.

Security safeguards. Encryption, access control, logging. Same controls, and the ₹250 crore penalty head makes them the most expensive thing to get wrong.

The penalty inversion

Worth understanding because it changes who should worry most.

GDPR fines are the higher of €20 million or 4% of global annual turnover. Percentage-based, so they scale with the organisation.

DPDP penalties are fixed maxima — up to ₹250 crore for security safeguard failures, with separate heads for breach notification, children's data and SDF obligations. Not turnover-linked.

A large multinational faces a lower ceiling under DPDP than under GDPR. A mid-sized Indian company faces the same ceiling as that multinational.

Proportionally, DPDP hits smaller organisations harder than GDPR does. If your risk model was calibrated on percentage-of-turnover thinking, recalibrate.

Penalties are also assessed per contravention rather than per organisation, so one incident can attract findings under several heads simultaneously.

Scope: narrower in one way, wider in another

Narrower: the DPDP Act covers digital personal data. GDPR covers personal data processed by automated means and structured manual filing systems. Paper records in a filing cabinet are within GDPR's reach in a way they are not within DPDP's.

Wider in practice: DPDP has no small-business exemption comparable to GDPR's lighter Article 30 obligations for organisations under 250 employees. The obligations apply regardless of size.

Your sequence

If you have a mature GDPR programme, work in this order:

1. Extract every legitimate-interest activity from your RoPA. Map each to a DPDP legitimate use or flag it for consent. This is the biggest work item and the one that determines everything downstream.
2. Add the India-specific RoPA fields. Language coverage, consent artefact location, withdrawal propagation.
3. Rebuild consent around the purposes that emerge — purpose-level granularity, Eighth Schedule delivery, withdrawal parity.
4. Re-run age gating at 18 and build verifiable parental consent.
5. Rewrite the breach playbook without the materiality filter, with the CERT-In clock alongside.
6. Review transfer paperwork for India specifically.
7. Self-assess for SDF likelihood and stand up DPIA capability before designation, not after.

ProtectComply is built for step one and two specifically — resolving discovery into a processing register with India-specific fields, then driving DPIA workflow from risk scoring, with human review so nothing enters the compliance record unchecked.

Frequently asked questions

Does GDPR compliance mean DPDP compliance?

No. It gets you a substantial head start — RoPA discipline, DPIA methodology, processor governance and security controls all transfer. But legitimate-interest processing, sensitive data tiers, children's thresholds, breach materiality filters, notice language and transfer mechanisms all need rebuilding.

What is the biggest difference between DPDP and GDPR?

The absence of a legitimate interest basis. GDPR's flexible balancing test does not exist under DPDP, so processing justified that way needs either an enumerated legitimate use or fresh consent.

Is DPDP stricter than GDPR?

Stricter in some places, more flexible in others. Stricter on consent, children's data, notice language and breach notification to individuals. More flexible on cross-border transfers and rights scope. Not a simple ranking.

What is the children's data age under the DPDP Act?

Under 18, uniformly — versus GDPR's 16 with member-state discretion down to 13. Verifiable parental consent is required.

Do we need a DPO under the DPDP Act?

Only Significant Data Fiduciaries must appoint a DPO, who must be based in India. Every Data Fiduciary must publish a contact point for grievances.

Are GDPR SCCs valid for DPDP transfers?

Do not assume so. SCCs are a GDPR instrument. The DPDP Act uses a different model — transfers permitted except to restricted territories — and recognition of one regime's mechanisms under the other should not be presumed.

Does DPDP have a right to be forgotten?

Not in GDPR's broad form. It provides rights to access, correction and erasure, without GDPR's data portability right or right to object. It adds a right to nominate someone to exercise your rights on your behalf.

How long do we have?

Full compliance by 13 May 2027, per the DPDP Rules timeline. Enforcement and penalty provisions become operative 13 November 2026.

Where to start

If you already have GDPR, do not start from scratch and do not assume you are covered. Run a gap analysis scoped to the delta — it tells you which of the seven rebuilds actually apply to your processing, and that is a much smaller question than full compliance from zero.

Map your GDPR programme against DPDP obligations

About the author

Yatin Chaudhary is an SEO Specialist at ProtectComply, where he writes about India's data protection framework and how organisations operationalise it.

How this article was researched

Written against the DPDP Act, 2023 and the DPDP Rules, 2025 as notified, compared against GDPR as in force. Where the two regimes are analogous but not identical we say so rather than treating them as equivalent.

Corrections: write to [corrections email] and we will review and update.

Sources

• The Digital Personal Data Protection Act, 2023 — Sections 4, 7, 8, 9, 10, 16, and the penalty schedule
• Digital Personal Data Protection Rules, 2025 — gazette notification G.S.R. 846(E), 13 November 2025
• Regulation (EU) 2016/679 (GDPR) — Articles 6, 8, 9, 30, 33, 34, 35, 44–49, 83
• The Constitution of India, Eighth Schedule
• CERT-In directions on cyber incident reporting

General information, not legal advice. Consult qualified counsel before finalising your compliance position.