Sections 11 to 14 of the DPDP Act grant data principals the rights to access, correct, update, erase, file grievance, withdraw consent, and nominate a representative. Rule 14 of the DPDP Rules 2025 sets out the operational form: the data fiduciary must publish the mechanism, accept requests, verify identity, respond within 7 days for a valid request, and resolve grievances within 90 days. Each right is operationally distinct — access produces a summary, correction touches live records, erasure triggers downstream processor notification, grievance requires escalation, nomination requires proof of identity. For a retail bank with 5–25 million customers, a published rights mechanism generates anywhere from 50 to 5,000 requests a month depending on awareness; every one carries a 7-day clock, every refusal needs a documented lawful basis, every grievance is a 90-day hard limit. The checklist below covers the pre-receipt setup, the per-right execution, and the evidence retention that makes the rights pipeline defensible under audit.
Pre-Receipt Publication and Access Enablement under Rule 14(1)
Rights exercise mechanism prominently published on the data fiduciary's website
Rights exercise mechanism prominently published on the data fiduciary's app — both surfaces required, not either-or
Details of the means by which a data principal may make a request published; method named (form, email address, IVR option, postal address)
At least one channel accessible to data principals who cannot use digital channels; accessibility for persons with disabilities considered
Required identifiers documented per Rule 14(1)(b): the username, email, phone number, customer ID, or other identifier that the data fiduciary requires to identify the requester under its terms of service
Grievance Officer named, with a contact channel separate from the general support channel
Published SLAs visible to the data principal: 7-day response for a valid rights request under Rule 14, 90-day grievance redressal
Rights mechanism page available in English and in every Eighth Schedule language relevant to the customer base
Request Intake and Routing
Intake form structured per request type: which right is being exercised, what data the request concerns, what outcome the requester seeks
Intake captures the identifier specified in the published mechanism; no extra-collection of data beyond the identifier and what is needed to fulfil the request
Routing matrix documented: which right type goes to which internal team (access → data engineering, correction → product, erasure → data engineering plus downstream-processor coordination, grievance → DPO office, nomination → records team)
Routing matrix tested quarterly with sample requests; broken routes corrected
Acknowledgement of receipt sent to the data principal automatically, with case reference, SLA target date, and language-appropriate response
Internal case management identifies the case owner with name and accountability; case ownership transferable on absence without losing the SLA
Escalation path defined for high-sensitivity requests: minister, regulator, ex-employee, deceased account, dispute with the data fiduciary
Volume monitored daily; surge response plan exists for high-volume events (data breach, regulatory action, public incident)
Verification of Requester Identity
Verification method documented per request type and proportionate to the sensitivity of the data being requested
Verification method does not require collection of additional data beyond what is necessary; Rule 14 minimisation respected
Verification can rely on existing relationship indicators: registered email confirmation, registered mobile OTP, in-app authenticated session, customer service authentication
Stronger verification triggered for higher-risk operations: erasure of all data, access to historical transactions, nomination registration
Verification failure logged with the failure reason; data principal informed of the failure and offered remediation routes
Repeated or excessive requests handled per Act provisions; refusal grounded in lawful basis, not in operational convenience
Verification process reviewed for impersonation risk; social-engineering-resistant where the data being requested is high-value
Per-Right Execution
Right to access (Section 11): summary of personal data being processed produced; summary of the processing activities prepared; identity of recipients to whom the data has been disclosed listed
Access response excludes data of other data principals; technical or contractual safeguards used to redact third-party data
Right to correction (Section 12(a)): inaccurate or misleading data corrected in the live record; correction propagated to downstream processors via DPA-defined notification
Right to update (Section 12(b)): completing or updating processed; out-of-date data refreshed where the data fiduciary continues to process it
Right to erasure (Section 12(c)): processed where the lawful basis to retain has ended; erasure executed across primary systems, backups (per institution's documented backup-deletion policy), and downstream processors
Right to grievance redressal (Section 13): acknowledged on receipt, routed to the Grievance Officer, resolved within 90 days under Rule 14(3)
Right to nominate (Section 14): nominee registered with proof of nominee identity and proof of the nominator's authority; nomination effective on death or incapacity of the data principal
Right to withdraw consent (Section 6(4)): processed; downstream processors notified; lawful basis for any continued processing of the same data re-evaluated and documented
Refusal of a request, where lawful, documented with the specific Act provision relied on; refusal communicated in plain language; escalation route to the Grievance Officer offered
Outcomes communicated in the data principal's preferred language where recorded; communication retained as part of the case record
Downstream Processor Coordination
Downstream processor inventory current and reconcilable to vendor DPAs
Each vendor DPA contains notification obligations for correction, erasure, and consent-withdrawal events
Notification mechanism operationally tested per vendor — not assumed from the contract
Notification timeline tracked; vendor compliance with the DPA-defined response time logged
Failure of a downstream processor to act on notification escalated to vendor management and the DPO
Sub-processor onward-notification flow-down tested; sub-processor confirmation of action evidenced
Response, Evidence, and Retention
Response sent within 7 days for a valid request under Rule 14
Response in plain language; no legalese; no defensive boilerplate that obscures the answer
Response in the data principal's preferred language where the preference is recorded; English in addition where the request was bilingual
Refusal includes the specific lawful basis for refusal; references the relevant Act provision
Refusal includes the grievance escalation route in the same communication
Response delivery evidenced (email delivery receipt, in-app notification log, postal receipt)
Full case record retained per Rule 6: request received, identifier provided, verification performed, routing, outcome, response sent, downstream-processor notifications issued, grievance escalations if any
Minimum 1-year retention of the case record; longer where the request resulted in a regulatory complaint or legal action
Quality Assurance and Surveillance
Monthly metrics produced: volume by right type, average response time, 7-day SLA compliance rate, refusal rate with lawful-basis distribution, grievance escalation rate
7-day SLA breach rate monitored; internal target lower than the legal cap; breaches root-caused individually
90-day grievance breach rate must be zero — Rule 14 cap is the legal limit, not an aspiration
Random-sample audit of closed requests performed monthly; sampling covers refused, fulfilled, and grievance-escalated cases
Audit examines: was verification proportionate, was the response complete, was the refusal lawful, was downstream-processor notification triggered, was the case fully evidenced
Audit findings fed back to intake, verification, and per-right execution teams with named accountability for correction
Patterns suggesting systemic issues (high refusal rate on a specific right, recurring vendor non-compliance, surge in a request type) escalated to the DPO and to the board if material
Annual review of the rights pipeline against current Act and Rules; changes in regulator expectation incorporated
DPDP Assurance Platform
Operationalise this checklist on the DPDP Assurance platform — purpose-built for Indian DPOs managing the full DPDP Act lifecycle.
Operationalise this →