DPDP for Customer Support Leads: Handling Rights Requests at the Front Line
Support teams are often the first to hear 'delete my data' or 'what do you have on me.' Here's how to recognise and route these requests properly.
Rights requests don't always announce themselves
A customer asking to 'close my account and remove my info' or 'send me everything you have on me' is exercising rights under Sections 11 and 12 of the DPDP Act, even if they never use the words 'data protection' or 'DPDP.' Support agents need to recognise these requests in ordinary customer language, not just in a formal legal template.
The risk in a support queue is that such a message gets treated as a routine account-closure or support ticket, actioned partially, and closed — without the structured verification, tracking, and response-within-timeline that a rights request actually requires.
The four requests to watch for
Access requests ('what data do you have on me,' 'send me my information') fall under Section 11 — the customer is entitled to a summary of what's processed and who it's shared with, not necessarily a raw database export.
Correction and erasure requests ('fix my address,' 'delete my account,' 'remove this old order') fall under Section 12. Erasure is subject to the same purpose-served-or-consent-withdrawn test as elsewhere — a customer with an open dispute or outstanding payment may not be immediately eligible for full erasure, and support needs a way to explain that without stonewalling.
Grievances about how a request was handled fall under Section 13, and there's a sequencing rule worth knowing: a Data Principal has to attempt resolution through your own grievance mechanism before they can escalate to the Data Protection Board — which is exactly why a functioning internal process matters.
Verification without becoming a barrier
Confirm identity before acting on a request — releasing account data to whoever emails in claiming to be the account holder is its own security incident. But verification should be proportionate: matching account credentials or a registered contact method is usually enough; don't demand disproportionate identity documentation for a simple access request.
Section 15 places some responsibility on the Data Principal too — providing only verifiably authentic information when asking for correction or erasure. If a customer's correction request itself looks fraudulent (asking to change account ownership details without proof, for instance), support has grounds to ask for more before acting.
Escalation and timelines
Every rights request needs a ticket type, an owner, and a due date distinct from ordinary support SLAs — treating a deletion request like a routine 'close my account' ticket is how timelines get missed. Build a simple tagging convention in your helpdesk so these requests are searchable and reportable.
Give support leads a clear escalation path to legal or the DPO for anything ambiguous — a request tangled up with an active dispute, a request from someone claiming to act for a deceased relative under Section 14, or a request that looks like it's testing your process rather than a genuine ask.
Where to go next
Equip the team with the Rights Navigator to correctly classify incoming requests, and use the Request Handling Toolkit to standardise verification, response templates and internal tracking.