DPDPA gives Indian users six enforceable rights over their personal data, and they will start using them. Here's what compliance and CX teams need ready before the first request lands.
July 2026 · 5 min read
The DPDPA is creating a new kind of user in India — one with enforceable rights over their own data, and a growing awareness of what those rights actually are. Privacy coverage in the media, awareness campaigns, and increasingly vocal user communities mean your customers, employees, and app users are about to start asking questions your operations teams may not be ready to answer.
This isn't a legal breakdown — you have lawyers for that. It's about the operational reality: what people will actually ask, what you need in place before they do, and where companies typically fail before the first request even arrives.
Section 11 gives every Data Principal the right to a summary of the personal data you process about them, plus the identities of any Data Fiduciaries you've shared it with.
In practice, nobody quotes the Act at you — they say things like "can I see everything you have on me?" or "why do you still have my address, I only ordered once, back in 2022." Answering that requires a readable, per-user data inventory you can actually pull, not a privacy policy that lists categories in the abstract. The common failure: companies document what types of data they collect, but have no mechanism to retrieve what they specifically hold on one named individual. That's a Section 11 gap even if the privacy notice reads perfectly.
Section 12(1) grants the right to correction of inaccurate data. It sounds like a simple ask. Operationally, it rarely is.
The request usually shows up as "my name's spelled wrong on my account" or "I've updated my address three times and it keeps reverting." Responding well means confirming the correction actually propagates — not just to the user-facing profile, but to every downstream system: CRM, marketing automation, analytics, third-party integrations. The typical failure is a siloed fix: the profile gets corrected, the CRM still has the old value, and the next communication goes out wrong anyway. That's a partial correction still doing damage.
Section 12(3) grants the right to erasure, and users mean it literally: "I closed my account, I want everything gone." The operational complexity here is real — deletion has to cascade through your primary database, relevant backups, partner data shares, marketing lists, and analytics datasets. Most companies we've seen can clear a user from their main product database within 24 hours. The gap is always downstream: the warehouse that ingests nightly, the third-party analytics tool, the marketing vendor who received the list six months ago and never got the follow-up instruction.
Section 6(4) requires that withdrawing consent be as easy as giving it. If you offered a single checkbox to opt in, the opt-out can't require an email to a support address with a five-day response time. Users will be blunt about it: unsubscribe me, permanently, from everything. The requirement is that withdrawal is immediate, self-service, and verifiable. The typical failure pattern: buried opt-out flows, multiple separate lists each needing its own separate action, or a withdrawal that stops email but leaves SMS and push notifications running.
This is the grey zone where most companies are quietly non-compliant without realising it. Section 13 establishes the right to grievance redressal, and requires a named Grievance Officer with a reachable contact route. Most companies have that much — a name in the privacy policy, an email address.
What most don't have is an SLA, a case number, an escalation path, or any way to show a complaint was received, triaged, and closed within a defined window. A grievance inbox nobody actively monitors isn't redressal — it's a formality with nothing behind it. The real test isn't whether a contact point exists, it's whether a Data Principal can prove their complaint was actually handled. If you can't produce that evidence, you're non-compliant regardless of what the privacy policy says.
This right gets less attention than it deserves. The DPDPA lets a Data Principal designate someone — usually a family member — to exercise their data rights if they die or become incapacitated. Most organisations haven't built anything for this at all. The question will come — "how do I nominate my spouse?" — and today, at most companies, the honest answer is: there's no mechanism yet.
Being ready means having a Rights Center: a self-service interface where a Data Principal can submit access, correction, and erasure requests, withdraw consent, file a grievance, and manage nominations — all as a single, timestamped, tracked workflow, not a form that drops an email into a generic inbox somewhere.
Underneath that interface, the consent infrastructure needs to be machine-readable and config-driven. A consent record that only lives as a user-facing log isn't actionable — what you need is a structured schema capturing what was consented to, for which purpose, under which notice version, and when, that downstream systems can consume programmatically. When someone withdraws consent, it's that machine-readable record — not a manual update somewhere — that propagates the instruction. Processing APIs need to check against purpose identifiers drawn from that same config, before they execute, not after the fact.
That's the actual difference between a compliance record and a compliance control. Most organisations have built the first. Very few have built the second.
The companies likely to struggle are the ones still treating these rights as rare edge cases instead of a routine operational workflow. Request volume will scale directly with user awareness, and awareness is about to scale fast once enforcement actually begins.
Your users are about to start asking questions your systems aren't yet built to answer. DPDPA gives them the right to ask — and the right to escalate when you don't answer properly.
Answering these reliably needs a real system behind it, not an inbox — our RoPA, DPDR & CDJR registers service builds the record-keeping that makes rights fulfilment auditable.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation