DPDPA gives every Indian citizen seven rights over their personal data — here is what each right requires operationally, the timelines that apply, and how to build a rights fulfilment system that scales.
The 7 Rights DPDPA Gives Every Indian Citizen
Chapter III of the Digital Personal Data Protection Act 2023 (Sections 11–14) establishes the rights of Data Principals — individuals whose personal data is being processed. These rights are not aspirational principles; they create legally enforceable obligations on Data Fiduciaries, with response timelines, content requirements, and penalty exposure for non-compliance.
The seven rights under DPDPA are:
- Right to access information about personal data being processed
- Right to correction, completion, and updating of personal data
- Right to erasure of personal data
- Right to withdraw consent to processing
- Right to grievance redressal
- Right to nominate another person to exercise rights (in case of death or incapacity)
- Right to approach the Data Protection Board where grievance redressal by the Fiduciary is inadequate
Unlike GDPR's eight rights (which include data portability), DPDPA does not include a right to data portability. But it adds two rights with no GDPR equivalent — nomination and a standalone grievance redressal right with a mandatory response timeline. These additions require workflows that GDPR-era compliance programmes never had to build.
Right to Access: What You Must Provide and in What Form
Under Section 11 of DPDPA, a Data Principal has the right to obtain a summary of the personal data being processed by the Data Fiduciary, information about the processing activities carried out on their data, and a list of any other Data Fiduciaries or Data Processors with whom the data has been shared.
What this means operationally:
- You must be able to retrieve all personal data associated with a given individual from all your systems — databases, CRMs, analytics platforms, cloud storage, backups
- The response must include not just the raw data but a comprehensible summary of what is being processed and for what purpose
- The third-party sharing disclosure requires an up-to-date processor and data-sharing registry, not just a generic statement that "data may be shared with partners"
The Act does not specify a response time for access requests, but the grievance redressal right creates an implicit 30-day outer limit — if a Data Principal raises a grievance about an unanswered access request, the clock starts ticking from that point. Best practice is to treat access requests as having a 30-day response SLA from the date of the request.
Rights to Correction and Erasure: Handling Requests Without Breaking Downstream Systems
Section 12 gives Data Principals the right to request correction, completion, updating, and erasure of their personal data. The correction right applies to inaccurate or misleading data; the erasure right applies to data that is no longer necessary for the purpose for which it was collected.
The operational complexity here is downstream propagation. If a Data Principal's name was processed by your system and shared with three downstream vendors or processors, correcting the name in your primary database does not satisfy the correction obligation if the incorrect data persists in downstream systems. The correction must be propagated.
Similarly for erasure: deleting from your primary database while the data persists in analytics systems, backup tapes, or third-party processors' databases does not constitute erasure. You need a complete picture of where each Data Principal's data lives and a mechanism to propagate deletion requests to all those locations.
The critical exception: erasure does not apply to data that the Data Fiduciary is required to retain under any other law — tax records, KYC records, medical records under applicable regulations. Documenting the legal retention basis for each data category is a prerequisite for handling erasure requests correctly.
Right to Grievance Redressal: The 30-Day Clock and What It Requires
Section 13 of DPDPA gives every Data Principal the right to a grievance mechanism. Every Data Fiduciary must establish a procedure for receiving and resolving grievances, and must respond to any grievance within 30 days of receipt.
This is one of the sharpest operational differences from GDPR, which has no equivalent mandatory response timeline embedded in the regulation itself. Under DPDPA, a Data Principal who raises a grievance and receives no response within 30 days can escalate directly to the Data Protection Board — creating an enforcement pathway that doesn't require the Fiduciary to be egregiously non-compliant, just slow.
What a compliant grievance mechanism requires:
- A published grievance channel — an email address, a web form, or a phone number that is easy to find
- Acknowledgement of receipt, ideally immediate or within 24 hours
- A tracked response workflow with the 30-day deadline visible
- An audit trail showing the date of receipt, the response provided, and the date of response
- A documented escalation path to the DPO (or the responsible officer) for complaints that require senior review
Right to Nominate: India's Unique Posthumous Data Right
Section 14 of DPDPA introduces a right with no equivalent in GDPR, CCPA, or most global privacy regulations: the right to nominate another individual to exercise data rights on behalf of the Data Principal in the event of death or incapacity.
This right reflects a specific Indian legislative context — the same Act that created digital data rights also recognised that data outlives individuals, and that families or representatives should be able to act on deceased or incapacitated persons' data.
Operationally, this requires:
- A nomination capture mechanism — allowing users to designate a nominee with appropriate identity verification
- A nomination registry that links nominators to nominees in a retrievable format
- A process for verifying a nominee's claim when they present to exercise rights (typically requires a death certificate or medical certificate of incapacity)
- A rights fulfilment flow that the nominee can complete on behalf of the original Data Principal
Most GDPR-era compliance programmes have no equivalent system. This is a net-new workflow that needs to be built, not ported.
Right to Withdraw Consent: The Technical and Legal Implications
DPDPA's withdrawal right is straightforward in principle — a Data Principal must be able to withdraw consent as easily as they gave it — but complex in implementation. Withdrawal is not just a record in your consent management system. It triggers a cascade of downstream actions.
When consent is withdrawn:
- Processing of personal data for the withdrawn purpose must cease
- Data Processors who were processing on the basis of that consent must be notified and must also cease processing
- Sub-processors downstream of your processors must receive the withdrawal notification
- The withdrawal must be logged with timestamp, mechanism, and the specific purposes withdrawn
The propagation requirement is the hardest part. A withdrawal recorded in your consent system but not propagated to your analytics vendor, your CRM tool, your data warehouse, or your advertising platform does not satisfy the Act. You need API-level integration between your consent management system and every downstream processor that acted on that consent.
Building a Rights Fulfilment System That Actually Scales
For a small Data Fiduciary processing data for a few hundred individuals, rights requests can be handled manually. For any organisation operating at scale — millions of users, data spread across dozens of systems, a multi-vendor processing chain — manual rights fulfilment is not operationally viable and creates the exact audit trail gaps that the Data Protection Board will scrutinise.
Consentica by OpenBlockAI provides purpose-linked consent records that make rights fulfilment lookups fast — every consent is indexed by Data Principal identity, purpose, and timestamp, so access requests return complete records rather than requiring a manual data archaeology exercise. Correction and erasure requests trigger propagation workflows to downstream processors. The 30-day grievance SLA is tracked automatically against each incoming request. Withdrawal propagation happens via webhook to connected processors in real time, with delivery confirmation logged to the audit trail.
Rights fulfilment is not a checkbox — it is an ongoing operational commitment. The Data Principals who will exercise these rights will do so at unpredictable times and in unpredictable volumes. The infrastructure needs to handle it without requiring manual intervention at each step.