Data Principal rights under the DPDP Act — and how to operationalise them
Access, correction, erasure, grievance redressal and nomination: what each right requires, the 90-day grievance ceiling, and a workflow that scales.
The DPDP Act gives every individual in India a set of enforceable rights over their personal data. For a business, each of those rights translates into a workflow: a request comes in, it has to be verified, routed, actioned across several systems and answered within a deadline — and you need records to show you did it properly.
This article walks through each right under Sections 11 to 14, what the 2025 Rules add, and how to build a request-handling process that scales beyond a shared inbox.
The four rights at a glance
| Right | Section | What the person can ask for |
|---|---|---|
| Access to information | 11 | A summary of their data and processing, and the identities of other fiduciaries and processors it has been shared with |
| Correction and erasure | 12 | Correction, completion, updating, and erasure of data no longer needed |
| Grievance redressal | 13 | A readily available way to complain to you before going to the Board |
| Nomination | 14 | Naming someone to exercise their rights after death or incapacity |
These rights apply to processing based on consent and, for access and erasure, mainly to data processed with consent or provided voluntarily. Processing under other legitimate uses may limit some of them, so your workflow needs to know the legal basis for each data set.
Right to access information
A Data Principal who has given consent can ask you for:
- a summary of the personal data being processed and the processing activities;
- the identities of all other Data Fiduciaries and Data Processors with whom the data has been shared, along with a description of the data shared;
- any other information prescribed by the Rules.
The second item is where many organisations struggle. To answer it, you need an up-to-date register of every vendor, partner and group company that receives personal data — and which categories of data each receives. If your data inventory does not capture outbound flows, fix that first.
Sharing with law-enforcement or investigative agencies under a lawful request does not have to be disclosed in an access response.
Right to correction, completion, updating and erasure
On request, you must correct inaccurate or misleading data, complete incomplete data and update outdated data. You must also erase personal data that is no longer necessary for the purpose for which it was processed — unless retention is required for compliance with a law.
Erasure is not just deleting a row in your production database. A complete erasure process covers:
- Primary application databases and data warehouses.
- Marketing platforms, CRM, support desk and analytics tools.
- Data shared with processors — who must erase on your instruction.
- Backups, handled through a documented policy (for example, data is put beyond use and expires with the backup cycle).
Retention beyond the requestThe Rules require fiduciaries and processors to retain certain personal data, associated traffic data and processing logs for at least one year for specified purposes such as investigating breaches. Build these legal holds into your erasure logic so you do not delete what you are required to keep.
Grievance redressal: the 90-day ceiling
Every Data Fiduciary must provide a readily available means of grievance redressal and publish how it works. Under the Rules, you must respond to grievances within the period you publish — which cannot exceed 90 days. A Data Principal must exhaust your grievance mechanism before approaching the Data Protection Board.
Ninety days is a ceiling, not a target. Customers expect far faster responses, and a slow, opaque process is the most reliable way to turn a routine request into a regulatory complaint. Many organisations set an internal service level of 7 to 30 days depending on the request type.
Right to nominate
A Data Principal may nominate another individual to exercise their rights in the event of death or incapacity (being unable to exercise rights due to unsoundness of mind or infirmity of body). Your systems should be able to record a nominee and accept requests from them, with appropriate verification — for example, a death certificate or a medical certificate.
How the request must be made — and how you must enable it
The Rules require Data Fiduciaries to publish, on their website or app, the means by which a Data Principal can make a rights request, and the particulars (such as a username or customer ID) needed to identify them. In practice this means:
- a clearly labelled "Your privacy rights" page or in-app section;
- a simple web form or in-app flow, not only an email address;
- identity verification proportionate to the risk — re-authentication for logged-in users, OTP to the registered mobile number for others;
- a reference number and acknowledgement for every request.
Building a scalable rights-request workflow
Whether you receive five requests a month or five thousand, the same stages apply:
- Intake — one entry point per channel, all feeding a single queue.
- Verify — confirm the requester is the Data Principal or their lawful guardian or nominee.
- Classify — access, correction, erasure, grievance, withdrawal or nomination.
- Locate — query the data inventory to find every system holding the person's data.
- Action — execute in each system and instruct processors; record exceptions with legal reasons.
- Respond — reply in clear language, within your published timeline, explaining anything you could not do and why.
- Record — keep an audit trail of every step for the Board.
| Metric to track | Healthy signal |
|---|---|
| Median time to close | Well under your published SLA |
| Requests breaching SLA | Zero, with root causes logged |
| Requests escalated to the Board | Rare, and each reviewed |
| Systems covered by automated search | Rising quarter on quarter |
Common mistakes to avoid
- Asking for more identity documents than you hold about the person — verification should not create new data risk.
- Deleting data the law requires you to keep, such as tax and accounting records.
- Forgetting processors: an erasure is incomplete while your email platform still holds the contact.
- Treating every complaint as a support ticket rather than a statutory grievance with a deadline.
- Answering access requests with raw database exports that users cannot understand.
Rights handling is where your customers experience your privacy programme directly. Done well, it builds trust; done badly, it is the fastest route to the Data Protection Board. Next in the series: what to do in the first 72 hours after a personal data breach.
