DPDPA and GDPR share a philosophy but diverge sharply on consent architecture, Data Principal rights, processor obligations, and breach timelines — here is exactly what needs to change.
Why Your GDPR Playbook Cannot Simply Be Relabelled
Every Indian enterprise that went through GDPR compliance carries institutional memory: consent forms, data maps, processor agreements, breach response playbooks. The instinct when DPDPA landed was to dust those off and adapt them. That instinct is partially right — and partially dangerous.
GDPR and DPDPA share a philosophical foundation: consent must be informed, specific, and withdrawable; individuals have rights over their data; organisations must demonstrate accountability. But the operational mechanics diverge in ways that will trip up companies that simply relabel their GDPR artefacts.
This article maps the five most consequential differences and tells you exactly what to change, what to port, and what to build from scratch.
Consent Architecture: The Core Divergence
Under GDPR, consent is one of six legal bases. Controllers routinely rely on legitimate interest, contract performance, or legal obligation — consent is reserved for cases where the other bases don't apply. This means many GDPR-compliant organisations have built their data processing on non-consent legal bases entirely.
DPDPA does not work this way. The Act recognises consent as the primary legal basis for processing personal data, with a narrower set of "deemed consent" exceptions (employment, legal obligation, public interest). For Indian consumer-facing operations, consent is the default, not the fallback.
What this means operationally:
- Every processing purpose needs a consent record, not just the ones where you chose consent under GDPR
- Consent collection interfaces must be purpose-specific — bundled or general-purpose consents that passed GDPR muster may not satisfy DPDPA's notice requirements
- The consent must be linked to an identifiable Data Principal, retrievable and auditable at any time
If your GDPR consent system was built to handle "consent as exception," you need a different architecture for DPDPA — one where consent management is the core data flow, not an edge case.
Data Principal vs Data Subject: Rights That Look Similar But Aren't
GDPR gives data subjects eight rights. DPDPA gives Data Principals seven. The overlap is significant — access, correction, erasure, and withdrawal are present in both. But three differences matter at the implementation layer.
Grievance Redressal (DPDPA-specific): Data Principals have a right to a grievance mechanism, and Data Fiduciaries must respond within 30 days. GDPR has no equivalent mandatory response timeline. If your GDPR rights fulfilment workflow doesn't have a hard 30-day SLA with an audit trail, it is non-compliant under DPDPA.
Right to Nominate (DPDPA-specific): Data Principals can nominate another person to exercise their data rights in the event of death or incapacity. There is no GDPR equivalent. This requires a nomination capture and management workflow that doesn't exist in any GDPR toolset.
No Right to Data Portability (DPDPA): GDPR Article 20 gives data subjects the right to receive their data in a machine-readable format. DPDPA does not include this right. This matters less as a compliance burden and more as a signal — DPDPA is primarily about protection, not portability.
Processor Accountability: What Changes at the Contract Layer
GDPR requires a formal Data Processing Agreement (DPA) between every controller and processor. Most mature GDPR compliance programmes have a standard DPA template. DPDPA uses the terms Data Fiduciary and Data Processor but the accountability chain works differently in three ways.
First, DPDPA makes Data Fiduciaries explicitly responsible for ensuring their Data Processors comply with the Act — there is no safe harbour for relying on a DPA and then not verifying processor behaviour. Your vendor contracts need audit rights, not just contractual warranties.
Second, DPDPA has not issued standard contractual clauses the way GDPR has. Your DPA templates need to be built from the Act's requirements, not ported from EU SCCs.
Third, the sub-processor chain matters. If your vendor uses sub-processors who touch Indian personal data, those relationships need to be disclosed and governed. Check your existing vendor agreements — most GDPR-era DPAs have sub-processor clauses, but they may not impose DPDPA-specific obligations on those sub-processors.
Breach Notification: 72 Hours vs "Without Undue Delay"
GDPR's breach notification requirement is "without undue delay and, where feasible, not later than 72 hours." There's also a materiality threshold — you only notify the supervisory authority if the breach is "likely to result in a risk to the rights and freedoms of natural persons."
DPDPA's breach notification, as elaborated in the DPDP Rules 2025, requires notification to the Data Protection Board and to affected Data Principals for any personal data breach — without GDPR's materiality filter. The Rules set a 72-hour window to notify the Board, with notification to affected individuals to follow.
What this means practically:
- Your breach materiality assessment process may need to be revised — under DPDPA, more breaches will cross the notification threshold
- You need a separate notification path to Indian individuals, not just to the regulator
- Your incident response runbook needs a DPDPA-specific lane, not just a GDPR lane with "India" written on it
- Audit logs proving notification timing will be scrutinised by the Data Protection Board
Significant Data Fiduciary vs High-Risk Processing
GDPR's highest-obligation category targets organisations conducting "high-risk processing" as defined by DPIA triggers. The DPIA requirement is activity-specific — it applies to particular processing operations, not to the organisation as a whole.
DPDPA creates a distinct category: Significant Data Fiduciary (SDF). An organisation is notified as an SDF by the central government based on volume of data processed, sensitivity, national security implications, and other criteria. Once classified as an SDF:
- A Data Protection Officer based in India must be appointed
- An independent data auditor must be appointed
- Periodic Data Protection Impact Assessments must be conducted
- Additional obligations as notified by the government apply to the whole organisation
The key difference: GDPR's high-risk obligations apply to specific processing activities; DPDPA's SDF obligations apply to the entire organisation. If you're notified as an SDF, every data processing activity comes under the heightened regime — not just the ones that triggered the classification.
Building Dual Compliance Without Doubling Your Workload
The most efficient path to dual GDPR-DPDPA compliance is a shared consent infrastructure that serves different obligation sets from the same data layer. The consent record — who consented, to what purpose, when, via what mechanism — is the same regardless of which regulation governs it. The differences are in the notice text, the rights workflow, and the audit trail format.
Consentica by OpenBlockAI is built for this multi-regulation architecture. A single consent collection event generates GDPR-compliant and DPDPA-compliant records simultaneously — different notice templates, different rights fulfilment flows, same underlying consent data store. Indian operations running under both frameworks can avoid maintaining parallel consent systems, parallel audit logs, and parallel processor registries.
The DPDPA-specific additions — nomination capture, 30-day grievance SLA tracking, purpose-specific consent for Indian data flows — sit as configuration on top of the shared infrastructure rather than as a separate system to build and maintain.