Handling a Data Principal Rights Request: The DSAR Workflow

A data principal rights request, often called a DSAR, is when an individual asks your business what personal data you hold about them and to access, correct or delete it, and every business covered by the DPDP Act needs a repeatable process to handle these before the law's full obligations take effect.

Key facts at a glance

• Under the DPDP Rules 2025, full substantive obligations including data-principal rights become enforceable on 13 May 2027, with no stated grace period.
• The Consent Manager registration framework under Rule 4 becomes operational earlier, on 13 November 2026.
• The Data Protection Board provisions already took effect immediately under the Rules, meaning the enforcement body already exists.
• Rights typically include access to what data is held, correction of inaccurate data, and erasure once the purpose for holding it has ended.
• Security-safeguard failures can attract penalties of up to Rs 250 crore per instance.
• Identity verification before acting on a request is a reasonable and expected safeguard, not optional courtesy.

What counts as a rights request

A data principal rights request is any communication from an individual, whether an employee, customer, vendor contact or website visitor, asking what personal data a business holds about them, or asking for it to be corrected, updated or deleted. It can arrive through a support email, a website form, a phone call, or even a message to a general company inbox, which is exactly why having a single defined intake channel matters.

Why a workflow, not an ad hoc response, matters

Handling one request informally is manageable. Handling requests at any volume without a process leads to missed deadlines, inconsistent responses, and difficulty proving compliance if the Data Protection Board or a customer later asks how a request was handled. A documented workflow turns a legal obligation into a repeatable operational task.

The core DSAR workflow

A workable request-handling workflow generally has five stages: intake, identity verification, data location, response preparation, and closure with logging.

Data location is usually the hardest part

Most businesses underestimate how many systems hold personal data about a single individual: HR and payroll software, a CRM, an email marketing tool, cloud storage, even spreadsheets on someone's laptop. Before a rights-request workflow can work reliably, it helps to have a rough data map showing where each category of personal data lives, so the "find it" step of a request does not turn into a scavenger hunt each time.

Handling exceptions correctly

Not every deletion request should be honoured immediately. If a business has a separate legal obligation to retain certain data, such as payroll or tax records under other statutes, that obligation can take precedence over an erasure request for that specific data, while other, non-essential data about the same person can still be deleted. Documenting this reasoning in the request log protects the business if the decision is ever questioned.

Building this before the deadline

With full obligations enforceable from 13 May 2027, businesses that wait until close to that date to design a rights-request workflow will be doing it under time pressure, with request volume already flowing in from more privacy-aware customers and employees. Starting with a simple, documented manual process now, and refining it over the coming months, is far less disruptive than building it from scratch at the deadline.

If you are not sure how ready your business is to handle a data principal rights request today, ComplianceCheck's DPDP assessment gives you a clear picture in a few minutes.

Sources

• Ministry of Electronics and Information Technology — meity.gov.in
• Data Protection Board of India (as established under the DPDP Rules)

This guide is general information, not legal advice. Requirements vary by state, sector and headcount - confirm specifics with a compliance professional or the relevant authority.