DPDP rights
What people can ask of you, and a desk that can answer them.
The Act gives every data principal a small set of rights and asks her to use them honestly. Most of the work for a business sits in the plumbing: one way in, a sensible identity check, a search that reaches every system and vendor, a clear answer, and a log that proves it.
Back to DPDP services01 · The rights
Five things a data principal can ask for
Four rights in Chapter III, plus withdrawal of consent in section 6.
- s. 11AccessA summary of her data and what you do with it, and the names of other fiduciaries and processors you shared it with, with a description of what went to each.
- s. 12Correction, completion, updating, erasureFix wrong or misleading data, fill gaps, bring it up to date, and erase it unless the purpose or a law still needs it.
- s. 13Grievance redressalA ready route to complain about you or your consent manager. She must use it before going to the Board.
- s. 14NominationName another person to use her rights if she dies or loses capacity.
- s. 6(4)Withdrawal of consentAt any time, and as easily as she gave it.
Access and correction attach to data she gave with consent, including data she volunteered for a purpose under section 7(a). Data held only on another legitimate use, such as employment, sits outside those two rights, though your other duties still apply.
An access answer need not list sharing with another fiduciary that is legally authorised to obtain data, where it asked in writing to prevent, detect or investigate offences or cyber incidents.
02 · Her duties
The individual has duties too
Section 15, backed by a penalty ceiling of 10,000 rupees.
- Follow the law while using her rights.
- Not impersonate anyone when giving personal data.
- Not hide material facts when giving data for a State-issued document, identifier or proof of identity or address.
- Not file false or frivolous complaints with a fiduciary or the Board.
- Give only verifiably authentic information when asking for correction or erasure.
For your workflow these duties matter in one way. They support asking for reasonable proof before changing a record, and they give you a recorded reason when a correction rests on information you cannot verify.
03 · Workflow
A five-step request workflow
Intake, identity, scope, response, log.
Intake
One way in, published where people will find it.
- What happens
- Publish the means for making a request and the identifier you need, as rule 14 asks
- Route stray requests (emails to sales, posts on social media) into the same queue
- Acknowledge receipt with a reference number
- You get
- One queue, one ticket per request
- Good practice
- A web form and an email address, both feeding the queue
- Watch for
- A request channel harder to use than the sign-up was
Identity check
Proportionate to the request and the risk.
- What happens
- Match the request to an account using the published identifier
- Ask for more proof only when the request and the risk justify it
- Check the authority of nominees, parents and guardians
- You get
- A recorded identity decision
- Good practice
- Verify inside the logged-in account where one exists
- Watch for
- Collecting a copy of an ID document you never needed before
Scoping
Every system on the data map, and every processor.
- What happens
- Search each system on the data map, not just the main database
- Ask each processor holding the data to search and act too
- Separate data a law requires you to keep from data you can change or erase
- You get
- A list of systems, processors and findings
- Good practice
- A named owner per system, kept with the data map
- Watch for
- Forgetting backups, exports, support tools and analytics copies
Response
Plain, complete, and honest about refusals.
- What happens
- Send the summary and sharing list, or confirm the change made
- Explain any part refused and why, such as a legal retention duty
- Include the contact point's details, which rule 9 requires in every rights response
- You get
- A response letter or in-app message
- Good practice
- Templates per request type, reviewed by counsel
- Watch for
- Sending raw database exports to the person
Logging
The record that proves the rest.
- What happens
- Record dates, decisions, systems searched and processors contacted
- Track response times against your published period
- Feed repeat issues back to product and data owners
- You get
- A request register
- Good practice
- A monthly review of the register by the privacy lead
- Watch for
- Keeping the register wider or longer than needed: it holds personal data too
04 · Request clock
A request clock with your own targets
The Act sets no general deadline for access, correction or erasure. Set yours.
The Rules ask each fiduciary to publish the period within which it will respond to grievances, and cap it at 90 days. That is the only response ceiling in the Rules for this workflow. The rest of the clock is yours to set, publish where sensible, and then keep.
| Stage | Legal anchor | Your internal target |
|---|---|---|
| Acknowledge the request | None set in the Act or Rules | ____ working days |
| Complete the identity check | None set | ____ working days |
| Search systems and processors | None set | ____ working days |
| Answer an access request | None set | ____ days |
| Correct, complete or update | None set | ____ days |
| Erase, or explain why not | None set; the purpose and the law decide what stays | ____ days |
| Act on a withdrawal, including at processors | Within a reasonable time (s. 6(6)) | ____ days |
| Resolve a grievance | Your published period, at most 90 days (rule 14(3)) | ____ days, published |
Whatever goes in the last column, the register must show you meet it.
05 · Where it breaks
Where request handling breaks
Six faults that show up in almost every first review.
- Only the main database is searched. Copies in support tools, spreadsheets and analytics stay untouched.
- Processors are never asked. The fiduciary must make processors erase and stop; silence leaves data behind.
- Deactivation passed off as erasure. A hidden account is still personal data in your systems.
- Identity checks that over-collect. Asking for documents you never held creates new data to protect.
- Requests handled outside the log. An answer from a salesperson's inbox leaves no proof.
- Legal holds ignored. Erasing records a law requires you to keep breaks a different rule.
Sources: The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), sections 2(j), 6, 11 to 15 and the Schedule; the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)), rules 9 and 14.
Questions about rights requests
Must we answer within 30 days?
The Act sets no such deadline. Set your own periods and keep them.
Neither the Act nor the Rules fix a period for access, correction or erasure. The Rules cap the grievance response period you publish at 90 days. Most teams set shorter internal targets so a request never turns into a grievance.
Can a parent make a request for a child?
Yes. For a child, the data principal includes the parent or lawful guardian.
The Act defines the data principal of a child to include her parents or lawful guardian. Check that the person asking really holds that role before acting.
Can we charge a fee for requests?
Neither the Act nor the Rules provide for one.
We found no fee provision in the Act or the Rules. A fee would also make rights harder to use than consent was to give, so plan for free handling.
What if the person goes straight to the Board?
She must use your grievance route first.
Section 13(3) asks her to exhaust your grievance route before approaching the Board. That makes a working, published grievance process your first line of defence.
Does access mean a full copy of the data?
The Act asks for a summary, not a full copy.
Section 11 asks for a summary of the data and the processing, and the names of those you shared it with. A clear summary often serves people better than a raw export.
Build a request desk that can prove its answers.
A DPDP readiness assessment tests your intake, identity checks, search reach and logs with sample requests. Counsel should confirm how the law applies to your contracts.