Your GDPR compliance program will not save you under DPDP. Not because the frameworks are incompatible — they share surface-level concepts like consent, data subject rights, and breach notification. They diverge precisely where it hurts most: at the data architecture level, where the infrastructure differences require new builds, not policy rewrites.
This is “The GDPR Assumption”: the belief that existing GDPR-compliant architecture can be repurposed for DPDP with minimal changes. It is the most expensive assumption an Indian enterprise with a European compliance history can make in 2026.
This guide covers the 4 structural differences between DPDP and GDPR — and exactly what each one demands from your data platform.
What you will master in this guide:
- Why DPDP’s digital-only scope changes your ingestion layer design
- Why the absence of legitimate interest as a lawful basis rebuilds your consent architecture from scratch
- What the Consent Manager role means for your data pipeline orchestration
- Why the absence of a sensitive data sub-category in DPDP changes your PII tagging strategy
For the full DPDP obligation framework, read the DPDP readiness on Databricks: complete guide 2026.
Difference 1: DPDP Is Digital-Only — GDPR Covers Everything
GDPR applies to all personal data, regardless of format: digital files, paper records, CCTV footage, physical HR files. DPDP applies exclusively to digital personal data — data that exists in digital form, or data that was originally non-digital and has been digitized.
This sounds like a narrower scope. It isn’t — not for a Databricks-based enterprise. Here’s why that matters.
Under GDPR, data architecture teams frequently argue that certain processing activities fall outside scope because they involve offline-only data paths. Under DPDP, that argument is not available. Every digital touchpoint is in scope. Every API call that moves personal data, every Spark job that processes it, every Delta table that stores it — all of it is subject to the Act the moment it exists in digital form.
The architectural implication: your bronze-layer ingestion pipeline must classify and tag personal data as DPDP-governed from the moment it arrives, without exception. The GDPR-era practice of selective scoping — treating some digital processing as out-of-scope because it connects to offline processes — does not apply under DPDP.
If your Databricks estate has even 1 digital touchpoint with Indian residents’ personal data, the Act applies. Full stop.
Difference 2: No Legitimate Interest — Consent Is the Only Basis That Scales
GDPR provides 6 lawful bases for processing: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Most enterprise processing programs rely heavily on legitimate interests — it is the most flexible basis and the hardest for data subjects to challenge.
DPDP eliminates this. Consent is the dominant lawful basis. The Act does recognize limited exemptions — state functions, certain research and archiving activities, employment-related processing — but none of these substitute for consent in a commercial enterprise context.
The result: if your GDPR program was designed around legitimate interests for marketing, analytics, behavioral profiling, or cross-product personalization, every one of those processing activities requires a consent record under DPDP. There is no migration path — you build a consent architecture from scratch.
On Databricks, this means:
- Every pipeline processing Indian residents’ personal data must join to a consent store before executing → A Spark job with no consent check is DPDP non-compliant regardless of technical quality
- Consent must be purpose-specific — one consent record per processing purpose, not a blanket approval → “We use your data to improve our services” is not a DPDP-compliant consent statement
- Consent must be withdrawable with the same ease as it was given — and withdrawal must cascade to downstream processing immediately → This requires event-driven pipeline architecture, not batch consent syncs
The absence of legitimate interest under DPDP is not a technicality. It rebuilds your processing justification layer from zero.
Difference 3: The Consent Manager Role — No GDPR Equivalent
GDPR introduced the concept of a Data Protection Officer (DPO). DPDP introduces something GDPR has no equivalent for: the Consent Manager — a government-registered intermediary that manages the relationship between Data Fiduciaries and Data Principals on consent.
Under DPDP Phase 2 (effective November 13, 2026), Data Fiduciaries must be able to interact with registered Consent Managers — third-party platforms that handle consent capture, storage, and revocation on behalf of data principals in an interoperable, standardized way.
Here is where the architecture diverges from GDPR entirely. A GDPR-compliant consent management tool is a first-party system — your organization builds and owns it. A DPDP-compliant consent infrastructure must be able to receive, process, and honor consent signals from external registered Consent Managers. Your pipeline cannot assume it owns the consent record.
| Feature | GDPR Consent Management | DPDP Consent Management |
|---|---|---|
| Consent infrastructure | First-party, organization-owned | Must integrate with registered third-party Consent Managers |
| Lawful basis alternatives | 6 bases including legitimate interest | Consent-dominant; narrow statutory exemptions only |
| Consent language requirements | Local language encouraged | 22 scheduled Indian languages on request — mandatory |
| Withdrawal handling | Must be honored | Must be honored AND cascade to all downstream processing |
| Intermediary role | No equivalent | Consent Manager (registered, interoperable, Phase 2 mandatory) |
| Scope | All personal data (digital and physical) | Digital personal data only |
The architectural implication for your Databricks estate: your consent store must be designed to receive consent signals from external Consent Managers — not just from your own application layer. A closed consent store that only accepts first-party signals is not DPDP-compliant after November 2026.
Difference 4: No Sensitive Data Sub-Category — How DPDP Changes PII Tagging Strategy
GDPR Article 9 establishes a special category of sensitive personal data — racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, sex life and sexual orientation — with heightened protection requirements and explicit consent obligations.
DPDP does not create a separate sensitive data category. All personal data is treated under the same consent and protection regime. The Central Government can designate specific categories of data for enhanced protection via notification, but as of 2026 no such category notification has been issued.
This changes your PII tagging strategy on Databricks in a non-obvious way. Under GDPR, most teams built a 2-tier classification: standard PII (less restrictive controls) and special category / sensitive PII (stricter controls, explicit consent required). Under DPDP, that tiering is irrelevant. Every field tagged as personal data carries the same consent and access control obligations. A name and phone number combination demands the same architectural controls as a health record.
The implication: if your Databricks Unity Catalog is configured with GDPR-era tiered PII policies — lighter controls on standard PII, heavier controls on special category data — you need to flatten that architecture for DPDP compliance. Every PII column, regardless of sensitivity, must be consent-linked and access-controlled at the same standard.
Your GDPR PII governance architecture is a starting point for DPDP. It is not a finish line.
The GDPR-to-DPDP Architecture Migration Checklist
This information has not been clearly laid out elsewhere — until now.
- Audit all processing activities currently justified under legitimate interests — each requires a consent record under DPDP
- Redesign consent store to accept external signals from registered Consent Managers (Phase 2 deadline: November 2026)
- Flatten PII governance tiers in Unity Catalog — all personal data fields to carry the same DPDP control set
- Add multi-lingual notice capability — DPDP requires notices in the data principal’s preferred language on request
- Configure cascade revocation: consent withdrawal must trigger immediate downstream processing halt across all pipelines
- Review digital-only scope definition — all digital personal data of Indian residents is in scope regardless of offline connections
Final Verdict
GDPR and DPDP share a vocabulary. They do not share an architecture. Consent-dominant processing, registered Consent Manager integration, uniform PII governance across all data categories, and cascade revocation workflows — none of these exist in a standard GDPR implementation. Every one of them requires new infrastructure.
The organizations that treat DPDP as a GDPR policy update will discover the gap at the worst possible time: under a DPBI investigation, with a 72-hour breach notification window running and a consent store that wasn’t designed for Indian enforcement.
Build the DPDP architecture deliberately. “The GDPR Assumption” has a ₹250 crore failure mode.
For the full technical architecture, read implementing DPDP readiness on Databricks: architecture reference.
FAQ: DPDP vs GDPR Differences
They share surface concepts — consent, data subject rights, breach notification, and data protection officers — but diverge structurally. DPDP is digital-only, consent-dominant (no legitimate interest basis), introduces a unique Consent Manager role, and applies a uniform standard to all personal data without a sensitive data sub-category.
Partially. GDPR infrastructure covers DPO governance, rights request workflows, and breach notification protocols — all of which map to DPDP requirements. However, your consent architecture, PII tagging strategy, and any processing activity currently justified under legitimate interests must be rebuilt for DPDP compliance.
Both require freely given, specific, informed, and withdrawable consent. The key difference is that DPDP makes consent the dominant lawful basis for commercial processing — GDPR’s legitimate interest basis does not exist under DPDP. DPDP also requires consent to be purpose-specific and to integrate with registered Consent Managers from November 2026.
The Consent Manager is a government-registered third-party intermediary that manages consent on behalf of data principals. GDPR has no equivalent — under GDPR, consent management is a first-party responsibility. Under DPDP, Data Fiduciaries must be able to interact with external Consent Managers from Phase 2 onwards.
GDPR applies to all personal data regardless of format — digital, paper, CCTV, physical records. DPDP applies only to digital personal data and to non-digital personal data that has been digitized. For Databricks-based enterprises, all digital processing of Indian residents’ personal data is in scope without exception.
No. DPDP does not create a separate sensitive data sub-category. The Central Government can designate specific data types for enhanced protection via notification, but no such categories have been notified as of 2026. All personal data carries the same consent and access control obligations under DPDP.
On consent requirements, DPDP is stricter — it eliminates legitimate interest as a lawful basis, which GDPR’s enterprise programs heavily rely on. On breach notification, both impose 72-hour windows to regulators. Neither is categorically “stricter” — they create different obligations that require different infrastructure.
Migrate Your Data Architecture from GDPR to DPDP
Talk to Sinki.ai about migrating your data architecture from GDPR to DPDP — consent store redesign, Unity Catalog PII governance, and Consent Manager integration, all native to your Databricks workspace.
