TL;DR: GDPR-oriented privacy programs often fail in India because the Digital Personal Data Protection Act is built around continuous consent enforcement and runtime data handling, not documentation alone, according to LEVO. The gap is structural: privacy teams must move from rights workflows and policy artifacts to system-level controls that prove personal data stays constrained as it flows.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “GDPR vs DPDP: Why GDPR First Privacy Programs Break in India”.
Key questions
Q: What breaks when GDPR-style privacy controls are used for DPDP compliance?
A: GDPR-style controls break when they stop at documentation, rights handling, and policy review while the live system continues processing personal data outside the intended consent boundary.
Q: Why do runtime privacy controls matter more under DPDP than under GDPR?
A: Because DPDP is designed to judge how personal data is actually handled, not just whether the organisation can justify processing on paper.
Q: How do security teams know whether privacy controls are actually working?
A: Look for evidence that discovery, classification, DSR routing, and consent enforcement update when the environment changes.
Practitioner guidance
- Map consent to runtime enforcement points Identify where consent state is checked, propagated, or lost across APIs, service layers, and downstream workflows.
- Audit data flows for purpose drift Trace how personal data is reused after collection, especially in analytics, integrations, and customer service workflows.
- Tie service identities to privacy boundaries Review which service accounts, application credentials, and integrations can still reach personal data after consent changes.
Bottom line: GDPR compliance can overstate readiness for India’s DPDP because the two regimes judge privacy risk through different enforcement models.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Runtime consent enforcement is now a governance requirement, not a privacy enhancement. LEVO’s central point is that DPDP changes the unit of compliance from documentation to system behaviour. That matters because a rights-driven model can tolerate some divergence between policy and execution, while a consent-centric model cannot. For identity teams, this means data access decisions and consent state have to be linked at the point of use, not only at the point of collection.
A question worth separating out:
Q: What should organisations change first when moving from GDPR readiness to DPDP readiness?
A: Start by mapping where consent is checked and where it disappears across application and API flows. That gives you the earliest and most actionable view of whether the organisation can enforce purpose-bound processing in live systems. Once those blind spots are visible, retention, deletion, and access controls can be aligned to them.
👉 Read our full editorial: GDPR compliance is not enough for DPDP readiness in India