DPDP Sections7 min read

Section 11, 12, and 15 Explained: Managing Data Principal Access Rights, Erasure, and Vendor Exposure

A definitive guide for General Counsels on Sections 11, 12, and 15 of the DPDP Act and the DPDP Rules, 2025, detailing how the right to access and erasure forces strict vendor mapping, triggers litigation risks, and requires careful contract restructuring.

Written bySanket Sharma· Former Advocate, Supreme Court of India · ComplyDP Co-Founder

Last updated:

The Core Challenge of Data Principal Rights

Sections 11 through 15 of the Digital Personal Data Protection Act, 2023 (DPDP Act) establish a comprehensive framework of rights and duties for Data Principals. For a General Counsel or Chief Privacy Officer, Section 11 represents a significant operational challenge. It grants Data Principals the right to request a comprehensive summary of their processed personal data and the specific processing activities undertaken. More importantly for enterprise risk, Section 11(1)(b) compels Data Fiduciaries to disclose the identities of all third-party Data Processors and other Data Fiduciaries with whom that personal data has been shared. This acts as a statutory discovery mechanism that subjects can utilise at scale. It transforms previously opaque vendor supply chains into immediate litigation and regulatory exposure, demanding meticulous tracking to ensure defensibility during regulator engagement. If a Data Principal submits a request, your organisation must be fully prepared to map the entire lifecycle of their data across your entire technology stack.

Section 11: Statutory Discovery and Vendor Mapping

Consent is the primary basis for processing, except where Section 7 legitimate uses apply. Under Section 11(1) of the Act, a Data Principal can demand a summary of their data processed under either basis. Crucially, the law mandates the disclosure of the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with a 'description of the personal data so shared.' This is not merely a request for a high-level vendor list; it requires a granular data inventory mapping specific data categories to specific third parties. The newly notified DPDP Rules, 2025 further prescribe the exact manner in which these requests must be authenticated, logged, and fulfilled. Your enterprise compliance architecture must natively support these 2025 regulatory specifics to avoid regulatory censure and escalating compliance costs.

Section 12: The Right to Correction and Erasure

Section 11 often serves as the gateway to Section 12, which operationalises the right to correction, completion, updating, and erasure. Once a Data Principal reviews their Section 11 access report, Section 12(1) empowers them to demand rectification of their data for which they previously gave consent (including consent under Section 7). Under Section 12(2), upon receiving such a request, the Data Fiduciary is legally obligated to correct inaccurate or misleading personal data, complete any incomplete data, and update the data comprehensively. Furthermore, Section 12(3) allows the Data Principal to mandate the erasure of their personal data in the manner prescribed by the DPDP Rules, 2025. For legal teams, this means that not only must you locate the data internally and across your vendor ecosystem, but you must also possess the technical capability to permanently purge or amend it across all active databases and third-party systems, ensuring seamless downstream compliance.

Section 15: The Fiduciary's Defensive Shield

While the rights granted under Sections 11 and 12 are expansive, General Counsels must actively leverage Section 15, which imposes strict statutory duties on the Data Principal. Section 15 acts as a critical defensive shield for Data Fiduciaries against malicious or weaponised requests. Section 15(a) requires Data Principals to comply with all applicable laws while exercising their rights. Section 15(b) explicitly prohibits impersonating another person, and Section 15(c) strictly forbids the suppression of material information when providing data for state-issued documents. Crucially for enterprise dispute resolution, Section 15(d) ensures that Data Principals must not register false or frivolous grievances or complaints with a Data Fiduciary or the Board. Finally, Section 15(e) requires that individuals furnish only 'verifiably authentic' information when exercising their right to correction or erasure. Legal teams should operationalise these duties into their intake workflows, retaining the right to reject requests that violate these statutory requirements.

Jurisdiction, Liability, and the Vendor Dynamic

These statutory obligations directly bind your enterprise as the Data Fiduciary. The Act covers digital personal data processed within India, and processing outside India if connected to offering goods or services to Data Principals in India. It is vital to note that under the DPDP Act and the DPDP Rules, 2025, Data Processors are not legally bound to answer these Data Principal rights requests directly. The statutory burden, and the ensuing liability, falls entirely on your legal and compliance teams. If a third-party vendor fails to surface, correct, or erase the data upon your instruction, your organisation bears the regulatory liability. This dynamic makes processor flow-down clauses, strict Service Level Agreements (SLAs), and robust limitation of liability terms absolutely critical in all vendor negotiations moving forward.

How to Comply: A Step-by-Step Architecture

Operationalising compliance for Sections 11, 12, and 15 requires a cross-functional strategy aligning legal, IT, and cybersecurity operations with the DPDP Rules, 2025: 1. Deploy a verifiable intake mechanism to authenticate the Data Principal's identity against existing records. The process owner is the Data Protection Officer, and the evidence artifact is a time-stamped authentication log. This is critical to enforcing Section 15(b) against impersonation. 2. Map all personal data flows to third-party vendors and joint fiduciaries. The process owner is the Legal Head, generating a dynamic data sharing registry directly linked to active vendor contracts to satisfy Section 11(1)(b). 3. Build data rectification and erasure workflows. Ensure database administrators can seamlessly execute Section 12 correction and erasure requests across primary storage and interconnected environments. 4. Enforce strict data retrieval and deletion SLAs in all processor agreements. The process owner is the General Counsel, and the evidence artifact is the executed vendor agreement containing explicit indemnity provisions. 5. Compile, review, and deliver the summary report securely to the verified Data Principal. The process owner is Compliance Operations, retaining a delivery receipt and a redacted copy of the report for privileged review in case of a dispute under Section 15(d).

Penalties for Compliance Failures

Failing to fulfill Section 11 and Section 12 obligations carries severe financial and reputational exposure. The Schedule to the DPDP Act sets a penalty ceiling of up to 50 crore rupees for breaching obligations regarding Data Principal rights. The Data Protection Board of India will meticulously weigh aggravating factors, such as systemic failures to track downstream vendors, a pattern of ignored access requests, or a negligent failure to execute erasure commands. Prolonged non-compliance will exponentially increase your outside counsel spend as you fight escalating regulatory notices. Conversely, Data Principals who violate their Section 15 duties by filing frivolous complaints also face statutory repercussions, reinforcing the importance of maintaining detailed audit logs of all request interactions.

Approaching the Hard Deadline

Exactly 304 days remain until the DPDP hard compliance deadline of 13 May 2027. The window to renegotiate hundreds of legacy vendor contracts and operationalise defensible Data Principal request workflows in accordance with the DPDP Rules, 2025 is closing rapidly. Legal departments must immediately evaluate whether their current legal tech stack can map downstream data sharing, generate a verifiable Section 11 report, and execute Section 12 erasures without requiring manual, error-prone escalation. Run a focused gap assessment on your vendor exposure at freescan.complydp.com today to ensure your compliance posture is audit-ready before the regulatory deadline.

Sources

Frequently asked questions

What is the penalty for failing to provide a Section 11 access report or process a Section 12 erasure?

Under the Schedule to the DPDP Act, 2023, the penalty for breaching obligations regarding Data Principal rights, which encompasses both Section 11 access requests and Section 12 erasure requests, can reach up to 50 crore rupees. The Data Protection Board determines the exact penalty amount based on the severity, scale, and systemic nature of the failure.

Do Data Processors have to answer Section 11 or Section 12 requests directly?

No. The legal obligation to respond to and fulfill a Section 11 access request or a Section 12 erasure request falls entirely on the Data Fiduciary. General Counsels must rely on strong indemnity clauses and strict Service Level Agreements in their vendor contracts to ensure that processors assist in data retrieval and deletion.

Can we reject an access or erasure request if the Data Principal is acting maliciously?

Yes. Section 15 of the Act imposes strict statutory duties on Data Principals, explicitly stating in Section 15(d) that they must not register false or frivolous grievances. If a request is demonstrably false or malicious, the Data Fiduciary can defend its refusal to process the request, and the Data Principal may face regulatory penalties for violating their statutory duties.

Does Section 11 require us to name all third-party vendors?

Yes. Section 11(1)(b) specifically grants the Data Principal the right to obtain the identities of all other Data Fiduciaries and Data Processors with whom their personal data has been shared, along with a description of the personal data so shared.