Introduction: Rights Requests Are Coming — Are You Ready?
From the moment the Data Protection Board of India begins accepting complaints, every Indian customer, employee, or app user whose data you process has the legal right to:
- Access what data you hold about them
- Correct or erase their data
- Withdraw consent and have that withdrawal propagated to all systems
- File a grievance if they believe their rights have been violated
- Nominate a person to exercise these rights after their death
This guide explains how to handle each type of rights request correctly, meet your SLA obligations, and build the operational infrastructure to manage rights requests at scale.
The Five Types of Rights Requests
1. Access Request
What the data principal is entitled to:
- A summary of all personal data you process about them
- A list of all Data Fiduciaries and Data Processors with whom their data has been shared
- Any other information as may be prescribed by the DPBI
Response format: Best practice is a structured PDF signed and dated by the DPO or Grievance Officer, with a data inventory table and list of sharing relationships.
2. Correction and Erasure Request
Correction — the data principal may request correction of inaccurate, misleading, or incomplete data: wrong name, email, phone, address, incorrect account details, outdated information.
Erasure — the data principal may request erasure where consent has been withdrawn, the data is no longer necessary for the purpose it was collected, or the purpose has been fulfilled.
3. Grievance
What triggers a grievance: Any dissatisfaction with how the Data Fiduciary has handled the data principal's data — including receiving unsolicited marketing after withdrawing consent, consent being required for access to essential services, a rights request being denied without explanation, or not receiving a response within SLA.
Grievance vs. Rights Request: A grievance is a complaint about how you handled data or a rights request. It is separate from the underlying rights request and has its own 30-day SLA.
4. Nomination
A data principal may designate a nominee to exercise their data rights in the event of their death or incapacity. The nominee steps into the data principal's shoes and can exercise all data rights on their behalf.
Practical requirements: identity verification for both the nominator and nominee, secure storage of the nomination record, and a mechanism for the nominee to invoke the nomination with proof of the principal's death or incapacity.
5. Consent Withdrawal
Consent withdrawal is technically governed by Section 6(4), not Chapter III, but it triggers rights obligations including erasure. Key rules:
- Must be as easy as giving consent
- Takes effect immediately upon withdrawal
- Does not invalidate past processing (prior processing remains lawful)
- Triggers erasure obligations for any data held solely on the basis of the withdrawn consent
- Must be propagated to all downstream processors that received the data under the withdrawn purpose
The Operational Framework — Building a DPR Queue
The Minimum Viable DPR Process
Every organisation needs at minimum:
- A submission channel: An email address (
privacy@yourcompany.com), a web form, or ideally a self-service portal where data principals can submit requests 24/7 - A request register: A tracker that records each request with type, submission date, SLA deadline, current status, and responsible team member
- Identity verification: Before processing high-impact requests (especially erasure), verify the requester is who they claim to be
- A response template library: Written response templates for each request type, reviewed by legal counsel
- An escalation path: Who handles complex requests? Who signs off on complete erasure? Who responds to DPBI escalations?
SLA Management
| Request Type | SLA | Count from |
|---|---|---|
| Access (Section 11) | 90 days | Date of receipt |
| Correction (Section 12) | 90 days | Date of receipt |
| Erasure (Section 12) | 90 days | Date of receipt |
| Grievance (Section 13) | 30 days | Date of grievance registration |
| Nomination (Section 14) | Promptly | Date of receipt |
Identity Verification — Balancing Security and Access
Before fulfilling a rights request — particularly erasure — you must verify that the requester is the data principal they claim to be. This protects against impersonation attacks, social engineering, and data exposure to unauthorised parties.
| Method | Appropriate For | Strength |
|---|---|---|
| Email OTP | Account access, consent toggles, basic access requests | Moderate — assumes email account ownership |
| Mobile OTP | Combined with email for higher confidence | Moderate |
| DigiLocker verification | High-impact requests (erasure, nomination) | High — government ID linked |
| Aadhaar OTP | High-impact requests where Aadhaar is known | High — biometric-grade identity |
The 90-Day Erasure Orchestration — Step by Step
Erasure is the most operationally complex rights request. Here is the complete eight-step process:
Register the request in your DPR queue with a unique reference number (e.g., DPR-2026-00047). Send an acknowledgement to the data principal with the reference number and expected response date. Start the 90-day SLA clock.
Send verification request to the data principal. Await verification completion before proceeding.
Query your data inventory for all records linked to this data principal. Identify all systems holding their data (use your Data Map / source system registry). Check if any data must be retained due to legal obligations (tax records, contract records, regulatory retention requirements). Determine what can be erased vs. what must be retained with a legal hold.
Consider notifying the data principal before erasure: "We will complete erasure of your data from the following systems by [date]. The following data will be retained under legal obligation for [period]." This step builds trust and reduces post-erasure disputes.
Submit erasure instructions to every system identified in Step 3. For API-connected systems: trigger erasure via API call. For manually managed systems: raise tickets with system owners. For Data Processors: send formal erasure instructions per your DPA terms. Track completion from each system with confirmation records.
Confirm erasure completion from every system. Re-check for any missed systems (backups, DR environments, CDN caches). Document completion evidence (system confirmation, API responses, operator confirmations).
Send a completion notice confirming: erasure is complete, all systems from which data was erased, and any data retained under legal obligation with the basis and duration.
The erasure process — from receipt through completion — is logged in the audit trail. This is your evidence in any subsequent DPBI proceeding.
Grievance Handling — The 30-Day Window
Grievances require faster resolution than other rights requests. The 30-day window is tight when factoring in investigation, internal coordination, and response drafting.
Building a Self-Service Portal — The Right Approach
Handling rights requests at scale via email is unsustainable. A self-service data principal portal reduces operational overhead, provides 24/7 access, creates an automatic audit trail, enables SLA tracking, and gives data principals real-time status updates.
| Feature | Requirement |
|---|---|
| OTP-based login | Email / mobile OTP, no password |
| Consent management | Per-purpose toggle; immediate withdrawal; withdrawal confirmation |
| Rights request submission | Guided form for each request type |
| Request tracking | Reference number, status, expected response date |
| Consent receipt download | PDF of consent records with verification details |
| Notice history | Access to current and historical privacy notices |
| Nomination management | Register and manage nominees |
| Language selection | Minimum English + Hindi; ideally all 22 Eighth Schedule languages |
Scale Planning — Rights Request Volume Projections
Industry benchmarks from GDPR-regulated markets suggest the following monthly volumes:
| Company Size | Monthly DPR Volume (Estimate) |
|---|---|
| 100K data principals | 10 – 50 requests/month |
| 1M data principals | 100 – 500 requests/month |
| 10M data principals | 1,000 – 5,000 requests/month |
| 100M+ data principals | 10,000 – 50,000 requests/month |
Common Mistakes to Avoid
privacy@ inbox checked weekly will miss the 30-day deadline. Grievances need immediate registration and SLA tracking.Conclusion: Build the Capability Before You Need It
Rights requests are an operational reality for every organisation that processes personal data under the DPDP Act. The organisations that handle them well — promptly, transparently, and completely — build trust and stay out of DPBI proceedings.
The organisations that handle them poorly — missing deadlines, providing partial responses, failing to orchestrate erasure across all systems — create DPBI complaints and expose themselves to significant penalties.
How Vishwaas AI Supports Rights Management
Vishwaas AI provides a complete Data Principal Rights management system:
- Self-service portal for request submission in 22 languages
- Unique reference numbers and automated acknowledgement
- SLA countdown per request type with admin alerts for approaching deadlines
- Identity verification (email OTP, DigiLocker, Aadhaar)
- Erasure job orchestration across all linked source systems and data processors
- Propagation confirmation from each system before DPR closure
- Immutable activity timeline per request for DPBI audit evidence
- DPBI-ready DPR export — signed PDF of the complete request handling history
About Vishwaas AI
India's DPDP Act compliance platform — complete DPR management with a self-service portal in 22 languages, SLA tracking, cross-system erasure orchestration, and DPBI-ready signed PDF exports for every request.