At a glance
The DPDP Act gives every person whose data you hold enforceable rights — to access it, correct it, erase it, and raise a grievance — and the DPDP Rules require you to publish how they can exercise them and respond within 90 days at most. Handling these by ad-hoc email won’t survive contact with volume or a complaint. The build is a small, repeatable pipeline: published channel, identity check, classification, the action itself (including at your processors), and a logged, dated response — lawful refusals stated, not silent.
Educational resource only. This explains how to build a rights-request process under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.
The situation
Your privacy policy says users can access, correct or delete their data — most do. Then a real request lands in the support inbox: “please delete everything you have about me.” Who owns it, how do you know the sender is the account holder, what do you actually delete, what about the copy at your payroll or analytics vendor, and who writes back? If the honest answer is “we’d figure it out,” you don’t have a process — and the clock on a legally-timed response starts the day the request arrives.
Why this is a process problem, not a policy problem
A rights request fails operationally — wrong inbox, no identity check, no deletion path, no record — long before it fails legally. Stating the rights is the easy half; the DPDP Rules also require you to publish the means by which a person makes a request and the identifiers they should furnish so you can find their record (Rule 14). That’s the regulation telling you what to build: a defined intake, a matching step, and a way to act on what you find. Each request type then needs a different action — access produces a report, correction changes a record, erasure removes one — but they can and should run through one pipeline, because they share every step except the action.
What the law actually requires you to handle
Four rights, one channel requirement, one clock. The requests your process must be able to receive and act on:
- Access (Section 11) — a summary of the personal data you hold about the requester, what you’ve done with it, and who it’s been shared with.
- Correction and erasure (Section 12) — fixing inaccurate or incomplete data, and erasing data once its purpose is served — unless a law requires you to retain it, in which case the retention has a named legal basis, not a shrug.
- Grievance (Section 13) — a working redressal route a person must be able to use before escalating to the Data Protection Board of India; your response window is capped at 90 days by the Rules, and your published timeframe is what a complainant will hold you to.
- Nomination (Section 14) — a person can nominate someone to exercise these rights for them (illness, incapacity, death), so your process can’t assume the requester is always the account holder in person.
These rights attach to data processed on the basis of consent, including data a person volunteered for a purpose — which for most private businesses is the bulk of what you hold.
Step by step: from published channel to closed request
Build it once, as a pipeline every request runs through.
- Publish the channel and the identifiers. One stated route for rights requests — a form, a dedicated email, an in-app setting — plus the identifiers you need to locate a record (registered email, phone, customer ID). Put it where your privacy policy and grievance section already live.
- Verify identity proportionately. Match the request to the record using the identifiers you published — a request from the registered email about that account usually suffices. Escalate verification only for sensitive scopes; demanding fresh ID documents to delete a newsletter signup is over-collection in its own right.
- Classify the request. Access, correction, erasure, withdrawal, grievance, or a nominee acting for someone — the classification decides the action and who owns it. Name an owner (your grievance contact is the natural one) so nothing sits in a shared inbox unowned.
Use the templateData deletion request template — the shape of a well-formed erasure request your process must be ready to receive. Run it through your own pipeline as a test: if any step has no answer, that’s the gap to fix.
- Act — including at your processors. An access request means compiling what you hold across your systems; a correction means fixing the live record; an erasure means deletion wherever the data lives — production, backups on their cycle, and every processor holding it on your behalf. Your vendor contracts need to support this before the first request arrives, not after.
- Apply exceptions transparently. Where a law requires you to retain some of the data (tax records, KYC under financial regulation), erase the rest and state what you kept and under which legal requirement. A lawful partial refusal, explained, closes a request; a silent one becomes a complaint.
- Respond in writing, within your published window. Confirm what was done, dated. Whatever timeframe you’ve published is your commitment; 90 days is the outer legal limit, not the target.
- Log the whole thing. Request, identity match, classification, action taken, exceptions applied, response sent, dates throughout. If a request ever reaches the Data Protection Board, this log is your account of having handled it properly.
Mistakes that quietly break a rights process
These are the failures that surface only when a determined requester — or the Board — tests the process:
- The support-ticket trap — rights requests closed as resolved tickets (“account deactivated”) without the underlying data being touched.
- Erasure that stops at your own database — processors, analytics tools and backups still holding what you confirmed was deleted.
- Identity checks that over-collect — demanding ID documents for low-stakes requests, creating new personal data in the act of deleting old.
- Silent refusals — retaining data under a legal obligation but never telling the requester what was kept or why.
- No dates, no log — actions genuinely taken but unprovable a year later, which is as good as not taken when a complaint arrives.
- Forgetting withdrawal is a trigger too — a consent withdrawal isn’t a rights request in name, but it obliges you to stop the processing it covered, and it deserves the same pipeline.
FAQ
How quickly do we have to respond to a rights request?
Within the timeframe you’ve published, and in any case within 90 days — the cap the DPDP Rules set for responding to rights requests and grievances. Faster published commitments bind you to the faster clock.
Do we have to delete data from backups too?
Erasure means the data stops being held, so backups can’t be a loophole — the practical pattern is deletion from live systems immediately and expiry from backup cycles on a defined schedule, with restoration processes that don’t resurrect erased records.
Can we refuse an erasure request?
Yes, where a law requires you to retain the data or a court order applies — but state specifically what you’re retaining and under which requirement, and erase everything the exception doesn’t cover.
Do we need to verify identity before acting?
Yes, proportionately — act on requests matched to the record via your published identifiers, and reserve heavier verification for sensitive scopes. Both acting on an impostor’s request and demanding excessive proof are failures.
Does this apply to data we process without consent, like employee data under the employment ground?
The access, correction and erasure rights formally attach to consent-based processing. But the grievance right applies regardless, and your security and retention duties cover everything you hold — so the pipeline is worth running for every request you receive, whatever the data’s basis.