DPDPA Data Principal Rights: How to Handle Access, Correction and Erasure Requests

Most DPDPA readiness conversations start with consent banners. The harder operational work sits on the other side: what happens when a customer, employee or student writes in and asks, "What data do you hold on me, and can you delete it?" Under the Digital Personal Data Protection Act, 2023, that request is a legal right, and the DPDP Rules, 2025 put a clock on your response.

This guide covers the four rights your organisation must be ready to honour, what the Rules require, and a practical workflow for handling requests at scale.

The four rights, in plain English

• Right to access information (Section 11). A Data Principal can ask for a summary of the personal data you process about them, the processing activities involved, and the identities of other Data Fiduciaries and Data Processors you have shared it with.
• Right to correction and erasure (Section 12). They can ask you to correct inaccurate data, complete incomplete data, update it, or erase it, unless you must keep it for the specified purpose or to comply with another law.
• Right to grievance redressal (Section 13). You must provide a readily available way to raise a grievance and respond to it. The Rules cap your response time at 90 days.
• Right to nominate (Section 14). A Data Principal can nominate another person to exercise their rights in the event of death or incapacity. GDPR has no direct equivalent, so global privacy tools often miss it.

When these obligations bite

The DPDP Rules were notified on 13 November 2025 with a phased start. The Rules that operationalise Data Principal rights, including Rule 14, take effect on 13 May 2027. MeitY has floated a proposal to compress the timeline to 12 months, which would pull the deadline forward to November 2026, but as of this writing it has not been notified. Either way, a rights-handling process takes months to design, staff and test, so the time to build it is now. See our DPDPA compliance timeline for the full phase-by-phase breakdown.

What the Rules require you to publish

Rule 14 expects every Data Fiduciary to publish, prominently on its website or app, the means by which a Data Principal can make a request, along with any identifier you need to verify them (a customer ID, registered mobile number or employee code, for example). If you are a Significant Data Fiduciary, you must also publish your Data Protection Officer's contact details; everyone else must publish contact details of a person who can answer questions about processing.

A seven-step workflow that holds up

1. One front door

Create a single intake channel, typically a web form plus a dedicated email address, and route every request there. Requests that arrive through sales reps, WhatsApp or branch staff should be logged into the same system the same day. Scattered intake is the most common reason organisations miss deadlines.

2. Verify identity proportionately

Confirm the requester is who they claim to be, using identifiers you already hold. An OTP to the registered mobile number is usually enough. Do not demand more personal data than you need to verify; asking for an Aadhaar copy to process a newsletter unsubscribe creates a new privacy problem.

3. Know where the data lives

You cannot answer an access request without a data map. List every system holding personal data: CRM, ERP, HRMS, marketing automation, support desk, spreadsheets on shared drives, and every vendor you pass data to. For each, record the owner and how to search by individual.

4. Fan out and track

Each verified request becomes a ticket with sub-tasks for every system owner. Track due dates against the 90-day ceiling, but set an internal target of 30 days so escalations have room.

5. Apply retention rules before erasing

Erasure is not absolute. Tax, labour and sector-specific laws may require you to keep certain records. Document why any data is retained, restrict access to it, and erase everything else, including copies held by your processors.

6. Respond in plain language

An access response should be understandable by a non-lawyer: what you hold, why, who you shared it with. Avoid raw database dumps.

7. Keep evidence

Log the request, verification method, actions taken, dates and the final response. If a Data Principal escalates to the Data Protection Board, this record is your defence.

Common mistakes to avoid

• Forgetting processors. Erasing data in your CRM but leaving it with your email marketing vendor or call centre is incomplete compliance.
• Ignoring nominations. Build a simple way to record a nominee and to verify a nominee's authority when they come forward.
• Treating employees differently. Staff and job applicants are Data Principals too, and HR systems are often the least mapped.
• Manual-only handling. A few requests a month can run on email; a consumer brand with lakhs of customers needs workflow automation.

How DAPro helps

DAPro (Data Adhikaar), Qodequay's DPDPA compliance platform, brings consent, rights handling and compliance evidence into one system. Its Evidence Vault keeps tamper-evident records of what was requested and what you did, it supports 22 languages for notices and communication, and 25+ connectors link it to the systems where personal data actually lives. Book a 30-minute walkthrough to see it against your own data map.

This article is for general information and is not legal advice. Always confirm obligations against the official text of the DPDP Act and Rules and consult qualified counsel for your situation.