Consent Requirements Under DPDP Act 2023 vs. EU GDPR
Organizations operating across Europe and India often make the same mistake: treating GDPR compliance as a baseline that DPDP compliance simply extends. It doesn’t. The two frameworks share privacy principles but diverge in architecture. GDPR is a rights-first, multi-basis regulation — Article 6 gives organizations six separate legal grounds for processing, so a great deal of everyday data use never touches consent at all. India’s DPDP Act inverts that: consent is the default requirement for commercial processing, and Section 7’s “Certain Legitimate Uses” is a narrow, closed list that does not include general commercial or contractual convenience. For CISOs and enterprise architects running both jurisdictions, this isn’t a wording difference — it’s a different starting assumption that Consent Management Platforms, IAM systems, and withdrawal pipelines have to be built around separately.
Table of Contents
Legal Basis Architecture
Section 7’s exceptions cover a defined set of situations — certain state functions, medical emergencies, employment-related processing, and similar specified purposes — not general commercial activity. Product analytics, cross-selling, and behavioral profiling all need explicit opt-in consent under DPDP, even where a GDPR program would rely on legitimate interest.
Notice and Transparency Requirements
Both frameworks require a clear notice before consent is collected, but the details differ. GDPR notices identify the Controller, DPO contact, lawful basis, retention period, and data subject rights. DPDP notices carry the same substantive core but add a language requirement: notices must be available in English or the data principal’s choice of a language listed in the Eighth Schedule to the Constitution.
DPDP also imposes a retrospective obligation GDPR doesn’t have in the same form: organizations holding personal data collected before the Act’s provisions took effect must send fresh notices — covering purpose and withdrawal mechanism — “as soon as reasonably practicable.” For any enterprise with a pre-existing Indian customer or employee database, that’s a real migration project, not a footnote.
Age Thresholds and Children's Data
This is where the two frameworks diverge most sharply. GDPR sets the default digital consent age at 16, with Member States free to lower it to 13 — most have. DPDP sets a single, non-negotiable threshold: anyone under 18 is a “child” under Section 2(f), full stop, with no member-state-style variation.
The obligations layer in three parts, and precision matters here because the sections are often conflated: Section 9(1) requires verifiable parental or guardian consent before processing a child’s data. Section 9(2) is broader — it bars any processing “likely to cause detrimental effect on the well-being of a child,” independent of tracking or advertising specifically. Section 9(3) is the explicit prohibition: no behavioral tracking, no profiling, no targeted advertising directed at children, and this prohibition holds even where a parent has consented.
There is a narrow release valve. Rule 10 exempts specified classes of Data Fiduciaries (healthcare, education, childcare, under the Fourth Schedule) from 9(1) and 9(3) for defined purposes — the well-being bar in 9(2) still applies regardless. Section 9(5) also lets the Central Government exempt a specific Data Fiduciary from 9(1)/9(3) obligations above a chosen age, if it can demonstrate its processing is verifiably safe. For CISOs running cross-border platforms, the practical conflict stands: a 16-year-old who is a fully consenting adult user under GDPR cannot legally be tracked or targeted the same way on the Indian side of the same platform.
The Consent Manager Innovation
DPDP’s most structurally distinctive feature has no GDPR equivalent. Section 6 and Rules 3–4 establish “Consent Managers” — independent, India-incorporated intermediaries registered with the Data Protection Board of India, modeled conceptually on the RBI’s Account Aggregator framework. Where GDPR consent lives inside each controller’s own systems, DPDP Consent Managers give an individual one interface to grant, review, and withdraw consent across multiple organizations at once.
Rule 4 takes effect in November 2026, giving Data Fiduciaries a hard integration deadline: systems must be technically ready to accept and honor consent instructions arriving from a third-party Consent Manager, not just from the organization’s own consent UI. The exact technical interoperability standard is still being finalized by the Board, but the direction is clear enough to build against now — standardized, auditable, real-time consent state synchronization, not a proprietary in-house flow.
Architectural Implementation Priorities
- Data inventory and geo-isolation — tag ingestion pipelines by country of origin; DPDP applies only to digital or digitized personal data.
- Consent architecture redesign — remove reliance on any “legitimate interest” logic for Indian data subjects; replace with unbundled, granular opt-in checkboxes.
- Multilingual notice delivery — build notice templates and translation workflows for Eighth Schedule languages.
- Age-gating and IAM updates — enforce the 18-year threshold, build verifiable parental consent workflows, and hard-block tracking/ad tech for confirmed or unverified minors in the Indian jurisdiction.
- Consent Manager readiness — design for API-based consent synchronization ahead of the November 2026 deadline, with cascading withdrawal automation across processors and vendors.
Common Implementation Mistakes
- Applying GDPR’s legitimate-interest logic to Indian data flows by default.
- Treating the 18-year child threshold as equivalent to GDPR’s 16 (or 13) — it is materially stricter and non-negotiable.
- Waiting until late 2026 to start Consent Manager integration work, which is a systems-integration project layered on top of a legal one.
Conclusion
DPDP isn’t a stricter GDPR — it’s a different regulatory philosophy built around consent as the default, not the exception. Retrofitting a GDPR-first architecture onto Indian operations tends to under-build exactly the two things DPDP requires most: granular, unbundled consent capture, and Consent Manager interoperability. Enterprises that engineer for both frameworks in parallel, rather than treating DPDP as a GDPR add-on, avoid rebuilding consent infrastructure twice.
Not sure where your consent architecture has GDPR assumptions baked in that won't hold under DPDP?
Ananta Quanta Consulting runs a structured DPDP-GDPR consent gap assessment for privacy and engineering teams managing both jurisdictions.
