Data Principal Rights Under DPDP: How to Handle Access, Erasure, Grievances, and Nomination

The Digital Personal Data Protection Act, 2023 gives individuals a practical set of rights over their personal data. Under the Act, those individuals are called Data Principals. The businesses, apps, websites, employers, platforms, and other entities deciding why and how personal data is processed are usually Data Fiduciaries.

The mistake many companies make is treating Data Principal rights as a privacy-policy section. That is not enough. A right is only real if the business can receive the request, verify the person, find the data, act on downstream systems, respond within the required timeline, and preserve evidence.

This guide explains the four core Data Principal rights under DPDP and gives a practical workflow Indian businesses can implement before enforcement pressure increases.

Quick Answer: What Rights Does A Data Principal Have Under DPDP?

Under the DPDP Act, a Data Principal has four core rights: the right to access information about personal data, the right to correction and erasure, the right of grievance redressal, and the right to nominate another person to exercise rights in the event of death or incapacity. Businesses should be ready to handle these requests digitally, verify identity, complete the request within the prescribed timeline, and keep an audit trail.

In the current DPDP Rules framework used by ComplyZero's implementation planning, Data Fiduciaries should design for a maximum 90-day response window for Data Principal requests. Treat 90 days as the outer limit, not the operating target.

The Four Rights In One Table

DPDP right	Section	What the Data Principal can ask for	Business action required
Access information	Section 11	Summary of personal data and information about processing	Find data, summarize purpose, disclose sharing details where required
Correction and erasure	Section 12	Correct inaccurate data, complete incomplete data, update outdated data, erase data no longer needed	Update source systems and cascade changes to processors/recipients
Grievance redressal	Section 13	Complain about rights, consent, data handling, or unresolved requests	Provide a readily available grievance mechanism and resolve before Board escalation
Nomination	Section 14	Nominate another individual to exercise rights after death or incapacity	Store nomination, verify nominee, process future requests through nominee workflow

A Data Principal Rights Workflow Businesses Can Actually Run

The safest way to implement DPDP rights is to treat each request like an operational case.

Step 1: Intake The Request

Create one obvious channel for Data Principal requests. This can be an account dashboard, privacy portal, email alias, or support form, but it should not be buried inside a general contact page.

The intake form should capture:

• request type: access, correction, completion, update, erasure, grievance, nomination
• Data Principal identifier: email, phone, account ID, employee ID, customer ID, or other verified identifier
• relationship with the business
• details of the requested action
• supporting documents, where needed
• preferred response channel
• consent to process the request data for verification and fulfilment

Do not collect excessive identity documents. Verification should be proportionate to the data and risk. An ecommerce account request does not need the same verification burden as a financial, healthcare, or employment-record request.

Step 2: Acknowledge And Start The Clock

Every request should receive an acknowledgement. The acknowledgement should include:

• request reference number
• request type received
• date received
• expected response timeline
• any information still needed from the Data Principal
• grievance or escalation contact

If your operating model uses the 90-day outer window, create internal milestones earlier than that:

Milestone	Suggested internal target
Acknowledge request	1 to 3 working days
Verify identity	7 to 10 working days
Complete system search	15 to 30 days
Vendor or processor action	30 to 45 days
Legal/privacy review	45 to 60 days
Final response	Before day 90

The goal is to avoid discovering on day 85 that a vendor, warehouse, backup system, or support tool was missed.

Step 3: Verify The Requester

Before giving access, correcting data, or erasing records, confirm that the requester is the Data Principal or an authorised nominee.

Verification should match risk:

• low-risk account data: authenticated account session, email OTP, or phone OTP
• employee data: HR identity check and employee record match
• financial or health data: stronger verification and manual review
• nominee request: nominee record, death/incapacity evidence if relevant, and legal/privacy review

Do not use rights requests as a reason to create new, permanent identity databases unless necessary. Store only the evidence needed to prove the request was handled correctly.

Step 4: Locate The Data Across Systems

Most rights failures happen here.

A company may erase data from the main app database but forget the CRM, support desk, analytics events, data warehouse, email platform, payment processor, fraud tool, or manually exported spreadsheets.

Create a system map before requests arrive.

System type	What to check
Product database	Account profile, preferences, usage records, uploaded files
CRM	lead records, sales notes, lifecycle status
Support desk	tickets, chat transcripts, attachments
Marketing tools	email lists, campaign events, ad audiences
Analytics	user identifiers, event streams, cohort data
Data warehouse	copied tables, derived records, exports
Payment tools	billing records, invoices, transaction references
HR systems	employee profile, payroll, attendance, benefits
Vendors/processors	copies held on behalf of the Data Fiduciary
Backups	retention schedules and restore-process controls

For erasure, be precise. Some records may need to be retained because of tax, accounting, fraud-prevention, employment, litigation, or other legal obligations. The final response should explain what was erased and what was retained because another legal basis applies.

Step 5: Decide The Action

Each right has a different operational response.

Access

The Data Principal may ask for information about personal data being processed. Your response should be understandable and useful, not a raw database dump.

Include:

• categories or summary of personal data held
• purposes for which data is processed
• categories of recipients or entities with whom data has been shared, where required
• instructions to exercise correction, erasure, grievance, or withdrawal options

Correction, Completion, And Update

For correction requests, determine whether the existing data is inaccurate, incomplete, or outdated. Ask for evidence only where the data type justifies it.

Examples:

• change of email address: verify through current account and new email
• correction of billing address: verify through account access
• correction of employment date: HR/manual review
• correction of health or financial data: stronger evidence and audit trail

After correction, propagate the update to relevant systems and processors.

Erasure

Erasure is not just deletion from one table. It is a coordinated process.

Check:

• whether the purpose has ended
• whether consent has been withdrawn
• whether retention is required by law
• whether another legitimate use under Section 7 applies
• where the data was shared
• whether vendors or processors must delete or return the data
• whether anonymisation is appropriate for analytics records

The response should state the outcome clearly: erased, partially erased, retained for legal reason, or unable to act because verification failed.

Grievance

A grievance may relate to a rights request, consent issue, breach concern, notice problem, or any other DPDP-related obligation.

The grievance channel should capture:

• complaint category
• original request reference, if any
• facts provided by the Data Principal
• requested remedy
• assigned owner
• status and resolution notes

Under the DPDP framework, a Data Principal should use the Data Fiduciary's grievance mechanism before approaching the Data Protection Board. That means your grievance process is not decoration. It is your first line of defence.

Nomination

The right to nominate is unusual and important.

A Data Principal may nominate another individual to exercise rights in the event of death or incapacity. Businesses should decide now how nomination will be captured, verified, updated, and used later.

At minimum, store:

• nominee name
• nominee contact details
• relationship, if provided
• date of nomination
• Data Principal confirmation
• method of verification
• update/revocation history

For sensitive accounts, do not let a nominee immediately access personal data without further verification and review.

Step 6: Cascade To Vendors And Processors

If personal data was shared with a processor or another entity, rights fulfilment may require downstream action.

Contract clauses should require processors to:

• support rights requests
• correct or delete data when instructed
• return confirmation
• act within a defined SLA
• preserve evidence
• notify the Data Fiduciary if they cannot comply

Without vendor SLAs, the Data Fiduciary is still responsible but may not have the operational leverage to complete the request on time.

Step 7: Respond Clearly

The final response should be plain, specific, and non-defensive.

Include:

• request reference
• request type
• action taken
• systems covered at a high level
• data retained and legal reason, if any
• vendor action, if relevant
• grievance or escalation channel
• date of closure

Avoid vague responses such as "your request has been processed." A Data Principal should understand what happened.

Step 8: Preserve The Evidence

For every request, keep an evidence record:

• request received
• verification method
• systems searched
• action taken
• vendor instructions and confirmations
• legal basis for any refusal or retention
• final response
• closure date

This is the record you will rely on if a request becomes a grievance or Board complaint.

What Can A Business Refuse?

The DPDP Act gives rights, but a business does not need to do impossible or unlawful things.

A request may need to be limited, refused, or partially fulfilled where:

• the requester cannot be verified
• the data must be retained under law
• fulfilling the request would disclose another person's personal data
• the request concerns data no longer identifiable to the person
• the request is outside the right being invoked
• the requested action would conflict with a court order, investigation, or legal hold

If you refuse or partially fulfil a request, explain the reason and preserve the decision record.

Data Principal Duties Also Matter

DPDP rights come with duties. Section 15 requires Data Principals to comply with applicable law, avoid impersonation, avoid suppressing material information, furnish only verifiably authentic information where exercising correction or erasure rights, and not register false or frivolous grievances.

Businesses should not use these duties to discourage legitimate requests. But they can use them to design proportionate verification, reject false requests, and keep records when a request appears abusive or fraudulent.

Implementation Checklist

Before the main enforcement deadlines, businesses should have:

• a public rights request channel
• a grievance redressal channel
• a named owner for requests
• identity-verification rules by risk level
• a system inventory mapped to personal data
• vendor SLAs for rights support
• erasure and retention rules
• nominee capture and verification rules
• response templates
• audit logs for request handling

If you cannot find personal data across systems today, you are not ready for DPDP rights enforcement tomorrow.

FAQ

Who is a Data Principal under DPDP?

A Data Principal is the individual to whom personal data relates. If the person is a child, the term includes the child's parent or lawful guardian. If the person has a disability and acts through a lawful guardian, the guardian may be relevant in exercising rights.

What are the main Data Principal rights under DPDP?

The main rights are access to information, correction and erasure, grievance redressal, and nomination. These are set out in Sections 11 to 14 of the DPDP Act.

How quickly must businesses respond to Data Principal requests?

Businesses should design for the prescribed DPDP Rules timeline and treat the 90-day response window used in current implementation planning as an outer limit, not a target. Straightforward requests should be resolved much earlier.

Does erasure mean deleting everything immediately?

No. Erasure applies when data is no longer needed for the purpose or when the relevant basis ends. Some data may need to be retained because of legal, accounting, security, fraud-prevention, employment, litigation, or regulatory obligations. The business should explain any retained data and the reason.

Can a Data Principal complain directly to the Data Protection Board?

The DPDP framework expects Data Principals to first use the Data Fiduciary's grievance redressal mechanism. If the grievance mechanism is missing, ineffective, or the response is unsatisfactory, escalation risk increases.

What is the right to nominate under DPDP?

The right to nominate lets a Data Principal name another individual who can exercise their DPDP rights in the event of death or incapacity. Businesses should create a way to capture, update, verify, and act on nominee details.

Bottom Line

Data Principal rights are not solved by publishing a privacy policy. They require a request workflow, system inventory, vendor process, response discipline, and evidence trail.

The companies that prepare early will have a calmer compliance experience. The companies that wait will discover that the hard part is not writing the rights. It is finding, changing, deleting, and proving action across all the places personal data lives.