Data Principal Rights Under DPDP: Templates + Workflow

Data Principal rights are the mechanism by which DPDP transforms from a paper regime into operational reality. A privacy notice can be ignored. A risk assessment can sit on a shelf. A request from a Data Principal — “show me everything you have about me” or “delete my data” — requires the organization to execute. This is where compliance gets tested in practice, and where most Indian organizations are not ready.

This is the operational guide to Data Principal rights under DPDP, with templates, response workflows, and the SLAs you need to meet.

The four substantive rights

§11 — Right to access

A Data Principal may obtain from a Data Fiduciary:

A summary of personal data being processed and the processing activities undertaken
The identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with a description of the shared data
Any other information related to the Principal’s personal data and processing that may be prescribed

Response timeline: prescribed in rules; practical planning target 30 days with option to extend for complex requests. Response must be in a machine-readable or human-readable form depending on request.

§12 — Right to correction and erasure

A Data Principal may obtain from a Data Fiduciary:

Correction of inaccurate or misleading personal data
Completion of incomplete personal data
Updating of outdated personal data
Erasure of personal data that is no longer necessary for the purpose for which it was collected, unless retention is required by law

Erasure propagation: you must also propagate erasure to Data Processors and any Fiduciaries you have shared the data with.

§13 — Right to grievance redressal

The Data Principal has the right to readily available means to raise grievances with the Fiduciary about any act or omission. If the Fiduciary does not resolve to the Principal’s satisfaction, the Principal can escalate to the Data Protection Board.

Grievance response timeline: the rules specify a short period (in early drafts, 7 days; practical planning should assume 7–14 days).

§14 — Right to nominate

The Data Principal may nominate another individual who, in the event of death or incapacity, will exercise the Principal’s rights on their behalf.

The request-response workflow

Stage 1 — Request intake

Multiple channels for receiving requests — email, web form, in-product settings, postal. Published contact point for grievances. Automated ticketing system to track each request from receipt to resolution.

Stage 2 — Identity verification

Before fulfilling a rights request, verify the requester is actually the Data Principal. Methods: authentication via existing account (for in-product requests), verification of knowledge of account details for email requests, government ID for high-sensitivity requests.

Balance: don’t create so much friction that legitimate requests fail, but don’t so little that an attacker can impersonate a Principal and extract their data.

Stage 3 — Scope determination

What personal data exists for this Principal, in what systems? This requires a data inventory mature enough to answer the question. Systems typically to check: product database, CRM, analytics, support, billing, email marketing, warehousing, backups.

Stage 4 — Extraction

For access requests, assemble the data in readable form. For correction/erasure, apply the change to all identified systems.

Stage 5 — Response

Deliver the response through an appropriately secure channel. For access, a structured document (JSON or PDF) delivered via authenticated download or encrypted email. For correction/erasure, a confirmation that all systems have been updated.

Stage 6 — Audit trail

Every step of the workflow logged: intake, verification, scope, extraction, response, confirmation. This is the evidence for both regulator inquiry and internal accountability.

Templates

Access request response template

[Date]
[Principal Name]
[Request Ref: DSAR-2026-XXXX]

In response to your request for access to your personal data under
Section 11 of the DPDP Act 2023, we are providing:

1. Summary of personal data we process about you:
   - [List by category: contact info, account info, transaction history, etc.]

2. Purposes of processing:
   - [List by purpose: service delivery, billing, support, etc.]

3. Third parties with whom we have shared:
   - [List of processors and fiduciaries]

4. Attached: structured data export in JSON format containing your
   complete personal data record.

If any of this data is inaccurate or outdated, you have the right
to correction under Section 12. Contact [DPO email] to request.

Erasure confirmation template

[Date]
[Principal Name]
[Request Ref: ERASE-2026-XXXX]

We confirm that we have erased your personal data across the following
systems: [list]. Retention has been applied only for the following
categories where required by law: [list with legal basis].

Erasure has been propagated to the following data processors we have
shared your data with: [list].

This confirmation completes your erasure request under Section 12
of the DPDP Act 2023.

Common operational failures

No complete data inventory. Cannot identify what personal data exists in what systems. Results in incomplete access responses and partial erasures.
Backup handling undefined. Erasure in production systems but not in backups. When backups are restored, the erased data returns.
Processor propagation manual and lossy. No automated mechanism to forward rights requests to processors; some requests get lost.
No SLA tracking. Requests exceed prescribed response timelines without alerts or escalation.
Identity verification too loose or too strict. Too loose enables social engineering; too strict prevents legitimate requests and generates grievance escalations.

Technology support

For scale-up SaaS companies, the DSAR workflow is increasingly handled by compliance-automation platforms: OneTrust, TrustArc, Transcend, DataGrail. These tools integrate with common data systems and automate the extract-and-respond workflow.

For smaller organizations, a structured manual process with well-documented runbooks is sufficient for the first year. Automation adds value when volume exceeds 10–20 requests per month.

Data Principal Rights Under DPDP (With Templates)