Introduction
DPDPA Chapters II and III establish six rights for Data Principals. Each right creates a corresponding technical obligation for the Data Fiduciary. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities. The right to correction and erasure requires workflows that propagate changes across connected systems, not only in the primary data store. The right to grievance redress requires a documented complaint and response process with a timestamped record. The right to nomination requires a mechanism for registering and activating nominated representatives.
Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that has published a privacy notice describing its data principal rights commitment but has no technical mechanism for fulfilling a data access request has not implemented the right. The Data Protection Board of India will assess whether rights are technically exercisable, not whether they are described in a policy document.
This blog covers each of the six DPDPA Data Principal rights, what the Act specifically requires for each, and what technical infrastructure the Data Fiduciary must implement to fulfil them. All clause references are drawn from the DPDPA and Akku’s DPDPA compliance mapping documentation.
Right to Access Information Under Clause 11
Clause 11 gives Data Principals the right to obtain information about the personal data being processed about them and the processing activities being carried out.
What the clause requires
Clause 11(1)(a) gives Data Principals the right to obtain a summary of personal data being processed by the Data Fiduciary and the processing activities being undertaken with respect to that data.
Clause 11(1)(b) gives the right to know 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 shared.
Clause 11(1)(c) gives the right to any other information related to personal data and its processing as may be prescribed by the Rules.
What this requires technically
The right to access requires a self-service portal through which a Data Principal can submit an access request and receive a structured response. At scale, manual fulfilment of access requests is not operationally viable. An organisation processing personal data of millions of customers cannot assign staff to manually compile data summaries for each access request received.
The response to an access request must be structured and complete. It must cover every category of personal data held, every processing purpose for which it is used, and every entity with whom it has been shared. This requires a data mapping that connects personal data categories to processing systems, and a mechanism for querying those systems to compile the response.
The disclosure of Data Processor identities under Clause 11(1)(b) requires that the Data Fiduciary maintain a current record of which processors hold which categories of personal data. This is a data governance obligation with a technical component: the processor record must be queryable at the time an access request is received.
Akku’s CIAM Consent Manager addresses Clauses 11(1)(a), 11(1)(b), and 11(1)(c) through Data Principal rights management workflows. The self-service portal enables access request submission and structured response delivery.
Right to Correction and Erasure Under Clause 12
Clause 12 gives Data Principals the right to correction, completion, updating, and erasure of their personal data.
What the clause requires
Clause 12(2)(a) gives the right to correction and updating of personal data that is inaccurate or incomplete. Clause 12(2)(b) gives the right to completion of personal data that is incomplete. Clause 12(2)(c) gives the right to erasure of personal data that is no longer necessary for the purpose for which it was collected.
Clause 12(3) requires that where the Data Fiduciary has shared personal data with another entity, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action.
What this requires technically
Correction workflows must update personal data across every connected system where it is held. A correction applied only in the CRM but not in the marketing automation platform, the support system, and the billing system is an incomplete correction. The workflow must propagate the change to every downstream system holding the affected personal data.
Erasure workflows face the same multi-system challenge with additional complexity. Erasure must be complete and verifiable. The Data Fiduciary must be able to demonstrate that the personal data has been removed from every system where it was held, not only from the primary database. Where personal data is held in backups, the erasure timeline must account for backup retention cycles.
Clause 12(3)’s notification requirement creates an automated downstream communication obligation. When correction or erasure is completed, every Data Processor or other Data Fiduciary with whom the data was shared must be notified. At scale, this notification must be automated through the data processing infrastructure, not manually coordinated.
Akku’s CIAM Consent Manager addresses Clauses 12(2)(a), 12(2)(b), 12(2)(c), and 12(3) through correction and erasure workflow capabilities. The User Lifecycle Manager addresses Clause 12(3) through automated deprovisioning and data lifecycle workflows that propagate cessation events to connected systems.
Right to Grievance Redress Under Clause 13
Clause 13 gives Data Principals the right to have their grievances addressed by the Data Fiduciary before approaching the Data Protection Board of India.
What the clause requires
Clause 13(1) requires that every Data Fiduciary establish an effective mechanism for redressal of grievances of Data Principals. The mechanism must allow Data Principals to raise complaints about how their personal data is being processed and receive a response within a defined timeframe.
The Data Principal must exhaust the Data Fiduciary’s grievance mechanism before approaching the Data Protection Board. This creates a procedural requirement: the Data Fiduciary must have a functioning grievance process that produces documented responses, so that the Data Protection Board can assess whether the mechanism was effective before accepting a complaint.
What this requires technically
A grievance redress mechanism requires a complaint submission interface accessible to Data Principals through the same channels as the consent management system. Every complaint must be recorded with a unique reference number, submission timestamp, complaint category, and Data Principal identity. The response must be recorded with a resolution timestamp, the action taken, and the outcome communicated to the Data Principal.
The record of complaints received and responses provided is the evidence the Data Protection Board will examine when a Data Principal files a complaint claiming the grievance mechanism was ineffective. Without structured records showing that the complaint was received, investigated, and responded to within the required timeframe, the Data Fiduciary cannot demonstrate that the mechanism operated as required.
Akku’s CIAM Consent Manager addresses Clause 13(1) through grievance submission and response management workflows within the Data Principal rights management infrastructure.
Right to Nominate Under Clause 14
Clause 14 gives Data Principals the right to nominate another individual to exercise their rights in the event of their death or incapacity.
What the clause requires
Clause 14(1) gives every Data Principal the right to nominate any other individual who shall, in the event of the death or incapacity of the Data Principal, exercise the rights of the Data Principal in accordance with the provisions of the Act.
This right is unique to DPDPA among the frameworks covered in this series. It reflects the Act’s recognition that digital identity and personal data persist beyond individual incapacity events, and that Data Principals should be able to designate someone to manage their data rights in those circumstances.
What this requires technically
The nomination right requires a nomination registration mechanism within the consent management portal. A Data Principal must be able to register a nominee by providing the nominee’s identity details and their relationship to the Data Principal. The nomination must be stored as a structured record linked to the Data Principal’s identity.
When the Data Fiduciary receives a rights exercise request from a claimed nominee, the verification process must confirm the nominee’s identity, verify their registration as the Data Principal’s nominee, and verify the incapacity or death event that activates the nomination. The nominee’s rights exercise must be logged with the same audit trail as a direct Data Principal rights exercise.
Akku’s CIAM Consent Manager addresses Clause 14(1) through nominee registration and activation workflows within the Data Principal rights management infrastructure.
Right to Withdraw Consent Under Clause 6(3)
While Clause 6(3) sits within the consent provisions rather than the Data Principal rights chapter, the right to withdraw consent is operationally a Data Principal right and requires the same technical fulfilment infrastructure.
What the clause requires
Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent was given through a single action in a mobile application, withdrawal must be achievable through an equivalent single action in the same application. Clause 6(4) requires that the Data Fiduciary cease processing and, on request, erase the personal data when consent is withdrawn.
What this requires technically
Withdrawal must be a self-service action requiring no interaction with a human agent. The withdrawal interface must be accessible through the same channel as the original consent mechanism. Processing cessation must be automated, triggering notifications to every downstream system processing personal data under the withdrawn consent.
Where the Data Principal also requests erasure under Clause 6(4), the erasure workflow must propagate deletion requests across all connected systems and notify Data Processors under Clause 12(3).
Akku’s CIAM Consent Manager addresses Clauses 6(1), 6(3), 6(4), and 6(7) through consent withdrawal workflows with automated downstream processing cessation notifications. The User Lifecycle Manager addresses Clause 8(7)(a) and 8(7)(b) through deprovisioning workflows triggered by consent withdrawal events.
Right to Data Portability Under DPDPA
The DPDPA does not include an explicit data portability right equivalent to GDPR Article 20. However, Clause 11’s access right implicitly supports portability in practice: a Data Principal who receives a structured summary of their personal data under Clause 11(1)(a) can use that summary to transfer their data to another provider.
Organisations subject to both DPDPA and GDPR must implement data portability infrastructure for GDPR Article 20 purposes regardless. A structured data export capability that produces personal data in a machine-readable format satisfies both GDPR’s explicit portability requirement and DPDPA’s implicit access right infrastructure requirement.
Technical Infrastructure Required Across All Six Rights
Fulfilling all six Data Principal rights requires a common technical infrastructure: a Data Principal identity verification mechanism at the point of rights exercise, a self-service rights submission portal accessible across channels, structured record storage for every rights request and response, automated fulfilment workflows for correction, erasure, and downstream notification, and an audit trail covering every step of every rights fulfilment process.
This infrastructure cannot be bolt-on. It must be integrated with the consent management system so that rights exercises are linked to the Data Principal’s consent record. It must be integrated with the access governance infrastructure so that erasure and deprovisioning workflows operate through the same automated lifecycle management that governs normal access changes.
Akku’s CIAM Consent Manager addresses 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation, covering the consent lifecycle, notice management, Data Principal rights fulfilment, and preference management. The User Lifecycle Manager addresses automated lifecycle events triggered by rights exercises. Together, these modules constitute the technical infrastructure DPDPA Data Principal rights require.
Diagnostic Questions
If a Data Principal submitted a Clause 11 access request today, could your organisation produce a structured summary of every category of personal data held about them, every processing purpose, and every entity with whom their data has been shared, without a manual compilation exercise across multiple system administrators?
When a Data Principal exercises their right to erasure under Clause 12(2)(c), does the erasure propagate automatically to every connected system holding their personal data, and does the Data Fiduciary receive confirmation of completion from each system?
Does your grievance mechanism produce a structured record for every complaint received, with a unique reference number, submission timestamp, and response record, sufficient to demonstrate to the Data Protection Board that the mechanism is operating effectively?
Can a Data Principal withdraw consent through a single self-service action in the same interface where they gave consent, without contacting support, and does withdrawal trigger automated processing cessation across all connected systems?
Has your organisation implemented a nominee registration mechanism, allowing Data Principals to designate someone to exercise their rights in the event of death or incapacity, as Clause 14(1) requires?
CTAs
See how Akku’s CIAM Consent Manager addresses DPDPA Data Principal rights requirements across access, correction, erasure, grievance redress, and nomination.
Book a conversation with the Akku team to assess your current technical infrastructure against DPDPA Data Principal rights obligations.
FAQs
What is the difference between the right to access under Clause 11 and the right to correction under Clause 12?
Clause 11 gives Data Principals the right to obtain information about what personal data is held about them and how it is being processed. It is an information right. The Data Fiduciary must tell the Data Principal what data it holds, for what purposes, and with whom it has been shared. Clause 12 gives the right to change or remove that data. It is an action right. The Data Fiduciary must update inaccurate data, complete incomplete data, or erase data no longer necessary for its original purpose. Both rights require technical fulfilment infrastructure, but the infrastructure requirements are different: Clause 11 requires a data retrieval and summary capability, while Clause 12 requires update and deletion workflows that propagate across connected systems.
What timeframe does DPDPA set for fulfilling Data Principal rights requests?
The DPDPA itself does not specify response timeframes in the current text. Timeframes are expected to be defined in the Rules, which are yet to be finalised. GDPR’s 30-day response standard for Data Subject rights requests is a reference point that many organisations subject to both frameworks are applying as a working standard for DPDPA as well. Organisations should monitor the Rules publication for specific timeframes and design their fulfilment workflows to operate within the expected standard.
Does Clause 12(3)’s downstream notification requirement apply to all third parties or only Data Processors?
Clause 12(3) requires that where the Data Fiduciary has previously shared personal data with another Data Fiduciary or Data Processor, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action. The obligation applies to both other Data Fiduciaries and Data Processors with whom the data was shared. This requires the Data Fiduciary to maintain a current record of every entity to whom each Data Principal’s personal data has been disclosed, which is a data governance obligation with direct technical implications for how data sharing is tracked and recorded.
How does the nomination right under Clause 14 interact with the consent management system?
When a nominated individual exercises a Data Principal’s rights following death or incapacity, they are exercising those rights on behalf of the Data Principal. The rights themselves, access, correction, erasure, grievance redress, are the same rights the Data Principal would exercise directly. The technical requirement is an identity verification layer at the point of nominee activation, confirming both the nominee’s identity and the activation event, followed by access to the same rights fulfilment workflows the Data Principal would use directly. The nominee’s actions must be logged with their identity, the Data Principal’s identity, and the activation basis in the same audit trail as direct Data Principal rights exercises.
What happens technically when a Data Principal withdraws consent and the Data Fiduciary no longer has a lawful basis for processing?
When consent is withdrawn and no other lawful basis under Clause 4 applies, the Data Fiduciary must cease processing the personal data for the purposes covered by the withdrawn consent. Technically, this means deprovisioning access to personal data processing systems for the Data Principal’s data, suppressing the Data Principal’s records from processing workflows, and notifying Data Processors operating under the same consent basis to cease processing. Where the Data Principal also requests erasure under Clause 6(4), deletion workflows must propagate across all connected systems. The automated deprovisioning workflow triggered by consent withdrawal is the technical implementation of this cessation obligation.
Can a single CIAM deployment address both DPDPA Data Principal rights and GDPR Data Subject rights requirements?
Yes. The overlapping infrastructure requirements are substantial. Both DPDPA Clause 11 and GDPR Article 15 require self-service access to personal data summaries. Both DPDPA Clause 12 and GDPR Articles 16 and 17 require correction and erasure workflows that propagate across connected systems. Both DPDPA Clause 6(3) and GDPR Article 7(3) require self-service consent withdrawal with automated processing cessation. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment, with the consent record data model extended to capture the specific fields each framework requires.
