Most Indian companies that already have a privacy program built it for GDPR. They serve European customers, or they process European employee data, or their global counsel imported the framework from their US or European headquarters. The assumption is that GDPR is the stricter law, so GDPR compliance covers DPDP by default.
That assumption is wrong in specific, expensive ways.
GDPR and DPDP look similar on the surface. Both are consent-based frameworks. Both grant data subjects (called "Data Principals" under DPDP) a set of rights. Both mandate breach notification. Both carry meaningful penalties. But underneath, the two laws differ on lawful basis, on children's data, on the definition of consent, on rights granted, on breach thresholds, and on structural mechanisms like the Consent Manager framework that has no GDPR equivalent.
If you built your compliance program for GDPR, this guide walks through the specific things you still need to fix. Each gap is tied to a specific DPDP section and, where relevant, the GDPR article that lulled you into thinking you were covered.
The high-level: GDPR gets you 60% of the way
The genuine overlap between GDPR and DPDP is substantial:
- Both require lawful basis for processing
- Both mandate purpose limitation and data minimization
- Both grant rights of access, correction, and erasure
- Both require breach notification (both have 72-hour timelines to a supervisory authority)
- Both impose meaningful penalties for non-compliance
- Both apply extraterritorially
If your GDPR program is genuinely operational (not just documented), you already have:
- A data map of processing activities
- A consent capture mechanism
- A privacy policy
- Data Subject Request (DSR) fulfilment processes
- A vendor management program with DPAs
- Breach detection and notification workflows
- A DPO or equivalent function
You are ahead of most Indian companies. But you are not compliant. Here is what specifically breaks.
Gap 1: "Legitimate interest" does not exist under DPDP
GDPR (Article 6(1)(f)): Legitimate interest is one of six lawful bases. Companies rely on it heavily for analytics, marketing, fraud prevention, and product improvement. It requires a balancing test but no user consent.
DPDP (Sections 6 and 7): There is no "legitimate interest" basis. Personal data can be processed only on the basis of consent (Section 6) OR one of a narrow, closed list of "legitimate uses" (Section 7). The Section 7 list includes:
- The Data Principal has voluntarily provided data for a specified purpose and hasn't objected
- Compliance with a court order or judgment
- Medical emergencies
- Compliance with employment-related obligations
- State functions (grants, subsidies, benefits)
- Public interest processing by the State
- Corporate transactions (mergers, demergers)
That's it. There is no catch-all. Every processing activity your GDPR program relied on "legitimate interest" for now needs either explicit consent or a Section 7 justification that probably doesn't apply.
What breaks in your program:
- Product analytics collected without consent
- Marketing personalization based on browsing behavior
- Fraud detection using cross-user pattern matching
- A/B testing infrastructure that segments users
- Machine learning training on user-generated content
- Recommendation systems using implicit signals
The fix: Audit every processing activity currently justified as "legitimate interest" under GDPR. For each one, either:
- Add explicit consent capture for that specific purpose, or
- Reclassify under a Section 7 legitimate use if genuinely applicable, or
- Stop the processing.
Most companies discover 20% to 40% of their processing activities need consent flows they haven't built.
Gap 2: Age of a child is 18, not 16
GDPR (Article 8): Children under 16 require parental consent for information society services. Individual EU member states can lower this to 13.
DPDP (Section 9): A child is anyone under 18. Full stop. There is no member-state variation. Processing a 17-year-old's data without verifiable parental consent is a Section 9 violation.
Additional DPDP restrictions on children's data:
- Behavioral tracking of anyone under 18 is prohibited outright, regardless of consent
- Targeted advertising directed at children is prohibited outright
- These prohibitions apply even if the parent consents
- Penalties reach Rs. 200 crore for violations involving children's data
What breaks in your program:
- Age gates set at 13 or 16 (both non-compliant)
- Any product feature that tracks user behavior with users between 13 and 18
- Any retargeting pixel or ad SDK that fires for under-18 users
- Any AI recommendation system that personalizes for minors
The fix: Redesign age verification. Move the threshold to 18. Build a verifiable parental consent mechanism (typically involving Aadhaar-based verification, credit card verification, or government ID). Disable all behavioral tracking and targeted advertising for verified minor accounts. This is engineering work, not a policy update.
Edtech and gaming companies are the most exposed. If any material portion of your user base is between 13 and 18, this is your biggest DPDP exposure. For the edtech implementation guide, see DPDP Compliance for Edtech: Parental Consent and Children's Data Under Section 9.
Gap 3: The rights DPDP grants are different
GDPR grants:
- Right to be informed (Art. 13-14)
- Right of access (Art. 15)
- Right to rectification (Art. 16)
- Right to erasure (Art. 17)
- Right to restriction of processing (Art. 18)
- Right to data portability (Art. 20)
- Right to object (Art. 21)
- Rights related to automated decision-making (Art. 22)
DPDP grants:
- Right to access information (Section 11)
- Right to correction and erasure (Section 12)
- Right to grievance redressal (Section 13)
- Right to nominate (Section 14)
- Right to withdraw consent (Section 6(4))
Notice what's missing from DPDP: no data portability, no restriction of processing, no explicit right against automated decision-making.
Notice what's new in DPDP: the right to nominate. Data Principals can nominate another person to exercise their rights in the event of death or incapacity. This is a right with no GDPR analog.
What breaks in your program:
- Your privacy policy lists GDPR rights that don't exist under DPDP (looks unprofessional and misinforms users) — the same pattern we see in 300+ startup audits
- Your rights fulfilment portal offers data portability workflows Indian users can't legally invoke
- You have no workflow for handling nomination requests (Section 14)
- You have no dedicated grievance redressal mechanism (Section 13) with the mandated 90-day response timeline
The fix: Region-detect your users. Show the correct rights based on jurisdiction. Build a nomination workflow. Set up a grievance redressal channel with proper SLA tracking.
Gap 4: The definition of consent is stricter in specific ways
GDPR (Article 4(11)): Consent must be "freely given, specific, informed and unambiguous indication" through a "clear affirmative action."
DPDP (Section 6(1)): Consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action." Adds "unconditional" and drops "indication" in favor of "unconditional consent."
The "unconditional" requirement matters. Under GDPR, you can bundle certain consent with contract necessity as long as the balancing test works. Under DPDP, consent cannot be conditional on receiving a service unless the data is strictly necessary for that service.
Also: Section 6(3) requires the consent notice to be available in English and every language listed in the Eighth Schedule of the Indian Constitution: Assamese, Bengali, Bodo, Dogri, Gujarati, Hindi, Kannada, Kashmiri, Konkani, Maithili, Malayalam, Manipuri, Marathi, Nepali, Odia, Punjabi, Sanskrit, Santali, Sindhi, Tamil, Telugu, and Urdu. Plus English. That's 23 languages.
What breaks in your program:
- Bundled consent flows (accept-terms-plus-marketing in one click) are not DPDP-compliant
- Consent notices only available in English are non-compliant
- Cookie banners with "reject all" hidden under "manage preferences" are dark patterns and non-compliant
- Consent obtained through implied means (continuing to browse) is invalid
The fix: Unbundle consent for every purpose. Build a consent notice localization pipeline (or use a Consent Manager platform that handles this). Redesign cookie banners to give equal weight to accept and reject. Move from implicit to explicit affirmative consent capture.
Gap 5: The Consent Manager framework has no GDPR equivalent
GDPR: No equivalent structural mechanism.
DPDP (Section 6(8)): Introduces the Consent Manager, an independent, registered intermediary that manages consent on behalf of Data Principals across multiple Data Fiduciaries. Consent Managers must be India-incorporated with a minimum net worth of Rs. 2 crore. The framework becomes operational on November 13, 2026.
What this means for your program:
- If your product needs to receive consent through a registered Consent Manager, you need API integration for consent ingestion, withdrawal propagation, and consent state queries
- Foreign platforms (OneTrust US entity, TrustArc) cannot operate as Consent Managers under DPDP. You cannot use them for this workflow.
- You need to design your consent architecture to accept both direct consent (from your app) and Consent Manager-delivered consent
The fix: Build the API integration layer. Choose a Consent Manager partner among India-incorporated options. Test end-to-end consent flow before November 2026.
Gap 6: Breach notification has no materiality threshold
GDPR (Article 33-34): Breaches must be reported to the supervisory authority within 72 hours unless "unlikely to result in a risk to the rights and freedoms of natural persons." Notification to affected individuals only required if "high risk."
DPDP (Section 8(6), Rule 7): Every breach must be reported to the Data Protection Board and every affected Data Principal. There is no materiality threshold. A breach affecting 10 records carries the same notification obligation as one affecting 10 million.
Also: India has a parallel breach reporting framework under CERT-In. Cybersecurity incidents must be reported within 6 hours. A personal data breach triggers both frameworks simultaneously.
What breaks in your program:
- Your breach classification workflow that filters "low materiality" incidents from notification is DPDP non-compliant
- Your 72-hour clock is not your only clock; CERT-In's 6-hour window is tighter
- Your breach notification templates are GDPR-formatted, not DPDP-formatted
The fix: Remove the materiality filter for DPDP reporting. Build parallel notification workflows (CERT-In within 6 hours, DPB within 72 hours). Update templates for DPB format.
Gap 7: Cross-border transfer is opt-in for restricted countries, not opt-out
GDPR (Chapter V): Transfers to non-EEA countries require an adequacy decision, appropriate safeguards (SCCs, BCRs), or derogations. The default is "restricted unless justified."
DPDP (Section 16): Personal data may be transferred outside India except to countries specifically restricted by the Central Government. The default is "allowed unless prohibited." As of writing, the restricted-country list has not been published.
However: RBI, IRDAI, and SEBI already impose data localization requirements for regulated entities. Payment data must stay in India (RBI 2018 circular). Insurance data has similar restrictions.
What this means for your program:
- Your GDPR-based transfer justification framework (SCC, adequacy) is not required for DPDP, but not sufficient for sector-specific rules
- You need a sector-overlay layer that catches RBI, IRDAI, SEBI requirements on top of DPDP
- When the restricted-country list is published, you need to be ready to reconfigure infrastructure quickly
Gap 8: The Significant Data Fiduciary designation
GDPR: No equivalent. All controllers face the same base obligations, with some higher-risk activities requiring DPIAs.
DPDP (Section 10): The Central Government can designate specific Data Fiduciaries as "Significant Data Fiduciaries" (SDFs) based on volume, sensitivity, risk to sovereignty, security, and other factors. SDFs face additional obligations:
- Appoint a Data Protection Officer based in India
- Appoint an independent data auditor
- Perform periodic Data Protection Impact Assessments (DPIAs)
- Perform periodic compliance audits
- Additional measures as prescribed
The SDF list has not been published. Certain sectors (large e-commerce, social media, online gaming) are expected to be included based on the Third Schedule of the DPDP Rules 2025.
What this means: If you might be designated an SDF, you need to be operating an SDF-ready program before the designation lands. Retrofitting DPO, independent audit, and DPIA methodology after designation is expensive and slow.
Gap 9: Grievance redressal is a mandated function
GDPR: No equivalent to India's grievance officer requirement. GDPR requires a DPO for certain organizations, but the DPO's role is oversight, not user grievance handling.
DPDP (Section 13): Every Data Fiduciary must publish a Grievance Officer's contact and respond to complaints within a defined period. The DPDP Rules set this at 90 days.
What breaks in your program:
- Your GDPR "contact us" or "DPO email" is not sufficient. You need a designated Grievance Officer named in your privacy notice.
- You need a tracking mechanism for grievances with SLA enforcement
- You need an escalation path from Grievance Officer to Data Protection Board
Gap 10: The specific breach content requirements
Both GDPR and DPDP require specific content in breach notifications, but the specifics differ.
DPDP Rule 7 requires the notification to include:
- Nature and scope of the breach
- Type of data affected
- Number of Data Principals affected (with categories)
- Timing and location of the breach
- Consequences that could arise
- Measures taken or being taken
- Contact details for further information
Your GDPR-formatted breach templates need to be reformatted to match DPDP fields. This is trivial to fix but easy to overlook until an actual breach occurs and your team is scrambling.
The 60% you already have (worth naming explicitly)
Not everything is a gap. If your GDPR program is real, you likely have the following pieces that carry over directly:
- Data mapping methodology (needs reclassification for DPDP but not rebuild)
- Vendor DPA templates (need DPDP clauses added but core structure works)
- Breach detection infrastructure (needs threshold adjustment but detection layer works)
- Access and erasure fulfilment workflows (need rights list updated but workflow works)
- Encryption, access controls, audit logging (all directly apply)
- Security incident response processes (adapt CERT-In and DPB reporting on top)
Your compliance maturity is a genuine head start. The question is whether you close the gaps before the DPDP enforcement window in May 2027.
The self-audit: 5 things to check this week
- Ctrl+F your privacy policy for "legitimate interest." If it appears, that section needs rewriting.
- Ctrl+F for "data portability." If it appears, that language misinforms Indian users.
- Check your age gate. If it's set to 13 or 16, it's non-compliant.
- Check your consent notice languages. If English-only, you're not covering Section 6(3).
- Check your breach notification workflow. If it filters out "low materiality" incidents, you're missing DPDP's zero-threshold requirement.
If two or more of these are true, your GDPR program needs targeted DPDP remediation, not a full rebuild.
Where Privra fits
Privra runs GDPR-to-DPDP gap assessments for companies with mature European privacy programs entering the Indian market. Our audit maps every one of your existing processing activities against DPDP-specific obligations, identifies the exact list of gaps, and delivers a remediation plan prioritized by penalty exposure.
For companies that already invested in GDPR compliance, this is the fastest path to DPDP readiness. You keep 60%. We help you fix the 40% that carries the penalties.