◆ XILIGENTFIELD NOTES·DPDPA
Field Notes · Issue 01 · APR 26, 2026

DPDPA vs GDPR: 10 Key Differences Every Compliance Team Should Know

Ten architectural differences that will shape your DPDPA programme — and where lift-and-shift from GDPR will leave you exposed.

From the essay
If your compliance program has been built around the GDPR, treating the DPDPA as a familiar problem in a new accent is one of the costliest assumptions a compliance team can make in 2026.
◆ FIG. 01 — XILIGENT FIELD NOTES VOL. 01

If your compliance program has been built around the GDPR, it is tempting to think of India's Digital Personal Data Protection Act (DPDPA) as a familiar problem in a new accent — GDPR-lite, perhaps, with a few Indian flavours. That assumption is one of the costlier ones a compliance team can make in 2026.

The DPDP Rules were finalised on 13 November 2025, and most substantive obligations become enforceable on 13 May 2027. That gives organisations roughly 18 months to design, build, and test their compliance posture — and the architecture of the law is different enough from the GDPR that lift-and-shift will leave material gaps.

This post walks through the ten differences that matter most when you are translating a GDPR programme into a DPDPA-ready one, or building from scratch for the Indian market.


1. The Vocabulary Reflects a Different Philosophy

The GDPR talks about Controllers, Processors, and Data Subjects. The DPDPA replaces these with Data Fiduciaries, Data Processors, and Data Principals.

The shift from "Controller" to "Fiduciary" is not cosmetic. A fiduciary, in Indian legal tradition, is someone who holds something in trust for another — and the term is a deliberate signal that organisations handling personal data owe a duty of care, not merely lawful processing. Compliance teams should expect the Data Protection Board of India (DPBI) to interpret obligations through that lens. Notices, consent flows, and grievance mechanisms will be assessed against whether they actually serve the principal's interests, not whether they technically discharge a legal duty.

Practical takeaway: When auditing your existing GDPR notices and consent flows for DPDPA, read them through the eyes of a non-technical Indian consumer, not a privacy lawyer.

2. Legal Bases for Processing: Consent is King

This is one of the largest operational gaps between the two laws.

The GDPR offers six lawful bases for processing: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The "legitimate interests" basis, in particular, is what allows European companies to run analytics, fraud prevention, B2B marketing, and a host of operational activities without explicit consent — provided a balancing test is documented.

The DPDPA offers only two pathways: consent or a narrow set of statutorily defined "legitimate uses" (employment, medical emergencies, voluntary provision of data, government functions, and a few others). There is no general "legitimate interests" balancing test.

Practical takeaway: Many activities you currently rely on legitimate interests for under GDPR — including a lot of marketing, profiling, and analytics — will require explicit consent under DPDPA. Map your processing inventory against the legitimate uses list early; what falls outside it needs a consent strategy.

3. There Is No "Sensitive" or "Special Category" Data

Under GDPR Article 9, special categories of data (health, biometrics, race, religion, sexual orientation, trade union membership, political opinions, genetic data) require an explicit legal basis and heightened safeguards.

The DPDPA does not separate sensitive data from other personal data. All personal data is treated under a single tier of protection.

This sounds simpler — and in some ways it is. But it has two real consequences. First, you cannot relax controls on "non-sensitive" data the way some GDPR programmes do; the baseline obligations apply uniformly. Second, you lose the regulatory cover that came with structured Article 9 safeguards — meaning categories like health and biometric data are protected by the same rules as a name and email, and the burden of additional safeguards rests on the fiduciary's own risk judgement.

Practical takeaway: If your GDPR DPIAs and access controls are calibrated to data sensitivity, do not abandon that approach for DPDPA. Keep the tiered controls; the law just will not give you credit for them in the same way.

4. There Is No Small Business Exemption

Article 30 of the GDPR gives organisations with fewer than 250 employees relief from the obligation to maintain detailed records of processing (with exceptions). Several other GDPR obligations are scaled to risk and size in practice.

The DPDPA has no automatic carve-out for small businesses or MSMEs. The Central Government can exempt specific classes of fiduciaries by notification, but until that happens, a 10-person Indian startup processing personal data has the same baseline obligations as a multinational bank.

This is one of the most underappreciated facts of the law and one that Indian MSMEs in particular need to internalise. There is no threshold below which the DPDPA simply does not apply.

Practical takeaway: Indian SMBs cannot wait for an exemption that may never come. Treat DPDPA readiness as a 2026 priority regardless of headcount.

5. Children's Data: A Higher Bar Than GDPR

The GDPR sets the digital age of consent at 16, with the option for member states to lower it to 13. Verifiable parental consent is required only below that age.

The DPDPA sets the threshold at 18 years, and mandates verifiable parental consent before processing the data of any child or person with a lawful guardian. It also explicitly prohibits behavioural monitoring and targeted advertising directed at children.

For EdTech, gaming, social platforms, and any consumer business where teenagers are users, this is a significant operational lift. The combination of a higher age threshold and a mandatory verification mechanism means you are not just adjusting a flag — you are building a parental consent infrastructure.

Practical takeaway: Plan now for parental consent verification mechanisms. This is one of the few DPDPA obligations that may require new product engineering, not just policy work.

6. Narrower Data Principal Rights

GDPR data subject rights include access, rectification, erasure, restriction of processing, data portability, objection, and rights related to automated decision-making.

DPDPA data principal rights are narrower:

  • Right to access information about processing
  • Right to correction and erasure
  • Right of grievance redressal
  • Right to nominate (someone to exercise rights on the principal's behalf in case of death or incapacity)

Notably absent: data portability, the right to object, and specific rights around automated decision-making and profiling. The DPDPA also does not currently include a private right of action for damages — disputes are resolved through the DPBI, with appeals to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

Practical takeaway: Some of the rights infrastructure you built for GDPR is not strictly required under DPDPA. But the right to nominate is novel — your DSAR portal needs a workflow that does not exist in GDPR programmes.

7. Cross-Border Data Transfers: A More Permissive Default

The GDPR is famously restrictive on international data transfers. Transfers outside the EEA require an adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or a derogation.

The DPDPA takes the opposite approach. Personal data may, by default, be transferred to any country except those the Indian government specifically restricts via notification — a "negative list" model rather than GDPR's "positive list." As of now, no such restrictions have been notified.

This sounds liberating, but two cautions apply. First, sectoral regulators — the Reserve Bank of India for payment data, IRDAI for insurance, SEBI for securities — impose their own localisation and transfer requirements that override the DPDPA's permissive default. Second, the Indian government can change the list at any time, so building infrastructure on the assumption of unrestricted flow is risky.

Practical takeaway: DPDPA cross-border compliance is simpler than GDPR's, but the sectoral overlay is where most real restrictions live. Map your data flows against your sector regulator first, the DPDPA second.

8. The Consent Manager: A Uniquely Indian Concept

GDPR has no analog to this. The DPDPA introduces a new regulated entity — the Consent Manager — who acts as a single, interoperable point through which data principals can give, review, manage, and withdraw consent across multiple data fiduciaries.

Consent Managers must be Indian companies with a minimum net worth of ₹2 crore, must hold specified certifications, and must register with the DPBI. The provisions governing them become operational on 13 November 2026.

The model is closer to the Account Aggregator framework that already exists in Indian financial services than to anything in GDPR. For data fiduciaries, this means designing your consent infrastructure to interoperate with registered Consent Managers — not just to collect consent directly.

Practical takeaway: Decide your Consent Manager strategy in 2026. Will you integrate with one or more registered managers? Build your own (which is a significant undertaking)? Treat them as optional? The answer affects your consent architecture.

9. Breach Notification: Stricter on the Individual Front

Both laws have a 72-hour reporting clock, but the obligations diverge meaningfully on individual notification.

Under GDPR, breaches must be reported to the supervisory authority within 72 hours, and affected individuals must be notified only when the breach is likely to result in a "high risk" to their rights and freedoms.

Under the DPDPA, the data fiduciary must inform the DPBI without delay, with a detailed report within 72 hours — and must inform every affected data principal directly, regardless of the level of risk. There is no risk-based threshold for individual notification.

Practical takeaway: Your incident response runbook needs an Indian-specific track. The decision tree for individual notification is simpler under DPDPA (you always notify) but the operational burden is heavier — you need a contact channel for every affected principal.

10. Penalty Structure and the Enforcement Body

GDPR penalties are turnover-linked: up to €20 million or 4% of global annual turnover, whichever is higher. Enforcement is by independent national Data Protection Authorities, each with quasi-judicial powers.

The DPDPA penalty structure is fixed-amount, not turnover-linked:

ViolationMaximum penalty
Failure to implement reasonable security safeguards₹250 crore
Failure to notify breach (DPBI or principals)₹200 crore
Violations relating to children's data₹200 crore
Failure to fulfil Significant Data Fiduciary obligations₹150 crore
Other violationsup to ₹50 crore

Enforcement sits with the Data Protection Board of India (DPBI) — a four-member administrative body, not a quasi-judicial regulator with the discretion of an EU DPA. Appeals go to TDSAT. Notably, there is no statutory right for individuals to claim damages directly; the DPBI may, however, facilitate mediation between fiduciaries and principals.

Practical takeaway: Penalty exposure under DPDPA is fixed and substantial, but the enforcement model is more administrative and less litigious than GDPR's. Plan for regulatory engagement and proactive disclosure rather than DPA-style adversarial enforcement.

A Side-by-Side Summary

DimensionGDPRDPDPA
TerminologyController / SubjectFiduciary / Principal
Lawful bases6 (incl. legitimate interests)2 (consent + narrow legitimate uses)
Sensitive data tierYes (Article 9)No separate tier
Small business reliefLimited (Art. 30)None
Child threshold16 (can be lowered to 13)18, with verifiable parental consent
Data portabilityYesNo
Right to objectYesNo
Cross-border transferRestrictive (positive list)Permissive (negative list)
Consent ManagerN/AMandatory regulated entity
Breach notification to individualsRisk-basedAlways
Penalty cap4% turnover or €20MFixed, up to ₹250 crore
Enforcement bodyNational DPAsData Protection Board of India

What This Means for Your 2026 Roadmap

If you already run a mature GDPR programme, you are not starting from zero — but you are not finishing close to it either. The areas that need fresh design work, in our experience:

  • Lawful basis re-mapping, especially for activities currently riding on legitimate interests
  • Consent infrastructure built for Indian Consent Manager interoperability
  • Children's data verification mechanisms
  • Breach notification workflows that contact every affected principal
  • Sectoral-overlay mapping for cross-border flows
  • The right to nominate, which has no GDPR analog

The temptation to wait until enforcement begins in May 2027 is understandable but expensive. The DPBI is already operational. Public disclosure of compliance posture — through privacy notices, contracts, and audit trails — starts long before the first penalty is issued. 2026 is the year your evidence is built.


Compliance teams that treat the DPDPA as its own regime, not a translation of GDPR, will find themselves in a stronger position when full enforcement begins. The two laws share a goal — protecting personal data — but they get there through different architectures, and the differences are where compliance programmes succeed or fail.

Field Notes · Weekly

Long-form privacy & GRC essays in your inbox. One per Tuesday. No filler.

Free. Unsubscribe in one click. We don't have a cookie banner.

© Xiligent 2026 · All rights reservedField Notes · Issue 01 · APR 2026