Notifications
Clear all
Topic starter
10/07/2026 9:07 pm
TL;DR: India’s DPDPA looks familiar to GDPR teams, but its consent-centred operating model changes lawful processing, notice design, breach response, and vendor accountability, according to OneTrust. Privacy programmes that treat DPDPA as a simple GDPR extension will miss the operational redesign it requires.
NHIMG editorial — based on content published by OneTrust: Why GDPR Readiness Does Not Automatically Prepare Organizations for India’s DPDPA
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should organisations prepare for DPDPA if they already comply with GDPR?
A: They should treat DPDPA as a separate operating model, not a compliance overlay.
Q: Why does DPDPA place so much emphasis on consent governance?
A: Because many processing activities depend on consent or narrow legitimate uses, consent becomes the operational gate for collection, use, and downstream sharing.
Q: What do privacy teams get wrong when they reuse GDPR workflows for DPDPA?
A: They often assume lawful basis, breach, and vendor processes can be reused without adjustment.
Practitioner guidance
- Rebuild lawful-basis mappings for India Catalogue every processing activity that relies on legitimate interests, contractual necessity, or broad GDPR assumptions, then map it to DPDPA consent or defined legitimate use.
- Test consent propagation end to end Validate that consent capture, withdrawal, and purpose restrictions are enforced across websites, mobile apps, customer systems, and vendor-integrated workflows.
- Localise breach and grievance workflows Create India-specific escalation paths for notification to the Data Protection Board, affected individuals, and internal stakeholders.
What's in the full article
OneTrust's full blog covers the operational detail this post intentionally leaves for the source:
- The side-by-side lawful processing comparison between GDPR and DPDPA, including where legitimate interests no longer map cleanly.
- The notice, consent, and withdrawal workflow implications for websites, mobile apps, and vendor-supported data collection.
- The children’s data and breach notification differences that privacy and security teams need to localise for India.
- The operational readiness checklist for teams that already have GDPR controls but need DPDPA-specific governance.
👉 Read OneTrust's analysis of why GDPR readiness does not guarantee DPDPA readiness →
DPDPA consent governance: what GDPR-mature teams still miss?
Explore further
10/07/2026 9:30 pm
DPDPA is a consent-operating-model shift, not a GDPR translation exercise. The article correctly frames the problem as structural rather than linguistic. GDPR-mature organisations often assume shared terminology implies shared control design, but DPDPA puts much more weight on explicit consent capture, revocation, and evidence. For privacy, security, and identity programmes, that means the control boundary moves from policy wording to operational enforcement. Practitioners should treat DPDPA readiness as a workflow redesign project, not a document update.
A question worth separating out:
Q: Who is accountable when DPDPA compliance fails across vendors and processors?
A: The data fiduciary remains the primary accountability point, even when processors and service providers are involved. That means vendor oversight, contract language, audit rights, and escalation paths must be designed around fiduciary responsibility rather than assuming processor obligations carry the same weight as under GDPR. Accountability needs to be operational, not just contractual.
👉 Read our full editorial: Why GDPR readiness does not equal DPDPA readiness
