DPDPA Section 11: Right to Access Information About Personal Data

A user asks what you know about them. In the past, you could ignore the email, reply with a link to a 4,000-word privacy policy, or dump an unreadable database export and consider the matter closed.

Under DPDPA Section 11, that era is over.

The Digital Personal Data Protection Act gives individuals a clear right to know what a Data Fiduciary is doing with their personal data,provided they previously gave consent. Rule 13 under the DPDP Rules 2025 sets the mechanics for how a DPDP Act data access request actually works in practice.

This is not a theoretical right. It requires Data Fiduciaries to produce usable information on demand, on a strict timeline, and in a format a normal person can understand.

Scope and Applicability

Section 11 applies only when the Data Principal has previously given consent to the Data Fiduciary for processing. This includes consent deemed under Section 7(a) in the employment context.

It does not apply to processing conducted under other legitimate uses without consent under Section 7(b) to 7(j). If a Data Fiduciary processes data under those specific grounds, Section 11 access rights are not triggered for that data.

Requests can only be made to the Data Fiduciary to whom consent was given. You cannot invoke Section 11 against a party you never interacted with, or demand answers for processing conducted solely on other lawful bases.

What must be provided under Section 11(1)(a)

You can request a summary of the personal data being processed and the processing activities undertaken with it.

Key point for operators: a summary means a structured, comprehensible overview. It is not a raw data dump.

Dumping technical database fields, server logs, and exhaustive machine outputs does not prove transparency. It defeats the purpose of a summary. You must organize the response by data categories and explain what exists, why it is used, and how it is processed,in plain language.

A compliant response typically covers:

• Identity and account data categories.
• Contact and address data categories.
• Transaction and usage data categories.
• Preference and support interaction data categories.
• High-level retention statements for relevant categories.
• A list of processing activities, each tied to a purpose, the data used, user choices, and retention.

Data sharing disclosure under Section 11(1)(b)

“We share data with trusted third parties” is no longer an acceptable answer.

Under Section 11(1)(b), individuals can request the identities of all other Data Fiduciaries and Data Processors with whom their personal data has been shared, along with a description of what was shared.

For compliance teams, this means maintaining a current, accurate register of all external sharing.

• Internal access by employees is not “sharing.”
• External parties that process data on your instructions are Data Processors.
• Parties that determine their own purposes and means are Data Fiduciaries.

Your disclosure must name each entity and describe, in plain terms, exactly what data was shared and why.

Other prescribed information under Section 11(1)(c) and Rule 13

The Act allows the government to prescribe additional disclosures. Under Rule 13, organizations must be prepared to pull back the curtain on lifecycle management and risk incidents.

Be ready to include:

• Retention periods by data category.
• Cross-border transfer details, including destination countries where applicable.
• Whether automated decision-making affects the Data Principal.
• Contact details for the Data Protection Officer (where applicable) and the Grievance Officer.
• Whether the Data Principal’s data was involved in any personal data breaches, with relevant details.

These items go beyond a basic summary. They force operational transparency.

Law enforcement exception under Section 11(2)

There is a boundary to disclosure. A Data Fiduciary does not have to disclose under 11(1)(b) and 11(1)(c) that it shared personal data with another legally authorized Data Fiduciary, provided the sharing was based on a written request for the prevention, detection, investigation, prosecution, or punishment of offences or cyber incidents.

Boundaries to observe:

• The exception applies only to 11(1)(b) and 11(1)(c). It does not remove the obligation to provide the 11(1)(a) summary of data and processing activities.
• The request must be in writing, and the recipient must be legally authorized to obtain the data.
• Routine regulatory or tax reviews that are not for investigation or prosecution typically do not qualify.

Use this exception narrowly. Document the legal basis and the written request internally.

Request process and timelines under Rule 13

To operationalize data principal rights, DPDP Rule 13 sets a disciplined flow:

• Identity verification: The Data Fiduciary must ensure the requester is the actual Data Principal or a legally authorized representative. Acceptable methods include account authentication, OTP to a registered contact, or other reasonable checks.
• Submission channels: Provide at least one simple channel,such as a web form, email address, or postal address,including the Grievance Officer’s contact.
• Acknowledgment: Within 7 days of receipt.
• Response: Within 30 days. This is extendable by another 30 days with justification if the request is complex. Sixty days is the absolute outer limit.
• Format and clarity: Use commonly used formats. Write in plain language. Structure the response so it can be understood without technical expertise.
• Fees: The first request within a 12-month period is free. Reasonable cost-recovery fees may apply for additional requests in the same period.

Failure to meet these obligations is not a minor administrative error. The input indicates penalties up to ₹200 crore for non-compliance with access rights.

What changes in practice for operators

If you process personal data on the basis of consent or Section 7(a), you need to be able to answer three questions on demand:

1. What data about this person do we have and what do we do with it?
2. Who outside our organization received it and exactly what was shared?
3. What additional items do the Rules require, such as retention and transfers?

To do this, you have to build actual capabilities, not just write a policy:

• Data inventory and mapping by category and system.
• A processing activity register that ties purpose to data elements and retention.
• A third-party sharing log that distinguishes Data Processors and Data Fiduciaries, with data elements and purposes.
• An identity verification workflow that is secure yet not obstructive.
• Standard response templates that present summaries in simple language.
• Timelines, reminders, and escalation paths to meet the 7-day acknowledgment and 30 to 60-day response windows.
• A mechanism to flag and handle law enforcement requests under the Section 11(2) exception, including written-request validation and internal documentation.

Common pitfalls to avoid

• Ignoring scope: Responding with “not applicable” when processing is based on consent or Section 7(a).
• Raw data dumps: Sending technical exports without explanation instead of a usable summary.
• Incomplete third-party lists: Omitting processors, affiliates, or niche vendors used by specific teams.
• Over-collection during verification: Demanding unnecessary documents that increase risk and create friction.
• Hidden channels: Burying the request mechanism or making it hard to use.
• Fee misuse: Charging for the first request in a 12-month period or setting excessive fees thereafter.
• Missing deadlines: Failing to acknowledge within 7 days or to respond within 30 days without a valid extension.
• Misusing the law enforcement exception: Applying it to routine regulatory or civil matters, or using it to avoid disclosing general processing activities.

A practical closing note

Section 11 is straightforward on paper. The operational lift sits in your data inventory, your third-party governance, and your ability to generate a clear, accurate, and timely summary that will stand up in a dispute. Teams that prepare templates, registers, and workflows now will avoid the scramble, the gaps, and the potential penalties later.

Ready to simplify compliance?

If you need a structured way to centralize your registers, run the process on time, and evidence every decision, Regodit can help you put this on rails. Explore how Regodit can operationalize Section 11 requests with clear registers, templates, and workflows. If you want to see how this works against your current stack, schedule a short discussion with our team.