The DPDP Act, 2023 is not just about what organisations cannot do with personal data. It is equally about what individuals can demand. The Act enshrines 8 rights for Data Principals — and the obligation falls squarely on Data Fiduciaries to honour them. If your product collects, stores, or processes personal data of Indian users, these rights are not optional features on your product roadmap. They are legal requirements.
Right 1 — Right to Access Information About Processing (Section 11)
A Data Principal has the right to obtain a summary of what personal data the Fiduciary holds about them, the processing activities carried out, and the identities of all Data Processors and other Fiduciaries with whom their data has been shared.
What your product must do
- Provide an authenticated, self-service "My Data" dashboard or portal
- Generate a structured summary of data categories collected and how they are used
- List third-party processors and integrations that have accessed the user data
- Respond to access requests within a reasonable timeframe (Rules will specify exact timelines)
This right drives the need for a robust data inventory underneath your product. Without knowing what you hold, you cannot tell users what you hold. Build your data mapping before you build your Data Subject Access Request workflow.
Right 2 — Right to Correction and Erasure (Section 12)
A Data Principal can request correction of inaccurate or misleading personal data, completion of incomplete data, and erasure of personal data that is no longer necessary for the purpose it was collected.
What your product must do
- Build correction workflows — either self-service or request-based with documented review and update process
- Implement erasure workflows that delete or anonymise data from primary databases and cascade deletion to backup systems
- Generate audit logs confirming erasure actions
- Maintain records of all correction and erasure requests and their resolution
Erasure can be declined or deferred when retention is required by applicable law — GST records, RBI mandates, SEBI requirements. Your product must document and communicate this to the user clearly at the point of rejection.
Right 3 — Right to Grievance Redressal (Section 13)
Every Data Principal has the right to have their grievances related to personal data processing addressed. If unsatisfied with the Fiduciary response, they can escalate to the Data Protection Board of India (DPBI).
What your product must do
- Designate and publish a Grievance Officer — name, contact details, and response timelines must be publicly accessible in your privacy notice
- Maintain a grievance ticketing system that acknowledges receipt, provides status updates, and resolves within Rules-defined timelines
- Keep records of all grievances and resolutions for potential Board audits
Avoid routing data-related complaints through a generic customer support queue — they need a dedicated, documented track that can be presented during a Board inquiry.
Right 4 — Right to Nominate (Section 14)
A Data Principal can nominate another individual to exercise their data rights in the event of their death or incapacity. This is a uniquely thoughtful provision — and a compliance requirement that most product teams overlook entirely during initial DPDP planning.
What your product must do
- Provide a nomination mechanism in user account settings
- Allow users to specify a nominee identity (name, contact, relationship)
- Design verification workflows to authenticate nominees when they invoke rights on behalf of a deceased or incapacitated user
Right 5 — Right to Withdraw Consent (Section 6)
Where processing is based on consent, the Data Principal has the right to withdraw that consent at any time. Withdrawal must be as easy as giving consent — this is the "as easy as giving" test.
What your product must do
- Provide a one-click or equivalent consent withdrawal mechanism in account or privacy settings
- Stop processing the relevant data upon withdrawal (subject to legitimate retention obligations)
- Trigger downstream notifications to processors and third-party integrators
- Not penalise the user for withdrawal by blocking access to unrelated features
If consent was given via a single toggle at signup, withdrawing it cannot require a 5-step email process. Your UX must pass this test. Audit your withdrawal flow against your consent capture flow before your next compliance review.
Right 6 — Right Against Automated Decision-Making (Implicit)
While the DPDP Act does not name this right as prominently as GDPR Article 22, Section 6(1) and related provisions implicitly support a Data Principal ability to contest decisions that materially affect them — particularly where automated profiling or scoring is involved.
What your product must do
- If your product uses automated decision-making (credit scoring, insurance risk, job screening), implement human review pathways
- Disclose automated decision logic in your privacy notice in plain language
- Provide Data Principals a mechanism to contest automated outcomes
Right 7 — Right to Data Portability (Anticipated via Rules)
While not explicitly codified at GDPR Article 20 level, the framework anticipates portability rights — particularly for Significant Data Fiduciaries. Data Principals may be granted the right to receive their data in a structured, machine-readable format.
What your product must do proactively
- Design data export functionality allowing users to download their data in JSON, CSV, or XML format
- Ensure exported data is complete, structured, and human-readable
- Prepare APIs or export mechanisms for data transfer to third-party platforms
Right 8 — Right to Information About Breach (Section 8(6))
If a personal data breach occurs and is likely to affect a Data Principal, the Data Fiduciary must notify the affected individual — in addition to notifying the Data Protection Board.
What your product must do
- Maintain a breach detection and response workflow that identifies affected Data Principals
- Draft breach notification templates in clear, plain language — free of technical jargon
- Include in every notification: nature of the breach, data affected, likely impact, remediation steps taken, and Grievance Officer contact
- Deliver notifications as soon as practicable after a breach is confirmed
- Log all notifications sent for Board audit purposes
Quick Reference — All 8 Rights Mapped to Product Features
| # | Right | Trigger | Product Feature Required |
|---|---|---|---|
| 1 | Access | User request | My Data dashboard, data summary |
| 2 | Correction & Erasure | User request | Edit/delete workflows, cascade deletion |
| 3 | Grievance Redressal | Complaint | Grievance Officer, ticketing system |
| 4 | Nomination | User-initiated | Nominee settings, validation workflow |
| 5 | Withdraw Consent | User-initiated | Consent management UI, one-click withdrawal |
| 6 | Automated Decisions | User-initiated | Human review pathway, explainability |
| 7 | Portability | User request | Data export (JSON/CSV/XML) |
| 8 | Breach Notification | Fiduciary-triggered | Incident response, notification pipeline |
Rights under the DPDP Act are not a PR story for your privacy page. They are functional requirements. If a user cannot exercise them with minimal friction, you are non-compliant — regardless of what your privacy policy says. For the full picture on how consent works under the DPDP Act, read Part 3 of this series.
Frequently Asked Questions
The 8 rights are: (1) Right to Access information about processing, (2) Right to Correction and Erasure, (3) Right to Grievance Redressal, (4) Right to Nominate, (5) Right to Withdraw Consent, (6) Right against Automated Decision-Making, (7) Right to Data Portability, and (8) Right to Information About Breach.
The Data Protection Board can impose penalties of up to ₹250 crore per instance of failure to implement adequate security safeguards. Each unaddressed right is a potential grievance to the Board, and the exposure compounds across multiple rights.
Not at the level of detail seen in GDPR Article 20. The framework anticipates portability rights, particularly for Significant Data Fiduciaries, but the specific requirements will be detailed in the Rules notified by MeitY. Building export functionality proactively positions you ahead of these requirements.
The Act specifies that requests must be responded to within a reasonable timeframe. Exact timelines will be specified in the Rules. In the interim, best practice is to acknowledge within 48-72 hours and resolve within 30 days — consistent with comparable international standards.
Yes, in specific circumstances. Erasure can be declined or deferred when retention is required by applicable law — for example, GST records (7 years), RBI-mandated KYC records, or SEBI-mandated transaction logs. The refusal must be communicated to the user clearly, with the legal basis for continued retention documented.