DSAR Handling Playbook: How to Manage Data Subject Access Requests Under DPDP Act 2023

Under India's DPDP Act 2023, individuals — called Data Principals — have rights over their personal data. When they exercise those rights, your organisation receives a Data Subject Access Request (DSAR). How you handle it determines both your regulatory exposure and your relationship with the individual.

This playbook gives DPOs, legal teams, and compliance officers a step-by-step process for handling DSARs under DPDP Act 2023 — from the moment a request arrives to the moment a compliant response is sent.

What Is a DSAR Under DPDP Act 2023?

A DSAR is any request from a Data Principal exercising their rights under Sections 11–13 of the DPDP Act 2023. The Act grants five rights that can generate incoming requests:

Five Rights That Generate DSARs

• Right to Access (§11): The individual can request a summary of the personal data you hold about them and how it is being processed.
• Right to Correction (§12): They can request correction of inaccurate or misleading personal data.
• Right to Erasure (§12): They can request deletion of personal data that is no longer necessary for the purpose for which it was collected, subject to legal hold exceptions.
• Right to Grievance Redressal (§13): They can raise a grievance with your designated grievance officer and, if unsatisfied, escalate to the Data Protection Board.
• Right to Nominate (§14): They can nominate another individual to exercise rights on their behalf in case of death or incapacity.

Note: Unlike GDPR, DPDP Act 2023 does not include a right to data portability (structured machine-readable transfer to another controller). Do not commit to providing data in portable format as a legal right — though you may choose to do so as a service.

Step 1: Receipt and Logging

Every DSAR must be logged the moment it is received, regardless of the channel — email, phone, web form, letter, social media, or in-person.

• Assign a unique reference number (e.g. DSAR-2026-001)
• Record: date received, channel, name of requester, type of right invoked (access / correction / erasure / grievance)
• Start the SLA clock from the date of receipt — not from when the DPO reviews it
• Acknowledge receipt to the individual within 2 business days (best practice; DPDP requires response within prescribed timeline)
• Forward to the designated DSAR handler or DPO team immediately

Train all customer-facing staff (relationship managers, customer service, HR) to recognise a DSAR. Requests often arrive informally — "Can I see what data you hold on me?" is a valid access request even without formal paperwork.

Step 2: Identity Verification

Before releasing any personal data, verify the requester is who they claim to be. Identity verification must be proportionate — do not demand excessive documentation that makes the right practically unusable.

• Existing customers: Authenticate via your standard login or verification procedure. Do not request original identity documents for customers already verified through KYC.
• Former customers: Email to the registered email address + one security question or last-4-digits of a known reference number is proportionate.
• Third-party requests: Require a signed authorisation from the Data Principal. Nominees under §14 must provide proof of nomination (will, power of attorney, or notarised declaration).
• Unverifiable identity: If you cannot verify identity after reasonable effort, you may decline the request — but document the reason and inform the requester what additional information is needed.

Do not use verification as a mechanism to delay or avoid responding. Regulators will scrutinise patterns of disproportionate verification demands.

Step 3: Scope the Request

Clarify what the individual is asking for before beginning the search. Many DSARs are broad ("everything you hold about me") or vague ("I want my data deleted"). Scoping protects both parties.

• For access requests: confirm whether they want a summary (what the Act provides) or specific data elements. You are not required to provide every raw database record — a clear, comprehensible summary satisfies §11.
• For erasure requests: identify the specific data or processing they object to. Some data cannot be erased (legal hold, regulatory obligation) — identify these early.
• For correction requests: request the corrected information in writing — what they want changed and to what value.
• For complex requests: you may request one clarification from the individual — but this should be done promptly and should not restart the SLA clock.

Step 4: Search and Compile

Conduct a systematic search across all systems that hold the individual's personal data. Your ROPA is the starting point — it should map where every category of personal data lives.

• Core systems: CRM, core banking/insurance platform, HR system, marketing platform, customer portal
• Secondary systems: email archives, call recording platforms, document management, analytics tools
• Processor systems: cloud providers, outsourced processors — request data from them under the terms of your DPA
• Backups: consider whether backups contain relevant data — you generally do not need to restore backups solely to respond to a DSAR if the data is available elsewhere

Use a search checklist tied to your ROPA to ensure no system is missed. Document which systems were searched and what was found or not found.

Step 5: Review Before Release

Before sending the response, the DPO or a senior compliance reviewer must check:

• Third-party data: Redact personal data of other individuals that may appear in the records (e.g. emails CC'd to colleagues, joint account data belonging to a co-applicant)
• Commercially sensitive information: You may redact information that would reveal business-confidential methods or processes, but cannot use this to avoid responding substantively
• Legal privilege: Legal advice and privileged communications may be withheld
• Law enforcement restriction: If a law enforcement order restricts disclosure, obtain legal advice before responding
• Accuracy: Verify that the data you are providing is current and accurate

Step 6: Draft the Response

The response must be in plain language, structured, and contain:

• Confirmation that you have processed the request
• The requested data or action (access summary, confirmation of correction, confirmation of erasure)
• For partial responses: a clear explanation of what has been withheld and why
• Information on how the individual can raise a grievance if dissatisfied
• The DSAR reference number for their records

When You Can Refuse or Restrict

DPDP Act 2023 does not provide unlimited rights. You may restrict or decline a request where:

• Legal obligation requires retention: You cannot erase data that a law (RBI, SEBI, Income Tax) mandates you to retain — but must erase everything beyond that obligation
• Active legal dispute: Data directly relevant to an ongoing dispute or legal claim may be withheld until resolution
• Identity cannot be verified: Document the refusal and inform the requester what verification is needed
• Third-party rights: Data that would reveal another individual's personal information can be redacted
• Manifestly unfounded or excessive requests: If requests are clearly abusive or repetitive, document the grounds for restriction — this is a narrow exception and must not be used routinely

Every refusal or restriction must be communicated to the individual with the reason and information on escalation to the Data Protection Board under §13.

Response Templates

Standardise your responses to ensure consistency and reduce DPO workload:

• Acknowledgement template: Sent within 2 business days of receipt — confirms the request, provides the reference number, states the expected response date
• Access response template: Summary of data held, organised by category (identity, financial, contact, transaction history)
• Erasure confirmation template: Confirms what was deleted and what was retained (with legal basis for retention)
• Correction confirmation template: Confirms the data element corrected, old value, new value, and date of correction
• Partial response / refusal template: States what was provided, what was withheld, the ground for restriction, and escalation options

SLA Tracking and Escalation

DPDP Act 2023 requires Data Fiduciaries to respond within timelines prescribed in the Rules. Until Rules prescribe specific timelines, best practice — informed by DPDP principles and regulator expectations — is:

• Acknowledgement: Within 2 business days of receipt
• Identity verification: Complete within 5 business days
• Full response: Within 30 calendar days of receipt (or of identity verification, if delayed)
• Complex requests: Where an extension is genuinely required, inform the requester promptly — do not simply miss the deadline

Track all open DSARs in a dedicated register. Flag any approaching the 21-day mark for DPO review. Escalate to Head of Compliance or General Counsel any request where a refusal or legal dispute is likely.

ROPA and Audit Trail Requirements

Every DSAR must leave a documented audit trail:

• Date received, date acknowledged, date responded
• Type of right exercised
• Identity verification method and outcome
• Systems searched
• Data provided, withheld (with ground), or action taken
• DPO review sign-off
• Whether the individual raised a further grievance

Retain DSAR records for a minimum of 3 years. If a Board inquiry follows a DSAR, the Board will expect to see this complete audit trail. A well-maintained DSAR log is one of the strongest demonstrations of accountability under DPDP.