DSAR Automation in 2026: Running Data Principal Rights Requests at Volume

Short answer: Under India's DPDP Act, Data Principals have the right to access a summary of their personal data and processing activities, to correction and completion, to erasure, to grievance redressal, and to nominate someone to exercise their rights. Data Fiduciaries must publish a contact channel, respond within their stated period, and be able to prove the request was handled — which is why manual handling breaks past low volumes.

The Five Rights You Must Service

Right	What the Data Principal can demand	Hard part
Access	A summary of personal data being processed, the processing activities undertaken, and the identities of other fiduciaries and processors with whom data was shared	Finding all of it across systems
Correction & completion	Correction of inaccurate data, completion of incomplete data, and updating	Propagating the fix downstream
Erasure	Deletion, unless retention is required by law	Deleting from every copy, including logs and vendors
Grievance redressal	A readily available means of registering a grievance, with a response	Staffing it and meeting the clock
Nomination	Nominating another individual to exercise rights on death or incapacity	Almost nobody has built this

The access right's third limb is the one that catches Indian companies out. It is not enough to export a user's profile. You must be able to state which other fiduciaries and processors received their data — which requires a processor register that is current, not a contracts folder.

Nomination is the quietly ignored one. It is a genuine statutory right, it requires product surface — a way to record and later act on a nominee — and virtually no Indian implementation has built it. It is also the kind of gap an auditor finds in five minutes.

Why Manual Handling Breaks

The first requests arrive in a shared inbox and someone handles them. That works to roughly ten a month. Then a data breach at another company makes the news, a consumer forum publishes a template, or a disgruntled ex-employee cohort coordinates — and volume moves an order of magnitude in a week.

Key insight: the failure mode is not that you cannot answer requests. It is that you cannot answer them consistently and provably. Two similar requests handled differently by two people, with no record of what was searched or what was sent, is a compliance finding regardless of whether either individual got a good answer.

The Six Stages of an Automated Rights Workflow

1. Intake

A published, readily available channel — a web form beats an email address, because a form captures structured fields and issues a reference number automatically. Requirements: reachable from your privacy notice and footer, available in the languages your users read, accessible to users without an account, and issuing an acknowledgement with a reference the requester can quote.

2. Identity verification without collecting more data

This is the stage that goes wrong most often. You must verify the requester is who they claim to be, otherwise you hand one person's data to another — which is itself a breach. But over-verification is its own violation: demanding an Aadhaar copy from someone who only ever gave you an email address means collecting more personal data than the purpose requires.

The proportionate approach is to verify against what you already hold:

• an OTP to the registered email or phone on file,
• a signed-in session for account holders,
• a magic link to the address of record,
• knowledge of details only the account holder would have, for edge cases.

Never accept a new identifier supplied in the request as proof of identity for data held against a different identifier. That is the standard account-takeover route.

3. Discovery across systems

The request is scoped by identity, not by system. A complete answer requires searching every place personal data lives: primary database, warehouse, CRM, support desk, email platform, analytics, payment processor, and any vendor processing on your behalf. Two prerequisites make this tractable:

• a stable identity key that resolves a person across systems even when they used different emails or phone numbers over time, and
• a system inventory that says which systems to search — the same inventory that drives retention. See our retention and erasure guide.

4. Review and redaction

Not everything found is disclosable. An access response must not reveal other people's personal data — a support ticket thread naming another customer, an internal note about a third party. Nor should it expose trade secrets. Automate the compilation; keep a human review step before release, with the reviewer recorded.

5. Response within the clock

Publish a response period and meet it. The obligation is to respond within the period specified for grievance redressal, so your published SLA becomes the standard you are held to. Practically:

• start the clock at intake, not at first human touch,
• track time-to-response per request with escalation before breach,
• send a holding response if genuinely complex, explaining the delay,
• deliver through a channel that does not itself leak — a secure download beats an email attachment.

6. Evidence

Every request needs a durable record: who asked, when, how identity was verified, what was searched, what was found, what was withheld and why, who reviewed, what was sent, and when. This record is the compliance artefact. A perfectly handled request with no record is indistinguishable from an ignored one.

The Erasure Complication

Erasure requests need three additional decisions the other rights do not.

• Legal retention override. Some data must be kept — tax records, KYC under PMLA, litigation hold. Erase what you can, retain what law requires, and tell the requester precisely which categories were retained and under which obligation. Silence reads as non-compliance.
• Downstream propagation. Processors and third parties who received the data must delete too. Automate the notification rather than relying on someone remembering to email the vendor.
• Suppression, not resurrection. If you delete a person and then re-import them from a backup, a CRM sync, or a marketing list, you have undone the erasure. Keep a hashed suppression list so re-entry is blocked.

Where the Volume Actually Comes From

Rights-request volume in India will not ramp smoothly. It will arrive in spikes, and the triggers are predictable enough to plan for:

• A breach at a well-known company. Coverage of one incident produces requests across an entire sector, from people checking what everyone holds on them.
• A template going around. Consumer forums, subreddits, and WhatsApp groups circulate copy-paste request text. One template can produce hundreds of near-identical requests in a week.
• An employment dispute. A terminated cohort files access requests in parallel, usually with legal advice behind them and a low tolerance for a late response.
• An activist or journalist testing an industry's responsiveness and publishing the comparison.
• A competitor probing your processes — uncomfortable, entirely lawful.

The common feature is that all of them arrive at once, from people who are already unhappy, and often with an audience watching. A workflow that quietly works at ten requests a month and collapses at three hundred fails precisely when failure is most visible.

Measuring the Workflow

Four numbers tell you whether the rights function is healthy. Track them monthly from the day you launch, not from the day you have a problem:

Metric	What it tells you	Warning sign
Median and p95 time to response	Whether your published SLA is real	p95 approaching the SLA while the median looks fine
Identity verification failure rate	Whether verification is proportionate	High failures — you are asking too much, or attackers are probing
Requests requiring manual discovery	Coverage of your system inventory	Rising share means a system is missing from the map
Escalations and grievances after response	Answer quality	Repeat contact from the same requester

The second metric deserves attention beyond compliance. A rising verification failure rate can mean your process is too demanding — but it can also mean someone is systematically attempting to obtain other people's data through your rights channel. Access requests are an underrated social-engineering vector precisely because staff are trained to be helpful and to move fast.

What Good Looks Like at Volume

Capability	Manual	Automated
Identity verification	Ad hoc, inconsistent	OTP or magic link to the address of record, logged
Discovery	Someone remembers which systems	Inventory-driven, identity-key resolved
SLA tracking	Spreadsheet	Clock from intake, automatic escalation
Evidence	Email thread	Immutable per-request audit trail
Erasure propagation	Manual vendor emails	Automated processor notification plus suppression list
Volume ceiling	~10/month	Thousands

Frequently Asked Questions

What rights do Data Principals have under India's DPDP Act?

Five: the right to access a summary of their personal data and the processing activities undertaken, including which other fiduciaries and processors received it; the right to correction, completion, and updating; the right to erasure; the right to grievance redressal; and the right to nominate another individual to exercise these rights in the event of death or incapacity.

How long do companies have to respond to a DSAR in India?

The Act ties the obligation to the period prescribed for grievance redressal, and requires Data Fiduciaries to publish their response commitment. In practice your published SLA becomes the standard you are held to, so publish a period you can actually meet and start the clock at intake rather than at first human review.

How should we verify the identity of someone making a rights request?

Verify against data you already hold — an OTP or magic link to the registered email or phone, or an authenticated session. Do not demand new identity documents such as Aadhaar copies from users who never provided them, since that collects more personal data than the purpose requires. Never treat an identifier supplied in the request itself as proof for data held against a different identifier.

Can we refuse a data erasure request?

Only to the extent a law requires you to retain the data — tax records, KYC obligations under PMLA, sectoral regulator directions, or an active litigation hold. Erase everything not covered, and tell the requester which categories were retained and under which legal obligation.

Do rights requests apply to employees and former employees?

Yes. Employees are Data Principals like anyone else, and the employment relationship does not suspend their rights. Former employees frequently file access requests, which is a good reason to know exactly where HR data lives. See our guide to employee data under the DPDP Act.

What is the nomination right and has anyone implemented it?

It lets a Data Principal nominate another individual to exercise their rights if they die or become incapacitated. It requires product surface to record a nominee and a process to verify and act on the nomination later. Very few Indian implementations have built it, which makes it an easy finding for an auditor.

Where Consently Fits

Consently ships a Privacy Preference Centre built for this exact workflow: OTP-verified identity against the address of record, structured intake with reference numbers, per-request SLA clocks, consent history and processing summary compiled automatically, erasure propagation, and an immutable audit trail per request. Rights requests are answered from the same consent records that prove what the person agreed to in the first place — one system, one evidence trail. See the rights workflow.