DPDP Act27 May 2026 7 min read

DPDP Act Right of Access: Responding to Data Requests

How to handle DPDP Act right of access requests under Section 11 — what you must provide, verification steps, timelines, and common implementation challenges.

Key Takeaways

Section 11(a) gives Data Principals the right to obtain a summary of their personal data and the processing activities conducted on it.
Access requests must be responded to within the timeframe the DPDP Rules specify — plan for 30 days as a baseline.
The response must include: categories of data held, the identities of Data Fiduciaries and processors who have received the data, and a summary of processing activities.
You must verify the requester's identity before providing personal data to prevent impersonation.
Build a Data Subject Access Request (DSAR) portal or process before enforcement begins — ad hoc responses at scale are not operationally viable.

In this guide

The Right of Access Under the DPDP Act
What Information Must Be Provided
Verifying Requester Identity
Building a DSAR Response Process
Technical Implementation of Data Portability
When You Can Limit Access
Tracking DSAR Metrics and SLAs

The Right of Access Under the DPDP Act

The right of access allows Data Principals to obtain a summary of the personal data held about them by a Data Fiduciary, along with information about how that data has been processed. Section 11(a) of the DPDP Act 2023 codifies this right, which is fundamental to privacy — individuals cannot exercise other rights (correction, erasure, consent withdrawal) unless they first know what data is held about them.

For Indian consumers who interact with multiple SaaS products, banking apps, e-commerce platforms, and healthcare portals, the right of access is a powerful mechanism for understanding their personal data footprint. For companies, it creates an operational obligation: you must be able to quickly and accurately compile a Data Subject Access Request (DSAR) response that covers all personal data you hold about the requester across all your systems.

The right of access is already familiar to companies that serve European customers (under GDPR) or that have processed US financial data (under CCPA). If you have existing DSAR processes for international markets, extending them to cover DPDP obligations is relatively straightforward. If you have no existing process, now is the time to build one — ad hoc manual compilation of DSAR responses does not scale.

What Information Must Be Provided

Section 11(a) specifies that the Data Principal has the right to obtain from the Data Fiduciary: (i) a summary of personal data being processed and the processing activities undertaken; and (ii) the identities of all other Data Fiduciaries and Data Processors with whom personal data has been shared. The Rules will specify the exact format of the response, but companies should prepare to provide comprehensive information across both dimensions.

For the personal data summary: compile a structured listing of the categories of personal data held (name, contact details, usage data, transaction history, etc.), the purpose for which each category is processed, and the legal basis. You do not necessarily need to provide a raw database dump — a human-readable summary that covers all data categories is the intent. However, if the Data Principal specifically requests their data in a portable format, consider this an implicit request for their actual data.

For the sharing disclosure: you must be able to list every entity to which the Data Principal's personal data has been shared — analytics vendors, email platforms, CRM tools, cloud infrastructure providers, marketing partners. This requires maintaining an up-to-date record of all Data Processors and the categories of data shared with each. Your data purpose register (built for minimisation and purpose limitation compliance) should contain this information.

Verifying Requester Identity

Before providing any personal data in response to an access request, you must verify that the requester is the Data Principal whose data they are requesting, or an authorised representative. Providing personal data to an impersonator is itself a data breach — handing someone else's personal data to an unauthorised third party who submitted a fraudulent DSAR request.

For in-product access requests submitted through an authenticated session, the authentication itself serves as identity verification. A user who is logged in and requests access to their own data has already proved their identity. For requests submitted via email to a privacy mailbox, send a verification link to the registered email address associated with the claimed account before processing.

For requests where the claimed identity cannot be easily verified (e.g., a former user whose account is already deleted), you may request supporting documentation — but be proportionate. Requiring unnecessary documentation creates barriers to exercising rights and may constitute an infringement of the right itself. Use the minimum verification steps needed to have reasonable confidence in the requester's identity.

Building a DSAR Response Process

Establish a dedicated DSAR intake and fulfilment process before you receive your first request. The process should include: (1) intake — a designated channel for receiving requests (email, in-product form, privacy portal); (2) acknowledgement — within 5 business days; (3) identity verification; (4) data compilation — querying all relevant systems for the Data Principal's data; (5) review — checking the compiled response for completeness and for any information that may be withheld; (6) response — sending the compiled summary to the requester in a clear format; (7) logging — recording the request, actions, and outcome.

For companies with multiple data systems (CRM, product database, data warehouse, support platform, marketing automation), the data compilation step is the most time-consuming. Build internal queries or scripts that can be run for a given user identifier and compile data across all systems. This is a one-time engineering investment that dramatically reduces the per-request fulfilment time.

Assign clear ownership: who receives and logs requests, who performs identity verification, who runs the data compilation queries, who reviews the output, and who sends the response. In larger companies, these may be different teams (privacy officer, engineering, legal). In smaller companies, a single person may perform all steps. Document the ownership in your privacy procedures.

Technical Implementation of Data Portability

While the DPDP Act's right of access is primarily a right to a summary, best practice (and likely future Rules requirements) suggest you should offer data portability — the ability for a Data Principal to receive their data in a structured, machine-readable format. This allows users to take their data to another service and reduces lock-in friction, which is increasingly expected by enterprise buyers.

Implement a "Download My Data" feature in your product that exports all personal data held for the authenticated user in a structured format (JSON or CSV are most common). Design the export to cover: profile data, activity history, documents uploaded, preferences, and any other user-generated or user-attributed data. The export should be downloadable immediately or within a short processing period for large accounts.

For B2B SaaS where the Data Principal is an end-user of an enterprise customer's account, implement an export mechanism that the enterprise administrator can trigger on behalf of their users. This allows your enterprise customers to fulfil DSAR obligations to their own employees or customers who use the product through them.

When You Can Limit Access

The right of access is not absolute. The DPDP Act allows the Central Government to specify exemptions through Rules. Based on comparable legislation, exemptions are expected to include: information that could harm national security or law enforcement operations; information that would reveal commercially sensitive trade secrets of a third party; information that would infringe the privacy of another Data Principal (for example, information about a third party embedded in the requester's records); and information subject to legal professional privilege.

You should also withhold information that could facilitate impersonation or fraud — for example, you do not need to include in an access response the internal fraud score you hold on a user, if revealing that score would allow them to game your fraud detection systems. Be careful, however, to distinguish legitimate withholding from using these exemptions as a shield to avoid fulfilling requests.

When you withhold information from an access response, inform the requester that certain information has been withheld and the general reason (without revealing what was withheld). This transparency allows the Data Principal to decide whether to escalate the matter to the Grievance Officer or the Board.

Tracking DSAR Metrics and SLAs

Track key DSAR metrics: number of requests received per month, response time (from receipt to sending the response), percentage of requests fulfilled within the prescribed timeframe, and number of requests refused or partially withheld. These metrics reveal whether your process is adequately resourced and help identify bottlenecks.

Set an internal SLA that is tighter than the legal deadline — if the Rules require 30 days, set an internal target of 21 days. This buffer gives you time to handle complex requests, escalations, or resource constraints without missing the legal deadline. Monitor SLA adherence monthly and escalate to leadership if the team is consistently missing the internal target.

Include DSAR metrics in your quarterly data protection compliance reporting. Significant Data Fiduciaries will need to report compliance metrics as part of their SDF obligations. All companies benefit from treating DSAR performance as a monitored compliance indicator — it demonstrates to customers and the Board that your rights management programme is operational and effective.

Frequently Asked Questions

How long do we have to respond to an access request?

The Act leaves the timeframe to the Rules. Expect the Rules to specify 30 days from receipt of a verified request. Build your process around 30 days as the hard deadline with an internal target of 21 days to allow buffer. Acknowledge receipt within 5 business days even if you cannot complete the response by then.

Do we have to provide all personal data we hold, or just a summary?

Section 11(a) specifies a "summary" of personal data and processing activities. You are not strictly required to provide a raw dump of every database record. However, if the Data Principal requests their full data in a portable format, good practice (and potential future Rules requirements) suggests you should provide it. Build a structured data export capability to handle both requests efficiently.

What if the same person submits multiple access requests in quick succession?

The Rules may allow you to charge a reasonable fee for excessive or manifestly unfounded requests, similar to GDPR. Until the Rules specify this, process requests in good faith. If you believe requests are being used to harass or to extract operational intelligence maliciously, document the pattern and seek legal advice. Do not simply refuse requests because they are inconvenient.

We are a B2B SaaS. Do our enterprise customers' employees have access rights against us directly?

The enterprise customer is the Data Fiduciary; you are the Processor. Data Principals whose data you process on the Fiduciary's behalf would typically direct access requests to the Fiduciary (your client), not to you. However, your contract should require your client to pass requests to you where you hold the data, and you should have technical capability to fulfil them.

Can a user's nominee or legal representative submit an access request on their behalf?

Yes. Section 14 of the DPDP Act provides for nominees — individuals designated by Data Principals to exercise their rights in case of death or incapacity. Access requests from duly authorised nominees or legal representatives (with appropriate documentation) must be processed. Factor nominee requests into your DSAR process design.