DSAR Process Under DPDP: From Request to Resolution Without the Email Chaos

Who this is for: compliance and privacy operations teams, DPOs and the engineering leads who build the systems behind rights requests.

A customer submits a request through your privacy page. From their side, the job is done: they have asked you to do something. Inside your organisation, the work has only begun.

The request may need identity verification. It needs to be classified. It may need to reach a CRM owner, a product team, a support platform and two or three vendors. Someone has to decide what data is relevant, whether an exception applies, and what to send back. Every one of those steps leaves, or should leave, evidence.

The customer sees one request. Your organisation sees ten systems. This guide sets out how to turn that complexity into a repeatable process under the DPDP Act. For what each right means legally, see Data Principal Rights Under DPDP.

What counts as a request

"DSAR" is the global industry term. Under the DPDP Act, it covers any request by a Data Principal to exercise their rights:

Treat consent withdrawal as part of the same intake. Customers don't distinguish between "withdraw consent" and "delete my data", and your process shouldn't make them.

The intake form is not the workflow

Rule 14 requires you to publish how individuals can make requests and which identifier they need to provide. A good intake form captures the request type, the identifier, the channel and a timestamp, and nothing more than it needs.

But capturing a request is the easy part. The common failure is what happens next: an email thread that becomes the only record of a privacy request, forwarded between teams until someone forgets it. Move every request into a defined state machine instead.

A request state machine

Every request moves through explicit states, and every transition is logged:

The states will vary between organisations. The principle does not: no request should exist only in someone's inbox.

Step 1: Classify

Identify the right being exercised, the systems likely to be involved and the deadline. Grievances have a 90-day outer limit. For other requests, set an internal target well inside that. Most mature programmes aim for 30 days or less, because unanswered requests turn into grievances, and grievances can be escalated to the Data Protection Board.

Step 2: Verify identity without over-collecting

You must not disclose or delete someone's data on the strength of an unverified request. But collecting a passport scan to verify a marketing-email request creates more risk than it removes. Match verification to the risk:

• Low risk (withdraw marketing consent, update preferences): logged-in session or OTP to the registered mobile number or email
• Medium risk (access summary, correction): account login plus OTP, or matching several details you already hold
• High risk (erasure of an account, nominee requests): stronger checks, such as additional matching or documentary proof of the nominee's authority

Section 15 helps here: Data Principals must not impersonate others or provide false information, with penalties for those who do.

Step 3: Locate the data

This is where most programmes stall. Use your Record of Processing Activities to list every system and processor that may hold the individual's data, then search each one by the identifiers you hold. For access requests under Section 11, you also need the list of other fiduciaries and processors that received the data, which only a maintained data-flow map can give you.

Automate discovery for core systems where you can. For the rest, assign each system an owner with a deadline, and track their responses in the request record.

Step 4: Decide, and document exceptions

Before acting, check the limits:

• Scope: Sections 11 and 12 apply to data processed on consent or voluntarily provided. Data processed under other legitimate uses may fall outside them.
• Legal retention: erasure gives way to retention required by law (Sections 8(7) and 12(3)), such as tax, KYC or medical records rules.
• Investigations: the Section 11 sharing disclosure does not extend to lawful sharing with agencies investigating offences.
• Third-party data: don't disclose other people's personal data in an access response.

Record each decision and the reason for it. "Retained under [law] until [date]" is evidence. "Retained" is not.

Step 5: Act and respond

Carry out corrections and erasure in every system and at every processor, not just the customer-facing app. Then respond in plain language: what you did, what you could not do and why, when retained data will be erased, and how to raise a grievance or complain to the Data Protection Board if they are unhappy.

Step 6: Close with evidence

A closed request should contain the original request, verification steps, systems and processors searched, actions taken, exception decisions with reasons, the response sent and timestamps for each state. That record is what you will rely on if the request becomes a grievance or a Board complaint.

Grievances

Section 13 requires a readily available grievance mechanism, and Rule 14 sets a 90-day outer limit for response. Individuals must exhaust this route before approaching the Board. Run grievances through the same state machine, tagged separately, so you can report on them and show the timelines were met.

Metrics worth tracking

• requests received, by type and channel
• median and 95th-percentile time to close
• requests breaching internal targets
• verification failures
• erasure requests partly refused under legal holds
• grievances raised and escalated to the Board

Common mistakes

• Email as the workflow. Requests get lost, and there is no evidence trail.
• Deleting the front end only. Data remains in the warehouse, CRM and vendor systems.
• Over-verifying. Asking for ID documents for low-risk requests deters legitimate users and creates new data.
• Silent refusals. Refusing without explaining the legal basis creates grievances.
• No vendor step. Processors hold your customers' data too.

How ConsentifyAI helps

ConsentifyAI's DSAR module gives you one published intake for every DPDP right and consent withdrawal, with risk-based identity verification. Requests move through a configurable state machine. Data discovery is driven by your ROPA, so each request is routed to the right system owners and vendors. Legal-hold checks run before erasure, deadlines are tracked against your targets, and every transition is written to a tamper-evident audit trail.