Data Principal Rights: What Your Users Can Demand Under DPDPA

Sections 11-14 of the DPDPA give Indian users — "Data Principals" — four rights that you, as a Data Fiduciary, must honour. If you do not have an operational workflow to handle these requests, you are gambling on never getting one. This is the practitioner's guide to building Data Subject Request (DSR) operations under Indian law.

The four rights

Section 11 — Right to information about personal data

The Data Principal can ask:

• What personal data of theirs you are processing
• The processing activities you carry out
• The identity of any other Data Fiduciaries with whom you have shared their data, and the categories of data shared

Section 12 — Right to correction, completion, updating, and erasure

The user can demand correction of inaccurate or misleading data, completion of incomplete data, update of outdated data, and erasure of data that is no longer necessary for the purpose.

Note: the right to erasure is not a general "right to be forgotten." It applies when the data is no longer necessary for the purpose, when consent has been withdrawn, or when retention is no longer permitted.

Section 13 — Right of grievance redressal

The user can complain to you. You must respond within a "reasonable time" (the Rules and best practice converge on 15-30 days). If they remain unsatisfied, they can escalate to the Data Protection Board.

Section 14 — Right to nominate

The user can nominate another individual to exercise their rights in case of death or incapacity. This is unique to DPDPA and has no GDPR equivalent.

What about portability?

The DPDPA does not include a general right to data portability (unlike GDPR Article 20). This is a meaningful narrowing — you do not need to export user data in a machine-readable format unless the user is exercising a different right (e.g., correction).

Building the DSR workflow

You need:

1. An intake channel. A form, email address, or in-app flow. Publicise it in the privacy policy and product UI.
2. Identity verification. Confirm the requester is the actual Data Principal — not a malicious actor harvesting data. For account holders, verifying via the registered email/OTP is sufficient. For non-account requesters, more friction is justified.
3. An internal ticket system. Log every request with timestamps, the request type, the data scope, and the eventual disposition. This is your defence in a Board inquiry.
4. An execution path. Engineering ticket -> data team query -> response packaging -> review -> send. This must be repeatable, not heroic.
5. A response timer. 30 days is the de facto standard. Track in your ticket tool.

Common request scenarios and how to handle them

"What data do you have on me?" (Section 11)

Respond with: account profile fields, transactional history (timestamps and amounts; not full payment details), support tickets, marketing consents, and the categories of any third-party Data Fiduciaries you have shared with. You do not have to give them raw logs or every database row.

"Correct my email/phone/name" (Section 12)

Best handled in product (account settings page). If outside the product (e.g., on an old order), accept via your DSR form and update via internal tooling.

"Delete my account and all my data" (Section 12)

Subtle one. You may need to retain some data:

• Tax/GST invoices for 8 years (legitimate use under Section 7(c))
• Fraud prevention logs (legitimate use)
• Legal hold for active litigation

Tell the user what you are deleting, what you are retaining, and why. Anonymize what you retain.

"Stop sending me marketing" (Section 6 + 12)

This is a consent-withdrawal request. Honour immediately. Should be a one-click unsubscribe by law.

"I want to nominate my brother to exercise my rights" (Section 14)

New territory. Best practice: a form that captures the nominee's identity and proof, signed by the user. Store the nomination on the user's profile. Activate only on incapacity proof or death certificate.

What if you can't respond in time?

If the request is complex (e.g., multi-system data export), you can extend the timeline with a clear written explanation to the user. Do not silently miss the deadline.

What if the request is abusive?

The Section 15 duties on Data Principals include not filing false or frivolous complaints. If a user files 50 DSRs in a week with no genuine purpose, you can refuse and document the refusal. The Board may even penalise the user (up to ₹10,000).

Tooling

For small teams: a Notion or Airtable database + a Typeform intake. For mid-size: Zendesk or Freshdesk with custom DSR ticket types. For large: dedicated tools like OneTrust DSR, BigID, or DataGrail.

Bottom line

Build the DSR pipeline before you receive your first request, not after. The first DSR you handle badly often becomes the first complaint to the Data Protection Board. Generate a privacy policy that publishes your DSR endpoint clearly.