Data Principal Rights Under DPDP: The Complete List (and What Isn't on It)

Who this is for: DPOs, compliance teams and legal counsel who need to know exactly what individuals can ask for under the DPDP Act, and how to build a process that answers them correctly and on time.

Every right in a privacy law becomes a workflow inside the business that has to honour it. A request arrives through some channel, someone has to verify who sent it, someone has to find the data across systems, someone has to decide what can and cannot be released or deleted, and someone has to respond, with evidence that all of this happened.

The DPDP Act gives individuals, called Data Principals, a shorter and more targeted list of rights than the GDPR. That makes the process simpler to build, but only if you build it for the Indian law rather than copying a European one. This guide sets out each right, its limits, the duties individuals owe in return, and the operating model that makes it work. For the wider law, see The DPDP Act, Explained.

The four rights at a glance

Section 11: the right to access information

A Data Principal can obtain from the fiduciary:

1. a summary of the personal data being processed and of the processing activities carried out on it
2. the identities of all other Data Fiduciaries and Data Processors with whom the data has been shared, with a description of the data shared
3. any other information related to their personal data and its processing that the Rules may prescribe

Three practical points follow.

It is a summary, not a copy. The Act asks for a summary of the data and processing. That is lighter than a full data export, but it still has to be accurate and complete enough to be meaningful.

The sharing disclosure is demanding. Most organisations cannot easily list every fiduciary and processor that has received a given customer's data. Answering this part of a request reliably requires a maintained map of data flows to vendors and partners. That is one of the strongest practical reasons to keep a Record of Processing Activities.

Scope is limited to consent-based processing. The right applies to personal data the individual consented to, including data they voluntarily provided under Section 7(a). It does not extend to data processed under other legitimate uses. The sharing disclosure also does not cover sharing with authorities authorised by law to prevent, detect or investigate offences, where the request was made in writing.

Section 12: the right to correction and erasure

A Data Principal can ask the fiduciary to correct inaccurate or misleading data, complete incomplete data, update data, and erase data, for personal data they consented to or voluntarily provided.

On receiving a correction request, the fiduciary must correct, complete or update the data. On receiving an erasure request, it must erase the data unless retaining it is necessary for the specified purpose or for compliance with any law in force (Section 12(3)).

Two connected duties make erasure more than a reactive right:

• Section 8(7) requires erasure once consent is withdrawn or the purpose is no longer being served, whether or not anyone asks.
• Rule 8 requires 48 hours' notice to the individual before erasure where the Third Schedule's inactivity rule applies, and keeps a one-year minimum retention for logs and associated data.

When you refuse an erasure request because a law requires retention, tell the individual which obligation applies and when the data will be erased. "We are required by law to retain this" without more is likely to become a grievance.

Section 13: the right to grievance redressal

Every fiduciary, and every Consent Manager, must provide a readily available means of grievance redressal for any act or omission concerning its obligations or the individual's rights. Rule 14 requires a response within a period that does not exceed 90 days.

Section 13(3) makes this route mandatory before escalation: a Data Principal must exhaust the fiduciary's grievance mechanism before complaining to the Data Protection Board. A well-run grievance process therefore resolves issues before they become regulatory matters. A poor one sends them straight to the Board, with your handling of the grievance as part of the record.

Section 14: the right to nominate

A Data Principal can nominate another individual to exercise their rights in the event of their death or incapacity. Incapacity covers inability to exercise rights due to unsoundness of mind or infirmity of body. Rule 14 provides that nomination is made in accordance with the fiduciary's terms of service and applicable law.

This is unusual among global privacy laws. Few organisations have a process for it, and fewer still for verifying a nominee's authority when they act. Build it now, rather than improvising when a bereaved family member first asks.

What isn't on the list

Organisations moving from GDPR programmes should note what the DPDP Act does not grant:

• No right to data portability. Individuals cannot demand their data in a structured, machine-readable format for transfer to another provider.
• No general right to object. There is no standalone right to object to processing. Where processing relies on consent, withdrawal under Section 6(4) serves a similar function.
• No right to restrict processing as a separate right.
• No specific right regarding automated decision-making.

Copying a GDPR request form will invite requests your process does not need to handle and confuse Indian customers. Design the intake for the four DPDP rights, plus consent withdrawal.

Duties of Data Principals

Section 15 is a distinctive feature of the Indian law. When exercising their rights, Data Principals must:

• comply with applicable laws
• not impersonate another person when providing personal data
• not suppress any material information when providing personal data for government documents or identity proofs
• not register a false or frivolous grievance or complaint
• furnish only verifiably authentic information when exercising the right to correction or erasure

A breach of these duties can attract a penalty of up to ₹10,000. For businesses, Section 15 provides a principled basis for handling clearly abusive or fraudulent requests. It is not a reason to treat ordinary requests with suspicion.

How individuals must be able to reach you

Rule 14 requires every fiduciary to publish prominently on its website or app:

• the means by which a Data Principal can make a request to exercise their rights
• any particulars, such as a username or identifier, needed to identify them under your terms of service

Section 8(9) also requires you to publish the business contact information of your Data Protection Officer, if you have one, or of a person who can answer questions about your processing. Rights can also be exercised through a Consent Manager, so your systems should be able to receive requests from that channel.

Building a rights process that works

A dependable rights process has five stages. Each needs a named owner and leaves a record.

1. Intake. One published route, ideally a web or in-app form that captures the right being exercised and the identifier you need, with email and Consent Manager requests routed into the same queue.
2. Verify. Confirm the requester's identity using information you already hold, without collecting more than you need. Verify nominees' authority separately.
3. Locate. Use your data map to find the individual's data across systems, including vendors.
4. Decide. Apply the limits: is the data in scope of Sections 11 and 12, and does a legal retention obligation override erasure? Document the reasoning.
5. Respond and record. Reply in plain language, carry out any correction or erasure across systems and processors, and keep evidence of each step.

The Rules fix 90 days only for grievances. Set a much shorter internal target for access, correction and erasure requests. Most well-run programmes aim for 30 days or less. Unanswered requests tend to become grievances, and grievances become Board complaints.

Common mistakes

• Building for GDPR rights. Portability and objection workflows add cost without a legal requirement.
• No data map. Without one, the Section 11 sharing disclosure and full erasure across systems are close to impossible.
• Erasing the front end only. Deleting a profile but leaving the data in the CRM, warehouse and vendor systems is not erasure.
• Silent refusals. Refusing erasure on legal grounds without explaining why invites a grievance.
• No nominee process. Section 14 requests will arrive at difficult moments for families. Have the process ready.

How ConsentifyAI helps

ConsentifyAI's rights management module gives you one published intake for all four DPDP rights and consent withdrawal, with identity verification built in. Each request is matched against your Record of Processing Activities to locate the individual's data across systems and vendors. Legal-hold rules are checked automatically before erasure, deadlines are tracked against your internal targets and the 90-day grievance limit, and every step is written to a tamper-evident audit trail.