Data Principal under DPDP Act: Meaning, Rights and Duties

Picture a product review in late 2026: the privacy team wants one channel for access and erasure requests, engineering needs to know which records can actually be deleted, and operations is debating whether every complaint must be closed within seventy-two hours. Institutional parts of the Digital Personal Data Protection Act, 2023 are already in force, but the core Data Principal rights and duties in Sections 11 to 17 have a later commencement date. Treating the framework as either fully operational or wholly deferred leads to the wrong implementation plan.

The Data Principal is the legal role around which these workflows are built. Correct classification determines who may exercise a right, which Data Fiduciary must respond, what a Data Processor must retrieve or delete under contract, and when a grievance can move to the Data Protection Board of India. It also affects privacy notices, account controls, identity verification, retention schedules and evidence logs.

For organisations, the immediate task is readiness rather than assuming that every prospective right is already enforceable under the DPDP Act. For individuals, it is important to distinguish a statutory DPDP request from a right that may currently arise under a contract, another law, a sectoral direction or an organisation’s voluntary privacy policy.

Practically, this phasing allows an organisation to build and test DPDP-aligned request and grievance channels before May 2027 without telling individuals that Chapter III rights are already legally enforceable. Any current response commitment should identify its actual basis—such as an existing policy, contract, sectoral requirement or voluntary service standard—and should not be attributed prematurely to the DPDP Act or Rules. When you set timelines or scope, treat the DPDP Act, Notification G.S.R. 843(E) and Rule 1 of the DPDP Rules as the controlling commencement instruments and cross-check them in their official Gazette versions.

A Data Principal is defined as the individual to whom personal data relates. The role follows the person represented by the data, not the device, account, employer or organisation holding it. An employee may therefore be the Data Principal for an employment record, while the employer may be the Data Fiduciary if it determines why and how that record is processed.

Where the individual is a child (an individual under eighteen years of age under the Act) or a person with a disability who has a lawful guardian, the definition of Data Principal extends to the parent or lawful guardian acting on that person’s behalf in the circumstances recognised by law. This wording should not be implemented as a blanket assumption that every adult with a disability must act through another person; the organisation should verify the guardian’s authority and the circumstances in which representation is legally valid.^[1]

A Data Fiduciary determines the purpose and means of processing personal data and remains responsible for its statutory obligations. A Data Processor processes personal data on the Data Fiduciary’s behalf, usually under a services agreement, but may still need contractual capabilities to search, export, correct, restrict or erase records. A Consent Manager is a Board-registered person through whom a Data Principal may give, manage, review and withdraw consent using an accessible, transparent and interoperable platform. Classifying a vendor as a Processor does not remove the Data Fiduciary’s responsibility to operate the rights process.

Chapter III of the DPDP Act creates four connected rights for Data Principals and one set of duties. Section 11 addresses access to information about personal data. Section 12 covers correction, completion, updating and erasure. Section 13 establishes grievance redressal, while Section 14 permits nomination of another individual to act on death or incapacity. Section 15 imposes corresponding duties on Data Principals, and Sections 16 and 17 address remedies and exemptions within the wider statutory structure.^[1]

These rights are not equivalent to an unrestricted ability to obtain or delete every record. Their scope depends on statutory conditions, the basis and context of processing, applicable exemptions, the information needed to authenticate the requester and whether retention remains necessary for a specified purpose or compliance with law. An organisation should record which legal ground supports any limitation rather than relying on a generic statement that data cannot be disclosed or deleted.

The Digital Personal Data Protection Rules, 2025, operationalise this framework by requiring published methods for exercising rights, identification particulars and grievance handling, and by setting standards for security, retention and breach notification. Because the relevant Act sections and these operational Rules are scheduled to commence in May 2027, implementation teams should map each future obligation to a system owner, response workflow, evidence source and approved exception path before commencement.^[3]

Section 11 allows an eligible Data Principal to request a summary of the personal data being processed and the processing activities undertaken with it, including information about other Data Fiduciaries and Data Processors with whom the data has been shared and the data shared with them, together with other prescribed information. The right applies to data processed on the basis of consent given by the Data Principal and to processing under the legitimate uses recognised in Section 7.^[1]

The access right contains a targeted limitation for certain disclosures made to another Data Fiduciary authorised by law, following a written request for purposes such as preventing, detecting or investigating offences or cyber incidents, or prosecuting or punishing offences. Broader exemptions under Section 17 may also apply in specified circumstances. These limitations should not be converted into a routine refusal of the entire access request; the response should distinguish information that can be provided from information lawfully withheld.

A workable intake process asks the individual to identify the relevant account or relationship, state the access sought and complete proportionate authentication. An example request could ask for a summary of the personal data associated with a mobile number, the purposes for which it is processed, and the categories or identities of recipients covered by Section 11. The Data Fiduciary should preserve the request, verification result, search scope, systems consulted, processor responses, redactions and final communication.

Over-verification carries its own risk. Requesting identity documents that are unnecessary for the account or data concerned creates additional personal data and may deter legitimate requests. The control should match the disclosure risk: access to an authenticated account may require a different check from the release of a consolidated offline record containing financial or identity information.

Section 12 distinguishes related remedies. Correction addresses inaccurate or misleading personal data, completion addresses an incomplete record and updating brings an outdated record up to date. A request to change an old telephone number might identify the account, state the existing and replacement values, and provide verifiably authentic supporting information where necessary. The response process should propagate an approved change to relevant systems and Processors rather than correcting only the visible customer profile.

Erasure is qualified. A Data Fiduciary must erase personal data upon a valid request unless retention remains necessary for the specified purpose or for compliance with law. An inactive marketing profile may be capable of complete erasure, while records associated with a closed financial transaction may still have to be retained under tax, accounting, anti-fraud or sectoral record-keeping requirements. A mixed request may therefore lead to erasure from optional marketing systems, restriction of routine use in operational systems and continued retention of a limited legal archive.^[4]

Rule 8 adds scheduled-erasure and retention requirements for the records, purposes and classes of Data Fiduciary within its scope, including applicable minimum one-year retention and a notice at least forty-eight hours before certain scheduled erasure. It should not be read as a universal direction to keep every item of personal data for exactly one year. The retention schedule should identify the applicable Rule 8 category, the start of the retention period, any longer legal requirement and the systems holding duplicate copies or logs.^[3]

Where erasure is narrowed or declined, the file should show the legal or specified-purpose rationale, the categories retained, access restrictions, review date and information erased elsewhere. A bare reference to company policy is weaker than a documented link to a binding retention provision, active purpose or defensible legal hold. Vendor contracts should also require deletion or return capabilities, confirmation from subprocessors and preservation where a lawful hold applies.

Section 13 gives a Data Principal the right to use a readily available grievance mechanism provided by a Data Fiduciary or Consent Manager concerning an act or omission connected with its obligations or the exercise of rights. The Data Principal must exhaust that internal mechanism before approaching the Data Protection Board. An organisation should therefore distinguish a rights request from a grievance about how that request was handled, while allowing both records to be linked.^[1]

Once Rule 14 commences, the Data Fiduciary or Consent Manager must publish a reasonable period for responding to grievances, and that period cannot exceed ninety days. Ninety days is a ceiling, not a mandatory waiting period or default service level. A published period of thirty days, for example, should be administered as the organisation’s stated commitment rather than silently extended to ninety days.^[3]

A defensible escalation record includes the original request, acknowledgement, identity checks, internal owner, relevant policy version, processing logs, response, reason for any retention or refusal, grievance submission and final decision. If the published internal period expires without appropriate resolution, or the individual remains dissatisfied after exhausting the mechanism, the matter may be taken to the Board in the prescribed form. Decisions of the Board may be appealed to the Appellate Tribunal under the statutory process.

The Board pathway should not become the first operational response to every disagreement. Front-line staff need authority to correct obvious errors, route legal questions and identify complaints that may indicate a broader control failure. Repeated grievances involving the same system, vendor or deletion failure should trigger root-cause review rather than being closed as unrelated tickets.

The DPDP framework does not impose a universal seventy-two-hour deadline for responding to access, correction, updating or erasure requests. Nor does it require every grievance to remain open for ninety days. Rights-request timing should be governed by the applicable statutory provision once commenced, the organisation’s published grievance period, any shorter sectoral or contractual commitment and a reasonable internal service level.

The seventy-two-hour period appears in the personal data breach regime. Under Rule 7 of the DPDP Rules, the detailed breach report to the Data Protection Board must be provided within seventy-two hours of becoming aware of the breach, subject to the Rule’s requirements. The related intimation to affected Data Principals is a separate breach-notification obligation. Neither requirement should be copied into a rights-request policy as though it were a statutory access or deletion deadline.^[3]

Incident and rights workflows should nevertheless connect. A grievance alleging unauthorised access, unexpected disclosure or account takeover may indicate a personal data breach and should be routed immediately to the incident-response team. That escalation does not convert the grievance itself into a seventy-two-hour rights request; it activates a separate assessment under the security and breach provisions.

Section 14 permits a Data Principal to nominate another individual who may exercise the Data Principal’s rights in the event of death or incapacity. For this purpose, incapacity refers to an inability to exercise the rights because of unsoundness of mind or infirmity of body. Nomination is therefore a statutory continuity mechanism, not a routine delegation of account access while the Data Principal remains capable of acting.^[1]

A nomination workflow should capture the nominee’s identity and contact details, the scope of the nomination, the Data Principal’s authenticated instruction and a reliable timestamp. It should also explain how a nominee will later establish the triggering event. Because nomination may intersect with succession, account ownership and sector-specific documentation, the organisation should avoid promising that nomination automatically transfers assets, contractual rights or beneficial ownership.

When a nominee acts, the review should verify the nomination record, the nominee’s identity and evidence of death or incapacity before disclosing or changing personal data. Access should be limited to what is necessary to exercise the statutory rights. Product, legal and operations teams should also decide how nominations are amended or revoked and how conflicting claims are escalated.

Section 15 requires a Data Principal to comply with applicable law while exercising rights, not impersonate another person, and not suppress material information when providing personal data for documents, unique identifiers or proofs of identity or address issued by the State or its instrumentalities. It also prohibits registering a false or frivolous grievance or complaint and requires the Data Principal to provide only verifiably authentic information when seeking correction or erasure. The Schedule to the Act permits a penalty of up to ten thousand rupees for a breach by a Data Principal of these duties; that maximum is not automatic and any penalty would depend on the statutory process and facts.^[5]

These duties support proportionate safeguards, but they do not justify treating an inconvenient or repeated request as abusive without evidence. A Data Fiduciary may authenticate identity, ask for information needed to locate the relevant records and investigate inconsistencies. It should document why a request is considered false, frivolous or linked to impersonation and provide an appropriate response through the grievance mechanism.

Even before Chapter III formally commences, many organisations already operate access and correction processes under contracts, sectoral rules or voluntary policies. A structured approach makes those requests easier to handle now and positions them for DPDP alignment in 2027.

For organisations, the main DPDP task before May 2027 is to turn statutory rights and duties into reliable processes. That means connecting intake channels, authentication, routing, SLAs, logging, vendor obligations and escalation criteria into a single workflow rather than treating each request type as a separate ad hoc exercise.

By May 2027, the organisation should have approved request and grievance procedures, published channels, defined identification particulars, a grievance period within the Rule 14 ceiling, trained operators and escalation routes to privacy, security and legal reviewers. Security evidence collected under internal standards and retention records aligned with Rule 8 should connect into the same case-management process where they affect disclosure, deletion or incident assessment.

After commencement, monitor acknowledgement times, completion times, overdue cases, partial refusals, processor delays, authentication failures, repeated grievances and deletion exceptions. Metrics should be reviewed for control failures, not merely ticket volume. A rising number of retained-data disputes may indicate that notices, purpose records or retention schedules are too vague to support consistent decisions.

The governance file should contain the current privacy notice, terms of service, grievance policy, retention schedule, legal-hold standard, vendor agreements, incident-response plan and system evidence. Verify that each document cites the correct operative provisions and commencement status. An old template that describes prospective rights as already enforceable, or a new notice that promises deletion despite mandatory retention, can create avoidable contractual and representation risk.

Implementation decisions should be checked against the official Gazette versions of the Digital Personal Data Protection Act, 2023, Notification G.S.R. 843(E) and the Digital Personal Data Protection Rules, 2025. Secondary summaries are useful for workflow design, but they should not replace the operative text when determining commencement, exemptions, retention or escalation.

Interpretation may develop through orders of the Data Protection Board, appeals before the Appellate Tribunal, court decisions, amendments and government guidance. Assign an owner to monitor Gazette notifications, corrigenda and sectoral directions, then update notices, procedures, contracts, training and system requirements through a controlled change process.