Who Is a Data Principal Under the DPDP Act?
The Digital Personal Data Protection Act 2023 defines a Data Principal — and that's pretty straightforward — it's the person whose personal info you're collecting, storing, and using — anybody from customers to employees to users and just about anyone else you're working with whose data is under your care. And just to clarify, "Data Principal" is the same as "data subject" in GDPR-speak.
If that person is a kid — you know, a minor under 18 — then some other grownup has to step in and deal with all this, someone who can give their consent. Then, when it comes to rights under the new law, the Data Principal gets to choose another person — their nominee — to sort out things for them if they can't do it themselves or if they pass away.
The idea is that Data Principals have got five different rights to get sorted out here, and understanding what those rights mean, how to give them to your customers, and how to make them work are all pretty central to what this guide is about.
At a Glance: The DPDP Act 2023 gives Data Principals the right to: Access (Section 11), Correction & Erasure (Section 12), Grievance Redressal (Section 13), Nomination (Section 14), and Withdrawal of Consent (Section 6(4)). Fail to follow all these rules, and you could be facing fines of up to ₹50 Crore per category.
Right to Access Information
Know what personal data is held, the purpose of processing, and the list of processors and fiduciaries with whom data has been shared.
Right to Correction & Erasure
Correct inaccurate or misleading data; erase data that is no longer needed for the specified purpose.
Right to Grievance Redressal
Raise complaints directly with the Data Fiduciary and escalate to the Data Protection Board if unresolved.
Right to Nominate
Designate another individual to exercise Data Principal rights in case of death or incapacity. Unique to DPDP — no GDPR equivalent.
Right to Withdraw Consent
Withdraw consent at any time, with the ease of the same manner in which it was given. Withdrawal must take immediate effect.
No Service Denial
A Data Fiduciary cannot deny service to a Data Principal for declining non-essential consent. Services cannot be made conditional on non-necessary data processing.
DPDP Act vs GDPR: Rights Comparison
Indian businesses operating across borders often ask how Data Principal rights under DPDP compare to data subject rights under GDPR. The table below maps the key rights:
| Right | DPDP Act 2023 (India) | GDPR (EU) |
|---|---|---|
| Right to Access | Section 11 — summary of data + list of third parties | Article 15 — full copy + machine-readable format (portability) |
| Right to Correction | Section 12 — correct, complete, or update inaccurate data | Article 16 — right to rectification |
| Right to Erasure | Section 12 — erase when purpose fulfilled or consent withdrawn | Article 17 — "right to be forgotten" |
| Right to Grievance Redressal | Section 13 — internal mechanism + DPB escalation | Article 77 — right to lodge complaint with supervisory authority |
| Right to Nominate | Section 14 — nominate a person for post-death/incapacity rights | No equivalent — unique to DPDP |
| Right to Withdraw Consent | Section 6(4) — as easy as giving consent; immediate effect | Article 7(3) — right to withdraw; equivalent ease required |
| Right to Data Portability | Not in DPDP Act | Article 20 — machine-readable copy to another controller |
| Right to Object to Processing | Withdrawal of consent achieves same effect | Article 21 — explicit right to object |
Right to Access Information (Section 11)
What the Data Principal Can Request
According to Section 11 of the DPDP Act 2023, a Data Principal has the right to obtain from the Data Fiduciary:
- A summary of the personal data being processed and the processing activities undertaken in respect of such data
- The identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, and a description of the personal data so shared
- Any other information related to the personal data and its processing as may be prescribed in the Rules
In practice, this means a Data Principal who contacts you and says "Tell me what data you hold about me" is making a lawful access request under Section 11. You must respond with a summary of their personal data, the purposes for which it is being processed, and the list of third parties you have shared it with.
This is operationally demanding for organisations without a centralised data inventory. You need to know: which databases hold personal data, which CRM fields contain PII, which email marketing lists include this individual, which analytics logs have their identifiers, and which third-party processors (cloud vendors, analytics providers, payment gateways) have received their data. The access request response must be comprehensive — partial responses do not satisfy the right.
The response must be provided in a manner that is understandable to the Data Principal — not in raw database format, but in plain language. For data fiduciaries subject to GDPR as well, you will also provide a machine-readable copy under Article 20 (data portability) — DPDP does not mandate portability but does mandate understandable summaries.
Right to Correction and Erasure (Section 12)
Correction and Erasure Rights
Section 12 provides Data Principals with the right to:
- Correction: Correct inaccurate or misleading personal data
- Completion: Have incomplete personal data completed
- Update: Update personal data that is out of date
- Erasure: Have personal data erased when the purpose for which it was collected is no longer being served
The correction right is relatively straightforward to implement: provide a mechanism for data principals to submit corrections, verify their identity, update the data across all systems (not just the primary CRM — also in email lists, data warehouses, and anywhere the data has been replicated), and notify any third parties who have received the incorrect data.
The erasure right is more complex. According to DPDP Act 2023, Section 8(7), a Data Fiduciary shall not retain personal data beyond the period necessary to satisfy the purpose for which it was collected. The erasure right essentially operationalises this retention principle: when a data principal requests erasure and you have no remaining purpose or legal obligation for their data, you must erase it.
Comprehensive erasure is a must — just hitting 'delete' on a record in your CRM system isn't enough, you need to make sure that all the details are wiped from all systems & backups too, within a reasonable amount of time. That means getting rid of the data from things like analytics databases, email marketing platforms & even sending a message to third-party processors to delete the data too. And it's not just them you need to inform, they have to be audited to ensure they are erasing the data properly.
Right to Grievance Redressal (Section 13)
Two-Tier Grievance Mechanism
Section 13 establishes a two-tier grievance redressal system:
- Tier 1: Data Principal raises a grievance directly with the Data Fiduciary through its designated grievance mechanism
- Tier 2: If the grievance is not resolved within the period prescribed by the Rules, the Data Principal may approach the Data Protection Board of India
Every Data Fiduciary must publish a grievance redressal mechanism — a designated contact point (email address, web form, or dedicated portal) where data principals can file complaints about how their data has been handled. The contact details of the grievance mechanism must be provided in your Privacy Notice as required by Section 5.
The Grievance Officer, or the Data Fiduciary's nominated contact, has to reply quickly. The issue should be settled within the time limit set out in the Rules. If the Data Principal is still not satisfied after that, the matter can be taken to the Data Protection Board of India. The Board can look into it and order penalties if it finds that rules were not followed.
For Significant Data Fiduciaries, as listed under Section 10, the duties are more strict. They must name a Data Protection Officer who is based in India. This DPO acts as the step before the case reaches the Data Protection Board of India.
Right to Nominate (Section 14)
Nomination for Death or Incapacity
Section 14 grants every Data Principal the right to nominate another individual who shall, in the event of the Data Principal's death or incapacity, exercise the rights of the Data Principal in accordance with the provisions of the Act.
This right is unique to India's DPDP Act — there is no equivalent provision in GDPR or any other major data protection framework. The nomination mechanism must be made available by Data Fiduciaries, though the specific process and registration format will be prescribed in the Rules.
In day to day work, an organization has to do four things. First, it needs a way to record a nominee. This can be a form. The form should let people add the nominee's name, link to the person, and contact details. Second, it must keep the nomination data safe. The record should be tied to the account of the data principal. Third, it must check the nominee's identity. It must also confirm the data principal is dead or unable to act, before the nominee uses rights on that person's behalf. Fourth, it must treat requests from a verified nominee with the same care it gives to requests made by the data principal directly.
Right to Withdraw Consent (Section 6(4))
According to DPDP Act 2023, Section 6(4): "A Data Principal shall have the right to withdraw consent at any time, with the ease of the same manner in which consent was given, and upon such withdrawal, the Data Fiduciary shall, within a reasonable period, cease and cause its Data Processors to cease processing the personal data of the Data Principal."
From this rule, three duties follow. One, the act of withdrawal should be as simple as giving consent. Two, once withdrawal happens, the data fiduciary must stop processing in a "reasonable period" — for tech like cookies and tracking, this should mean stopping right away. Three, the data fiduciary must also make sure its data processors stop, so you have to inform your third parties, like Google Analytics, Meta, and your email tool.
The right to withdraw consent for cookie tracking is handled by your consent management platform. The right to withdraw consent for ongoing data processing activities (e.g., withdrawing consent to a personalisation programme you enrolled in) requires a separate DSR (Data Subject Request) workflow with SLA tracking. See our guide on cookie consent implementation for the technical side of consent withdrawal.
Automate Data Principal Rights Fulfilment
Consiva's DSR module handles all five rights — access, correction, erasure, grievance, and nomination — with SLA timers, identity verification, and immutable evidence trails.
Start Free on Consiva.ai — No Credit Card →SLA Timelines for Each Right
The specific response timelines will be prescribed in the DPDP Rules. Based on the draft Rules circulated for public consultation and international best practice, the following working timelines should be used for operational planning:
| Right | Working SLA | Notes |
|---|---|---|
| Access (Section 11) | 30 days | From receipt of valid, verified request. Complex requests may require extension. |
| Correction (Section 12) | 30 days | Must propagate correction to all systems and notify downstream processors. |
| Erasure (Section 12) | 30 days | For front-end systems; backup erasure within 90 days. Legal holds may extend. |
| Grievance Redressal (Section 13) | 30 days | Acknowledge within 24–48 hours; resolve within 30 days. Board escalation if unresolved. |
| Nomination Registration (Section 14) | 7 days | Confirm nomination registration to the Data Principal. |
| Consent Withdrawal (Section 6(4)) | Immediate | Cookie/tracking consent: real-time. Other processing: within reasonable period. |
These timelines are working estimates based on draft Rules. When final Rules are notified, update your SLAs accordingly. Consiva's DSR module automatically starts SLA timers when a request is received and sends escalation alerts as deadlines approach.
Identity Verification Before Fulfilling Rights
Before fulfilling any Data Principal rights request, you must verify that the requester is actually the Data Principal (or their authorised nominee). Without verification, you risk:
- Disclosing personal data to an unauthorised third party (a separate DPDP violation)
- Erasing data based on a fraudulent request, harming the legitimate Data Principal
- Correcting data incorrectly based on an impersonation attempt
Practical identity verification approaches:
- Authenticated portal: Require the requester to log in to their account before submitting a rights request. This links the request to a verified identity.
- Email verification: so for people who have emailed in, you need to send a verification link to the actual email address linked to the account, their on-file address.
- Government ID for high-risk requests: so when you get a request for erasure or access to sensitive stuff then you need a link to a real government ID (Aadhaar, PAN, Passport) — but make sure you don't ask for more ID than you need.
- Callback verification: For phone-submitted requests, call the registered phone number for verbal confirmation.
Do not over-verify. Requiring excessive proof of identity for simple correction requests can itself be a barrier that violates the spirit of the rights. Match verification level to the sensitivity of the requested action.
Erasure Requests and Legal Retention Obligations
A common operational challenge arises when a Data Principal requests erasure of their data, but the organisation has a legal obligation to retain that data. Common examples in India:
- Income Tax Act records: Financial transaction data may need to be retained for 6–8 years
- PMLA (Prevention of Money Laundering Act): KYC and transaction records for regulated entities — 5 years
- Companies Act 2013: Certain company records indefinitely; others for 8 years
- GST records: 6 years from the due date of the relevant annual return
- Labour law records: Employment records varying by state and type
When an erasure request conflicts with a legal retention obligation:
- Acknowledge the request promptly
- Explain the specific legal basis for retention (cite the statute and section)
- Commit to erasing the data as soon as the legal retention period expires
- During the retention period, restrict processing to the purpose of the legal obligation only — do not use retained data for marketing, analytics, or any other purpose
- Document your decision with the legal basis cited — this is your evidence if the Data Protection Board investigates
Building a DSR Workflow
A Data Subject Request (DSR) workflow is the operational process your organisation uses to receive, verify, process, and respond to Data Principal rights requests. A compliant DSR workflow has seven components:
- Intake mechanism — the public-facing channel people use to submit rights requests: web form, email address (e.g., privacy@yourcompany.com), or maybe an in-app self-service portal.
- Automated acknowledgement — which has to be sent within 24–48 hours, and it needs to include a reference number and some sort of idea of when you'll get back to them with an answer.
- SLA timer — Start the 30-day (or applicable) SLA clock from the moment a verified, complete request is received. Escalation alerts at 15 days, 25 days, and 29 days remaining.
- Identity verification — Verify the requester's identity using methods appropriate to the risk level of the requested action. Do not start the SLA timer until identity is verified.
- Data inventory lookup — you need to trawl through all your systems, CRM, databases, email platforms etc to find any and all personal details you've got stored about the Data Principal.
- Fulfilment and downstream notification — follow through with the request (provide a summary, correct the data, delete it, etc) and send a notification to all the Data Processors who have copies of that info to tell them to do the same.
- Evidence trail — Record every step: intake timestamp, verification method, SLA clock start, data lookup results, fulfilment actions, downstream notifications, and response sent. This evidence trail is your defence in a Data Protection Board investigation.
How Consiva Automates Rights Fulfilment End-to-End
Consiva's Data Principal Rights module provides complete DSR automation for the DPDP Act 2023 rights framework:
- Self-Service Rights Portal: A branded portal where your data principals can submit access, correction, erasure, grievance, and nomination requests. Login-based identity verification is automatic.
- Automatic SLA Timers: each type of request gets its own timer, and if things don't get moved along quick enough, you can set up notifications to your privacy team at configurable intervals (15 days, 25 days, and the day before the deadline for a 30-day request).
- Data Inventory Integration: Consiva hooks up to your CRM, database and cloud storage to find personal data scattered across all your systems, and then it auto-generates the response so you don't have to lift a finger.
- Third-Party Processor Notifications: when you've done the request, be it an erasure or a correction, Consiva automatically sends out notification emails to your configured Data Processors (Google Analytics, Mailchimp, Salesforce, etc) with the info they need to get the same job done.
- Immutable Evidence Trail: every single DSR action is logged with a timestamp, a user ID and what they did, and then you can export that lot in a format the Data Protection Board will love.
- Nomination Registration: a dedicated nomination form lets Data Principals name someone to act for them, connecting the nominee to the account, after which the portal carries out the identity checks.
Consiva's DSR module is available on all plans — view pricing. For enterprise implementations with complex data inventory integrations, contact our compliance team. Ready to start? Try it free — no credit card required.
Frequently Asked Questions
To be honest a Data Principal is just the person whose personal data you're dealing with — defined as such under Section 2(j) of the DPDP Act 2023. In simpler terms — it's your users, customers, employees, or anyone else whose data you're looking after. And if that Data Principal is a kid (under 18), then someone's gotta exercise those rights on their behalf — usually a parent or some other sort of lawful guardian.
Specific timelines will be prescribed in DPDP Rules (not yet finalised as of mid-2025). Based on draft Rules and international practice, 30 days is the working benchmark for standard requests. The "without undue delay" principle applies throughout. Consent withdrawal for cookie tracking must take effect immediately (technically). Organisations should build workflows capable of responding within 30 days as a conservative default until final Rules are published.
The DPDP Act does not explicitly permit fees for responding to rights requests. The default position is that responding to Data Principal rights requests is a compliance obligation that cannot be monetised. This contrasts with GDPR, which allows "reasonable fees" for manifestly unfounded or excessive requests. Under DPDP, demanding fees for rights responses could itself constitute a violation of the Data Principal’s rights.
When someone asks for erasure but there's a law that says you have to keep the data (like the Income Tax Act or the Companies Act), the Data Fiduciary gets to hold onto it for as long as the law says they have to. What happens then: (1) they have to let the person know they've got their request; (2) they explain why the data has to stay around by pointing to the specific law that says so, along with the actual name of the law; (3) they promise to get around to erasing the data as soon as the law says they can; (4) for the time being, the Data Fiduciary is only allowed to look at the data so they can stick to what the law says they have to do — no sneaking in any marketing or analytics work on it; and (5) to keep themselves covered, they have to write down why they're keeping the data, including the law that says they have to — that's their evidence record.
Section 14 of the DPDP Act 2023 grants every Data Principal the right to nominate another individual to exercise their data rights in the event of death or incapacity. This nomination is registered with the Data Fiduciary and activated when the Data Principal's death or incapacity is verified. GDPR has no equivalent right — this is unique to India's DPDP Act. Data Fiduciaries must build nomination registration and succession mechanisms into their DSR workflows.
Automate Data Principal Rights — Start Free
Consiva's DSR module covers all five DPDP rights with SLA timers, identity verification, and immutable evidence trails. No credit card to start.