India's Digital Personal Data Protection Act, 2023 and the European Union's General Data Protection Regulation, 2018 are the two most important data protection laws that Indian businesses — and MNCs operating in India — must navigate simultaneously. They share the same philosophical DNA: consent, rights, accountability, and enforcement. But their architecture, standards, scope, and penalties are meaningfully different in ways that create real compliance complexity. Understanding these differences is not an academic exercise — it determines which law applies to which data flow, what consent language must say, whether you need a DPO, how high your penalty exposure is, and critically: what changes the moment you start marketing to European users from India. This guide gives Indian businesses — and the MNCs operating in India — a complete, side-by-side analysis of both laws across every dimension that matters.
- Scope and territorial reach — which law applies to which data
- Lawful bases for processing — a fundamentally different architecture
- Consent standards — where DPDPA is stricter and where GDPR goes further
- Data subject / Data Principal rights — comparison across 9 rights
- Data Protection Officer — mandatory vs. conditional requirements
- Data Protection Impact Assessments — DPDPA vs. GDPR approach
- Data localisation and cross-border transfers — opposite default positions
- Penalties — the numbers compared across every violation tier
- Children's data — where the two laws converge and diverge
- Data breach notification — timelines and obligations compared
- Accountability and documentation — Record of Processing Activities vs. DPDPA
- Special categories of data — how each law treats sensitive data
- What changes if you target EU users from India — the GDPR trigger explained
- Building a dual-compliance programme — practical framework
1. Scope and Territorial Reach — Which Law Applies to Which Data
The first and most critical question for any business is: which law applies to me, and to which data? The two laws use entirely different territorial scope tests — and both can apply simultaneously to the same organisation.
| Scope Dimension | 🇮🇳 DPDPA 2023 | 🇪🇺 GDPR 2018 |
|---|---|---|
| Establishment Test | Applies to any entity processing digital personal data within India, regardless of where the entity is established | Applies to entities established in the EU/EEA processing personal data in the context of that establishment — regardless of where processing occurs |
| Targeting Test | Also applies to entities outside India processing digital personal data of Indian residents in connection with any activity — if the data is processed in digital form | Also applies to entities outside the EU that offer goods or services to EU data subjects, or monitor their behaviour within the EU — the "targeting test" |
| Data Type Covered | Digital personal data only — data in digital form, or data originally collected offline but digitised. Purely manual/paper records are excluded. | All personal data processed wholly or partly by automated means, plus non-automated processing that forms part of a filing system. Broader than DPDPA. |
| Who Is Protected | "Data Principals" — natural persons providing data in India. Broadly covers all individuals in India. | "Data Subjects" — natural persons in the EU/EEA. Citizenship or nationality is irrelevant — location matters. |
| Exemptions | Personal data processed for personal or domestic purposes; data made publicly available by the Data Principal; certain government processing activities; processing under specified statutes | Household/personal activity; law enforcement processing (separate Directive); purely anonymous data; deceased persons' data; certain journalistic/research/artistic exemptions |
| Applies to Dead Persons? | No — only natural persons who are alive. Deceased persons' data is outside DPDPA scope. | No — GDPR protects living individuals only. Member states may extend protection to deceased persons under national law. |
The dual-application scenario: An Indian SaaS company with Indian and European customers simultaneously processes data of Indian residents (DPDPA applies) and EU residents (GDPR applies). The company must maintain compliance with both laws — using the correct consent language, rights mechanisms, and DPA templates for each user population. This is not hypothetical: it is the daily reality for every Indian tech company with any European customer base.
2. Lawful Bases for Processing — A Fundamentally Different Architecture
This is one of the most significant structural differences between the two laws — and it has profound practical implications for how Indian businesses design their data processing programmes.
| Lawful Basis | DPDPA | GDPR | Key Difference |
|---|---|---|---|
| Consent | ✓ YES | ✓ YES | Both require it to be free, specific, informed, and affirmative. DPDPA adds "unconditional." GDPR additionally allows grandfathered consent with specific conditions. |
| Contract Performance | ≈ PARTIAL | ✓ FULL | GDPR has explicit "contract necessity" basis. DPDPA achieves similar outcome through "legitimate use" — processing necessary to perform a contract to which the Data Principal is a party (Schedule 1, Item 2). |
| Legitimate Interests | ✗ NO | ✓ YES | Critical difference. GDPR's "legitimate interests" basis — widely used for direct marketing, fraud prevention, and network security — does not exist in DPDPA. Activities relying on legitimate interests under GDPR must find an alternative basis under DPDPA. |
| Legal Obligation | ✓ YES | ✓ YES | Both permit processing necessary for compliance with legal obligations. DPDPA frames this as a legitimate use ground under Section 7. Functionally equivalent. |
| Vital Interests | ≈ NARROW | ✓ YES | GDPR has explicit vital interests basis. DPDPA covers emergency medical situations through a narrower legitimate use provision — functionally similar but more restricted in scope. |
| Public Interest / Official Authority | ✓ YES | ✓ YES | Both permit government and public interest processing with appropriate safeguards. DPDPA's government exemptions are arguably broader than GDPR's — a source of concern among civil society groups. |
| Research and Statistics | ≈ LIMITED | ✓ BROAD | GDPR has explicit research and statistics exemptions under Article 89. DPDPA permits research processing but within narrower legitimate use grounds and requires further Rules to be notified. |
The "legitimate interests" gap — the most significant practical difference: GDPR's legitimate interests basis (Article 6(1)(f)) is used by the majority of European companies for direct marketing, fraud prevention, IT security, employee monitoring, and analytics. DPDPA has no equivalent. Indian businesses that currently rely on GDPR's legitimate interests basis for any processing activity must either: obtain consent for that activity, or identify a legitimate use ground under DPDPA Schedule 1. Where neither is available, the activity must stop. This is not a theoretical problem — it requires a complete audit of processing activities that currently rely on legitimate interests.
3. Consent Standards — Where DPDPA Is Stricter and Where GDPR Goes Further
| Consent Requirement | 🇮🇳 DPDPA | 🇪🇺 GDPR | Stricter Law |
|---|---|---|---|
| Must be Free | Yes — cannot be precondition for service unless genuinely necessary | Yes — significant power imbalance renders consent invalid (especially for employees) | EQUAL |
| Must be Specific | Yes — each purpose requires its own separate consent notice. Bundling multiple purposes is prohibited. | Yes — granular consent required. Bundling purposes in one checkbox is not valid. | EQUAL |
| Must be Informed | Yes — notice must state the data, purpose, and withdrawal mechanism before consent is obtained | Yes — data subject must understand what they are consenting to, including identity of controller and purpose | EQUAL |
| Unconditional Requirement | Explicitly required — Section 6(1) states consent must be "unconditional." Processing cannot be conditioned on giving broader consent than necessary. | Not expressly stated as "unconditional" — but the free and specific requirements achieve a similar outcome through the prohibition on bundled consent. | DPDPA |
| Withdrawal Mechanism | Must be as easy as giving consent — Section 6(4). A single click, no friction. Must be mentioned in the consent notice itself. | Must be as easy to withdraw as to give consent — Article 7(3). Must be told of this right before giving consent. | EQUAL |
| Grandfathered/Historical Consent | Not explicitly addressed — legacy consent given before DPDPA's commencement may not meet the new standards. Fresh consent is the safest approach. | Permitted under conditions — Article 7(1) allows reliance on pre-GDPR consent if it meets GDPR standards. Recital 171 provides guidance on acceptable grandfathered consent. | GDPR |
| Consent Manager System | Unique to DPDPA — a Board-registered Consent Manager allows individuals to manage consent across multiple Data Fiduciaries from a single interface. Opens Nov 2026. | No equivalent system — consent is managed bilaterally between data subject and controller. No centralised consent management infrastructure. | DPDPA UNIQUE |
| Record-Keeping of Consent | Required under DPDP Rules — timestamp, notice version shown, method, and withdrawal records must be maintained | Required under Article 7(1) — controller must demonstrate that consent was given. Audit trail is mandatory. | EQUAL |
4. Data Subject / Data Principal Rights — Comparison Across All Rights
| Right | DPDPA | GDPR | Key Differences |
|---|---|---|---|
| Right to Access / Information | YES (S.11) | YES (Art.15) | GDPR's right of access is broader — includes categories of recipients, retention periods, and the right to receive a copy of all data. DPDPA's right to information covers what data is held and how it is processed, but the Rules prescribe its precise scope. |
| Right to Rectification / Correction | YES (S.12) | YES (Art.16) | Functionally equivalent. Both require correction of inaccurate data and completion of incomplete data. GDPR also explicitly covers updates to data that has changed. |
| Right to Erasure / "Right to be Forgotten" | YES (S.12) | YES (Art.17) | DPDPA's erasure right is triggered by consent withdrawal or end of purpose. GDPR's right to erasure has six triggers including withdrawal of consent, objection to processing, and unlawful processing — broader grounds. GDPR also requires informing third parties of the erasure request ("right to be forgotten" extension). |
| Right to Data Portability | NOT IN ACT | YES (Art.20) | GDPR-only right. GDPR gives data subjects the right to receive their data in a structured, machine-readable format and transfer it to another controller. DPDPA has no equivalent — though the Non-Personal Data Governance Framework may introduce portability obligations in the future. |
| Right to Object / Restrict Processing | NOT EXPLICIT | YES (Art.21-22) | GDPR-only right. GDPR gives data subjects the right to object to processing (especially for direct marketing) and to restrict processing in certain circumstances. DPDPA achieves some of this through consent withdrawal but has no standalone objection right. |
| Right Re: Automated Decision-Making | LIMITED (SDF) | YES (Art.22) | GDPR Article 22 gives explicit right not to be subject to solely automated decisions with significant legal effects, including right to human review. DPDPA has algorithmic transparency obligations only for Significant Data Fiduciaries — not a general individual right. |
| Right to Nominate | UNIQUE (S.14) | NOT IN GDPR | DPDPA-unique right. Section 14 allows Data Principals to nominate a person to exercise their data rights posthumously or in case of incapacity. GDPR has no equivalent — though member states may provide rights for deceased persons under national law. |
| Right to Grievance Redressal | YES (S.13) | YES (Art.77) | Both provide for complaint mechanisms. DPDPA requires a Grievance Officer at the organisation level. GDPR provides for complaints to the supervisory authority (DPA). GDPR also provides for judicial remedies independently. |
5. Data Protection Officer — Mandatory vs. Conditional Requirements
6. Data Protection Impact Assessments — DPDPA vs. GDPR
| DPIA Feature | 🇮🇳 DPDPA | 🇪🇺 GDPR |
|---|---|---|
| Who Must Conduct DPIAs | SDFs only — Section 10(2) requires Significant Data Fiduciaries to conduct Data Protection Impact Assessments. General Data Fiduciaries have no mandatory DPIA obligation. | All controllers when processing is likely to result in high risk — Article 35. Specific triggers include systematic evaluation, large-scale processing of special categories, and large-scale monitoring of public areas. |
| Trigger Conditions | To be prescribed by the Board for SDF designation. No published list of DPIA triggers yet — subject to further Rules. | Article 35(3) lists mandatory triggers: automated profiling with legal effects, large-scale special category data, systematic monitoring of public areas. Supervisory authorities publish additional lists of required DPIAs. |
| Consultation with Regulator | Not explicitly required in the Act. SDFs submit DPIAs to the Board — whether prior consultation is required is subject to further Rules. | Article 36 requires prior consultation with the supervisory authority where a DPIA indicates high residual risk. The authority has 8 weeks to respond with written advice. |
| Best Practice for Non-SDF | Voluntary — no mandatory DPIA for general Data Fiduciaries under DPDPA, though recommended for high-sensitivity processing. | Mandatory if processing triggers Article 35 — regardless of entity size or designation. |
7. Data Localisation and Cross-Border Transfers — Opposite Default Positions
- Permissive default — transfers to all countries are allowed unless the government notifies a restriction
- Restricted list approach — government will publish countries to which transfers are prohibited
- No general data localisation requirement in DPDPA itself (sector rules differ)
- Transfer terms and conditions to be prescribed by Rules — not yet notified
- No explicit SCC mechanism yet — pending Rules
- Consent may be used as a transfer mechanism if disclosed in notice
- Prohibitive default — transfers outside EEA are prohibited unless a specific mechanism applies
- Adequacy decisions — EU Commission approves countries meeting GDPR standard (UK, Japan, etc.)
- SCCs — pre-approved contractual clauses for transfers to non-adequate countries
- BCRs — binding corporate rules for intra-group transfers
- Derogations — explicit consent, vital interests, public interest, contract performance
- No general data localisation requirement — but several member states have sector-specific requirements
The practical conflict for Indian companies with EU customers: An Indian company processing Indian users' data on AWS us-east-1 (a cross-border transfer under DPDPA perspective) does not currently violate DPDPA's transfer provisions — because the restricted list has not been notified. However, the same company processing EU users' data on AWS us-east-1 must have a GDPR-compliant transfer mechanism (AWS's SCCs) — because GDPR's prohibitive default applies immediately. One infrastructure decision requires different legal treatment depending on whose data is in the bucket.
8. Penalties — The Numbers Compared Across Every Violation Tier
| Violation Category | 🇮🇳 DPDPA Penalty | 🇪🇺 GDPR Penalty | Stricter for Large Corps |
|---|---|---|---|
| Breach of data security safeguards | Up to ₹250 Cr (~€28M) | Up to €20M or 4% of global annual turnover — whichever is higher | GDPR — for large MNCs |
| Failure to notify breach to regulator | Up to ₹200 Cr (~€22M) | Up to €10M or 2% of global annual turnover — whichever is higher | GDPR — for global corps |
| Consent violations (invalid, absent, bundled) | Up to ₹50 Cr (~€5.5M) | Up to €20M or 4% of global annual turnover | GDPR — significantly |
| Rights violations (access, erasure, portability) | Up to ₹50 Cr (~€5.5M) | Up to €20M or 4% of global annual turnover | GDPR — for global corps |
| Children's data violations | Up to ₹200 Cr (~€22M) | Up to €20M or 4% of global annual turnover | EQUAL / GDPR for large corps |
| Failure to appoint DPO (where required) | Up to ₹50 Cr (SDFs only) | Up to €10M or 2% of global annual turnover | GDPR — for global corps |
| Unlawful cross-border transfers | Up to ₹50 Cr (~€5.5M) | Up to €20M or 4% of global annual turnover | GDPR — for global corps |
| No cap on instances | Each individual violation is a separate instance — 10,000 affected customers = 10,000 potential violations | Fines are per infringement, not per data subject — but supervisory authorities consider scale of processing in calculating amount | DPDPA — for high-volume |
9. Children's Data — Where the Two Laws Converge and Diverge
| Children's Data Rule | 🇮🇳 DPDPA (Section 9) | 🇪🇺 GDPR (Article 8) |
|---|---|---|
| Age of Child | Under 18 — significantly stricter than GDPR. Every student, teenager, and young adult under 18 is a child for DPDPA purposes. | Under 16 — for online information society services. Member states may lower this to 13. Most EU member states use 13 or 16. |
| Parental Consent | Verifiable parental consent required before any data collection from a child — not just for online services. Applies to all sectors including healthcare, education, and e-commerce. | Parental consent required for online information society services targeted at children. Healthcare and other sectors may have separate rules under national law. |
| Behavioural Tracking | ABSOLUTE PROHIBITION — no tracking, profiling, or targeted advertising directed at children under Section 9(3). | No explicit prohibition on behavioural tracking — but consent-based processing of children's data for tracking purposes requires parental consent, making it operationally very difficult. GDPR's legitimate interests basis cannot override children's privacy interests. |
| Targeted Advertising | ABSOLUTE PROHIBITION — no targeted advertising directed at children under any circumstances. | Not explicitly prohibited but operationally constrained by the consent and profiling restrictions. Many EU member states have enacted additional national prohibitions on advertising to children. |
| DPDPA Verdict | Significantly stricter — broader age definition, absolute prohibitions rather than consent-based constraints, and application across all sectors not just online services. | Strong protections but more nuanced — consent-based model means prohibitions are operational rather than absolute in most cases. |
10. Data Breach Notification — Timelines and Obligations Compared
The notification timeline gap: GDPR's 72-hour deadline is one of the most operationally demanding breach notification requirements globally — and it applies the moment a qualifying breach is discovered, not confirmed. DPDPA's timeline is pending Rules, but is expected to be similar or perhaps slightly longer. Companies with both EU and Indian data must prepare breach response plans that can meet the 72-hour GDPR standard — which will de facto satisfy DPDPA's (likely longer) timeline as well. Building to the stricter standard is the only rational compliance approach for dual-jurisdiction organisations.
11. Accountability and Documentation — ROPA vs. DPDPA
| Documentation Requirement | 🇮🇳 DPDPA | 🇪🇺 GDPR |
|---|---|---|
| Record of Processing Activities (ROPA) | Not explicitly required — DPDPA does not mandate a formal ROPA. However, maintaining a data inventory is functionally necessary to demonstrate compliance with lawful basis, notice, consent, and retention obligations. | Mandatory (Article 30) for organisations with 250+ employees or processing that presents risk. Must document categories of processing, recipients, transfers, retention periods, and security measures. |
| Accountability Principle | Implicit — DPDPA requires Data Fiduciaries to demonstrate compliance through appropriate technical and organisational measures, but there is no explicit "accountability" article equivalent to GDPR Article 5(2). | Explicit (Article 5(2)) — the controller must be able to demonstrate compliance with all GDPR principles. This is a standalone obligation, not merely an outcome of other obligations. |
| Privacy by Design | Implied through the obligation to implement appropriate technical and organisational measures under Section 8(5). No explicit "privacy by design and by default" provision. | Explicit (Article 25) — data protection by design and by default is a standalone obligation requiring privacy to be built into systems from inception, not bolted on after deployment. |
| Codes of Practice | Board may issue regulations and guidance on compliance. Sector-specific codes may emerge but are not yet published. | Article 40 provides for approved codes of conduct — industry associations can develop sector-specific codes endorsed by supervisory authorities, providing compliance certainty. |
12. Special Categories of Data — How Each Law Treats Sensitive Data
DPDPA does not create an explicit "special category" list like GDPR. Instead, the law treats all personal data under a single framework — but the penalties for breach of data security safeguards are the highest in the Act (₹250 Cr), incentivising higher protection of clearly sensitive data types.
The SPDI Rules 2011 (which remain partially in force) define sensitive personal data to include: passwords, financial information, health and medical data, sexual orientation, biometric data, and information on religion and political views.
The DPDP Rules 2025 are expected to introduce additional sensitivity-based obligations for specific data types — particularly health, financial, and biometric data.
Explicit list of special categories — processing is prohibited by default unless a specific exception applies:
- Racial or ethnic origin
- Political opinions
- Religious or philosophical beliefs
- Trade union membership
- Genetic data
- Biometric data (for identification)
- Health data
- Sex life or sexual orientation
Processing requires explicit consent or a specific Article 9(2) exception (employment, vital interests, legitimate aims, legal claims, public interest, health, archiving/research).
The practical implication: Companies processing what GDPR considers "special category" data (health, genetic, biometric, political, religious data) must use GDPR's explicit consent or specific exception — a higher standard than GDPR's general consent requirements. The same data under DPDPA is subject to the general consent framework without a higher explicit consent requirement (though health and financial data will likely attract additional obligations under forthcoming Rules). For dual-jurisdiction companies, GDPR's explicit consent standard for special categories provides the safer floor to build to.
13. What Changes If You Target EU Users From India — The GDPR Trigger Explained
This is the question every Indian tech company, SaaS founder, and export-oriented business must answer before entering the European market. GDPR applies to you the moment you have a European user — regardless of where your servers are, where you are incorporated, or whether you have a European office.
14. Building a Dual-Compliance Programme — The Practical Framework
For organisations subject to both DPDPA and GDPR, the most efficient approach is to build a single compliance programme that satisfies both laws simultaneously — using the stricter requirement as the baseline for shared obligations and maintaining law-specific provisions where the laws diverge.
| Compliance Area | Build to Which Standard | Rationale |
|---|---|---|
| Consent Architecture | DPDPA Standard | DPDPA's "unconditional" requirement and mandatory Consent Manager compatibility makes it marginally stricter. A DPDPA-compliant consent architecture will satisfy GDPR's requirements. |
| Privacy Notice | GDPR Standard | GDPR's notice requirements (Articles 13/14) are more detailed — including lawful basis disclosure and legitimate interests explanation. A GDPR-compliant notice, plus DPDPA-specific additions (Consent Manager, nomination right), covers both. |
| Rights Response Process | GDPR Standard | GDPR has more rights (portability, objection, automated decision-making) and more detailed procedures. Building GDPR-compliant rights workflows covers DPDPA's narrower rights plus adds DPDPA-specific additions (nomination right). |
| Breach Response Plan | GDPR Standard | GDPR's 72-hour notification timeline is stricter than DPDPA's forthcoming timeline. Building to the 72-hour standard satisfies both laws simultaneously. |
| Vendor / Processor DPAs | BOTH | Different DPA templates required for each law — GDPR SCCs for EU-related flows, DPDPA-compliant DPAs for India-related flows. Where the same vendor processes both, a combined DPA with law-specific schedules is the most efficient approach. |
| Data Inventory / ROPA | GDPR Standard | GDPR mandates a formal ROPA; DPDPA does not. But a GDPR-style data inventory is functionally necessary for DPDPA compliance as well. Build the ROPA to GDPR Article 30 standard — it covers both. |
| Children's Data | DPDPA Standard | DPDPA's under-18 threshold, absolute prohibition on tracking, and prohibition on targeted advertising are stricter than GDPR's under-16 threshold with consent-based constraints. Build to DPDPA's stricter children's data standard. |
| Governance and Accountability | GDPR Standard | GDPR's explicit accountability principle, privacy by design, DPIAs, and documentation requirements provide a more robust governance framework. Building GDPR-standard governance satisfies DPDPA's implicit accountability requirements. |
Operating under both DPDPA and GDPR simultaneously requires a compliance programme that is architecturally sound — not just individually compliant with each law. The consent language, DPA templates, rights workflows, breach response plans, and governance structures must be coherent across both frameworks. A privacy notice that satisfies GDPR but violates DPDPA — or vice versa — creates simultaneous liability in two jurisdictions.
Our Dual Compliance Programme is built specifically for Indian companies exporting to the EU and MNCs operating in India. It covers: gap analysis against both laws, a unified compliance architecture that satisfies both simultaneously, jurisdiction-specific documentation (privacy notices, consent notices, DPA templates) for each law, breach response plan meeting the stricter 72-hour GDPR standard, EU representative appointment support, and an ongoing monitoring service that tracks regulatory developments in both India and the EU.
Every engagement is led by advocates with cross-jurisdictional expertise in both Indian data protection law and GDPR. We work with Indian SaaS companies, BPOs, manufacturers, IT services firms, and MNC India subsidiaries.
