How to respond to a data access request under DPDP
When an individual asks what data you hold about them, you have a legal obligation to respond. Here is how to handle it correctly under the DPDP Act.
What information must you provide in response to a data access request?
You must provide: a summary of the personal data being processed (not necessarily every single data point, but a meaningful summary of what categories of data you hold); the purposes for which the data is processed; the identities of any Data Processors who process the data on your behalf; other Data Fiduciaries with whom the data has been shared; and any other information prescribed by the government. You do not necessarily need to provide a raw database dump — a structured, readable summary of what categories of data you hold and how they are processed satisfies the legal requirement.
How do you receive and verify a data access request?
Build a dedicated data request mechanism: a web form, email address, or in-app portal where data principals can submit requests. At intake: verify the identity of the requestor to ensure you are responding to the correct individual and not disclosing another person's data. For customers, verification can be through their existing login credentials or a one-time verification code to their registered email/phone. For employees, verify through HR. Do not ask for excessive identity verification documents — a reasonably proportionate verification is sufficient.
What is the response timeline under DPDP?
The Act requires response 'within such period as may be prescribed' — expected to be 30 days from receipt of the request in the Rules. Start the clock from the date you receive a valid request (after identity verification). If the request is complex or requires coordination across multiple systems, communicate proactively with the requestor about the timeline. A partial response with a commitment to provide the remainder is better than silence. If you need more information to fulfil the request, ask promptly — but the time for clarification should not extend the response deadline unfairly.
How do you locate all personal data about an individual across your systems?
This is the operational challenge of data access requests at scale. You need to search: your CRM (customer interaction history); billing and payment systems; HRMS (for employee requests); email archives (if the individual was a customer contact); marketing database; analytics systems; helpdesk/support tickets; and any file storage where the individual's data may be stored. If you have a data inventory, use it to identify all systems that hold data about the individual's category (customer, employee, vendor). Without a data inventory, locating data across systems is slow and error-prone.
Can you refuse a data access request?
You can decline a request that is manifestly unfounded (clearly not a genuine rights request) or if fulfilling it would adversely affect the rights of another individual (for example, if the requested data contains third-party personal data that cannot be separated). You cannot decline because the request is inconvenient, because you believe the requestor has no legitimate reason to ask, or because your systems do not support easy data retrieval. If you decline, you must inform the requestor of the refusal and the reason, and they have the right to complain to the Data Protection Board.
How do you handle data access requests from employees?
Employee data access requests are typically the most complex: employees may request access to performance reviews, disciplinary records, payroll history, and HR communications. This data may also contain third-party information (the feedback of specific colleagues in a 360 review). You must provide the employee's data while protecting third-party personal data (redact names of colleagues who gave feedback, for example). Build an HR-specific data access response process separate from your customer request process — the data types and sensitivities are different.
Frequently asked questions
What happens if the individual is not satisfied with our response?
If the individual is not satisfied with your response to a data access request — whether because you failed to respond, the response was incomplete, or you wrongly refused — they have the right to file a complaint with the Data Protection Board. The Board can investigate, order you to comply, and impose penalties for failure to honour data rights. This is not a theoretical risk: regulators globally use access request failures as entry points for broader investigations into a company's data practices.
Do we need to provide data access in a specific format?
The Act and draft Rules do not specify a mandatory format for data access responses. Best practice: provide a structured, readable document or downloadable file (PDF or JSON) that clearly organises the data by category — not a database dump in a technical format that the individual cannot interpret. For consumers making requests via a mobile app, an in-app 'download your data' feature (similar to GDPR's data portability tools on Apple, Google, Facebook) is the ideal user experience.
How do we handle data access requests for deceased individuals?
The DPDP Act is silent on deceased individuals' data rights. If a family member or legal representative requests access to a deceased individual's data, handle it cautiously: verify their legal authority (probate, succession certificate, legal heir certificate); consider whether disclosure is appropriate given the sensitivity of the data and any likely objection from the deceased; and take legal advice for complex situations. In the absence of specific DPDP guidance, apply judgment and document your reasoning.
Build your DPDP data access request workflow
Niti Bharat's Data Principal Rights Portal guidance covers DSAR intake, verification, data search, response assembly, and Board complaint handling — everything you need to honour data rights at scale.
Design Your Rights Portal