The Digital Personal Data Protection Act, 2023 (DPDP Act) gives individuals important rights over their digital personal data and places corresponding responsibilities on organisations that determine the purpose and means of processing that data.

For businesses, one of the most operationally important aspects of DPDP compliance is the ability to receive, authenticate, track, investigate and respond to Data Principal requests in a consistent and legally compliant manner.

A Data Principal may want to correct inaccurate information, seek erasure of personal data, raise a grievance, withdraw consent or exercise another right available under the DPDP framework. Organisations therefore need more than a privacy policy. They need a functioning Data Principal Rights Request (DPRR) process supported by people, technology, procedures and appropriate controls.

The notified Digital Personal Data Protection Rules, 2025 provide additional operational requirements. In particular, Rule 14 requires Data Fiduciaries and, where applicable, Consent Managers to prominently publish the means through which Data Principals can make rights requests and any identifiers needed to identify them. It also requires a grievance redressal system with a published response period that cannot exceed 90 days.

This guide explains how businesses should build and manage a practical DPDP Data Principal request process, what rights need to be supported, how to verify requests, when personal data can be retained, common mistakes to avoid and how to create an auditable workflow.

Important: This article provides general information about the DPDP framework and is not legal advice. Organisations should assess their specific processing activities, applicable laws, contracts and regulatory obligations before implementing a particular process.

What Is a Data Principal Request?

A Data Principal request is a request made by an individual to a Data Fiduciary to exercise a right available under the DPDP Act.

The DPDP Act defines a Data Principal as the individual to whom the personal data relates. For a child, the definition includes the parent or lawful guardian; for a person with disability, it includes the lawful guardian acting on the person’s behalf.

Depending on the circumstances, a request may involve:

• correction of inaccurate personal data;
• completion of incomplete personal data;
• updating personal data;
• erasure of personal data;
• grievance redressal;
• withdrawal of consent where consent is the basis of processing; or
• nomination of another individual to exercise rights in specified circumstances.

The exact right available and the organisation’s response should always be assessed against the DPDP Act, Rules and any other applicable law.

Why Data Principal Requests Matter for Businesses

Rights requests are not simply customer-service tickets.

They can affect:

• customer databases;
• CRM systems;
• HR systems;
• marketing platforms;
• analytics systems;
• cloud storage;
• backups;
• data processors;
• identity-management systems;
• legal records;
• financial records; and
• business continuity processes.

For example, an individual may request erasure through a website.

The organisation may then need to determine:

1. Which systems contain the individual’s data?
2. Which processors received the data?
3. Which data can legally be erased?
4. Which data must be retained?
5. Which data should be corrected rather than deleted?
6. Whether another law requires retention?
7. Whether the requested individual can be authenticated?
8. Whether the request affects an ongoing transaction or legal obligation?

This is why a mature DPDP compliance programme should treat rights requests as a cross-functional operational process.

What Rights Can a Data Principal Exercise?

The DPDP Act establishes several rights for Data Principals.

Right to withdraw consent

Where processing is based on consent, the Data Principal can withdraw that consent at any time.

The DPDP Act requires the ease of withdrawal to be comparable to the ease with which consent was given. Once consent is withdrawn, the Data Fiduciary must, within a reasonable time, cease and cause its Data Processors to cease processing unless continued processing is required or authorised under the Act, Rules or another applicable law.

This is an important operational requirement.

A company should therefore have a mechanism capable of propagating a consent withdrawal to relevant systems and processors.

Right to Correction, Completion and Updating

Section 12 of the DPDP Act provides the Data Principal with a right to correction, completion, updating and, subject to the statutory conditions, erasure of personal data.

When a Data Fiduciary receives a request for:

• correction of inaccurate data;
• completion of incomplete data; or
• updating of personal data,

it must take the appropriate action under the Act.

Example

Suppose a customer informs an e-commerce company:

“My registered mobile number is incorrect. Please update it.”

The organisation should not treat this simply as an informal customer-service query if it forms part of a formal rights process.

It should have a mechanism to:

1. authenticate the requester;
2. identify the relevant account;
3. verify the requested change where necessary;
4. update the relevant systems;
5. propagate the change to relevant processors where required; and
6. maintain an appropriate record of the request and action taken.

Right to Erasure

The right to erasure is one of the most important and potentially complex Data Principal rights.

Under Section 12, a Data Principal may request erasure of personal data, and the Data Fiduciary must erase it unless retention is necessary for the specified purpose or to comply with another law.

This means that an erasure request does not automatically mean that every record must immediately disappear from every system.

The organisation must first determine whether there is a valid reason for retention.

Examples of potential retention considerations

Depending on the circumstances, an organisation may need to retain information because of:

• statutory obligations;
• regulatory requirements;
• accounting requirements;
• tax requirements;
• legal proceedings;
• contractual obligations; or
• another applicable law.

The organisation should document the reason for retaining information rather than simply rejecting an erasure request without explanation.

Right to Grievance Redressal

Section 13 gives a Data Principal the right to have readily available means of grievance redressal from the Data Fiduciary or Consent Manager in relation to their obligations and rights under the Act and Rules.

The Data Principal must exhaust the opportunity for grievance redressal before approaching the Board.

This makes the organisation’s internal grievance mechanism an important part of its DPDP compliance architecture.

Right to Nominate

Section 14 provides the Data Principal with the right to nominate another individual who may exercise the Data Principal’s rights in accordance with the Act and Rules in the event of death or incapacity.

Businesses should therefore consider whether their rights-management systems are capable of handling nomination-related requests.

A Data Principal Request Is Not Always an Erasure Request

One common compliance mistake is treating every rights request as a deletion request.

A request may instead ask for:

• correction;
• completion;
• updating;
• withdrawal of consent;
• information about processing;
• grievance redressal; or
• another applicable right.

The organisation should classify the request before taking action.

Step 1: Create a Single Entry Point for Rights Requests

A business should provide an easily identifiable method for submitting Data Principal requests.

For example:

Privacy Rights Portal

Submit a request to access, correct, update or erase your personal data.

The portal could be accessible through:

Website → Privacy → Your Data Rights

The organisation could also provide an email address or another communication mechanism where appropriate.

The notified Rule 14 requires the Data Fiduciary to prominently publish the means by which a Data Principal can make a request to exercise rights.

Step 2: Clearly Explain the Request Process

Businesses should tell individuals:

• where to submit a request;
• what information is required;
• how identity will be verified;
• what types of requests can be submitted;
• what happens after submission;
• how the requester can track the request;
• how the organisation will communicate its response; and
• how to escalate a grievance.

This information should be easy to find.

A rights process hidden somewhere in a lengthy privacy policy is unlikely to provide the same practical accessibility as a clearly identified rights portal.

Step 3: Collect Only the Information Necessary to Process the Request

A rights request itself involves personal data.

Therefore, the organisation should avoid collecting excessive information simply to process the request.

For example, if an authenticated customer account can establish identity, asking the customer to upload multiple identity documents may not always be necessary.

The verification mechanism should be proportionate to the risk and the nature of the request.

Step 4: Authenticate the Requester

Before disclosing, correcting or deleting personal data, the organisation needs to establish that the requester is the relevant Data Principal or an authorised person.

This is particularly important for:

• access requests;
• correction requests;
• erasure requests;
• requests involving sensitive account information;
• requests submitted by representatives; and
• requests relating to children or persons with lawful guardians.

Possible verification mechanisms

Depending on the circumstances, an organisation might use:

• authenticated account login;
• registered email verification;
• registered mobile number;
• transaction information;
• secure one-time password;
• account-specific identifier; or
• another appropriate verification method.

The objective should be to prevent unauthorised disclosure while avoiding unnecessary collection of additional personal data.

Step 5: Use the Identifier Published by the Organisation

Rule 14 specifically contemplates that a Data Fiduciary may require particulars such as a username or other identifier to identify the Data Principal.

The Rules define “identifier” broadly to include items such as:

• customer identification numbers;
• customer acquisition form numbers;
• application reference numbers;
• enrolment IDs;
• email addresses;
• mobile numbers; and
• licence numbers.

Businesses should therefore determine which identifiers are appropriate for their systems and clearly communicate them to Data Principals.

Step 6: Classify the Request

Once received, the organisation should classify the request.

A practical classification system could include:

Request Type	Example
Correction	“My address is incorrect.”
Completion	“My profile is missing information.”
Update	“Please change my phone number.”
Erasure	“Delete my account data.”
Consent withdrawal	“Stop processing my data based on my consent.”
Grievance	“I believe my data has been processed improperly.”
Nomination	“I want to nominate another individual.”

The organisation should avoid treating all requests using a single generic workflow.

Step 7: Identify the Relevant Processing Activity

The next question should be:

Which processing activity does this request relate to?

For example:

A customer may have data in:

• CRM;
• billing;
• customer support;
• marketing;
• loyalty programme;
• mobile application;
• website;
• fraud-prevention system; and
• cloud storage.

The organisation should map the request to the relevant processing activities before responding.

Step 8: Search Across Relevant Systems

This is where data mapping becomes critical.

A business cannot effectively respond to a Data Principal request if it does not know where personal data is stored.

The organisation should maintain a data inventory showing:

• system name;
• data category;
• purpose;
• business owner;
• processor;
• retention period;
• source;
• access controls; and
• deletion/correction capability.

Example

System	Personal Data	Processor	Action
CRM	Name, email, phone	Cloud provider	Correct
Marketing platform	Email	Vendor	Withdraw/delete as applicable
Billing	Transaction data	Payment processor	Retain if legally required
Support system	Customer communications	SaaS vendor	Review
Analytics	Usage data	Analytics provider	Assess

This creates an operational bridge between the rights request and actual processing systems.

Step 9: Assess Whether Any Retention Requirement Applies

An organisation should not automatically erase every record simply because a Data Principal requests erasure.

Section 12 expressly recognises situations where retention is necessary for a specified purpose or to comply with another law.

Example

A customer closes an account and requests deletion.

The business may determine that:

• account profile data can be erased;
• marketing data should no longer be used;
• certain support records may be deleted where appropriate;
• financial records must be retained under another applicable legal requirement.

The response should distinguish between data that is erased and data that must continue to be retained.

Step 10: Coordinate With Data Processors

A Data Fiduciary remains responsible for compliance in respect of processing undertaken by it or on its behalf by a Data Processor. Section 8 places responsibility on the Data Fiduciary for compliance with the Act and Rules.

Therefore, a rights request cannot simply stop at the organisation’s CRM.

If a relevant Data Processor holds the personal data, the organisation needs an appropriate contractual and operational mechanism to communicate the required action.

Example

Customer submits:

“Delete my marketing information.”

The business may need to coordinate with:

• CRM provider;
• email marketing platform;
• customer-data platform;
• analytics provider; and
• other relevant processors.

The organisation should know in advance how these requests are communicated and tracked.

Step 11: Take the Appropriate Action

After assessment, the organisation should execute the required action.

For correction

• update inaccurate information;
• propagate the correction to relevant systems where appropriate;
• verify completion.

For completion

• identify missing information;
• update relevant records.

For updating

• replace outdated information;
• maintain appropriate audit records.

For erasure

• identify data subject to deletion;
• identify data that must be retained;
• delete or anonymise where appropriate;
• communicate retention limitations where relevant.

For consent withdrawal

• record the withdrawal;
• stop relevant consent-based processing;
• communicate the change to relevant processors;
• determine whether other lawful processing continues.

Step 12: Record the Decision

Every rights request should have an appropriate audit trail.

The record could include:

• request ID;
• date received;
• requester identifier;
• request type;
• verification status;
• systems reviewed;
• processors contacted;
• decision;
• action taken;
• date completed;
• communication sent;
• retention exception, if any;
• escalation details.

The organisation should avoid retaining unnecessary copies of identity documents or other information simply because a request was submitted.

Step 13: Respond Clearly

A response should tell the Data Principal what happened.

Example: Correction request

We have received your request to correct your mobile number. Your request was verified and the mobile number associated with your account has been updated.

Example: Erasure request

We have processed your request to erase your personal data. The personal data associated with your account has been deleted where retention was not required. Certain transaction records will continue to be retained where required under applicable law.

The response should be clear, accurate and consistent with what the organisation actually did.

How Long Does a Business Have to Respond?

This is an area where organisations should avoid inventing a single universal “DPDP response deadline.”

The DPDP Act and Rules establish different requirements depending on the type of right and process.

For grievance redressal, Rule 14(3) requires the Data Fiduciary or Consent Manager to publish a grievance response period, which must not exceed 90 days, and requires appropriate technical and organisational measures to support the effectiveness of that system.

For other rights requests, businesses should assess the specific statutory provision, applicable Rules and any other applicable legal requirement rather than automatically applying a generic 30-day or 45-day deadline.

Compliance best practice

Even where a longer period may legally be available, organisations should establish internal service levels that allow requests to be:

• acknowledged promptly;
• authenticated efficiently;
• assigned to an owner;
• investigated systematically; and
• closed within the applicable timeframe.

What Should a Data Principal Request SOP Contain?

A written Data Principal Rights SOP should define:

1. Intake

How requests are received.

2. Verification

How the requester is authenticated.

3. Classification

How requests are categorised.

4. Assignment

Who owns each request.

5. Data discovery

How relevant systems are identified.

6. Legal assessment

How retention and other legal restrictions are evaluated.

7. Processor coordination

How external processors are instructed.

8. Execution

How correction, erasure or other actions are performed.

9. Quality control

How completion is verified.

10. Response

How the Data Principal is informed.

11. Escalation

When legal, privacy or security teams become involved.

12. Closure

How the request is documented and closed.

Create a Data Principal Request Workflow

A practical workflow can look like this:

Request received

↓

Request ID generated

↓

Identity/authentication

↓

Request classified

↓

Relevant data identified

↓

Applicable legal requirements assessed

↓

Relevant systems and processors identified

↓

Action approved

↓

Correction / erasure / withdrawal / other action executed

↓

Completion verified

↓

Data Principal notified

↓

Request closed and recorded

This workflow can be automated substantially for organisations with high request volumes.

Build a Central Rights Request Register

Businesses should consider maintaining a central register.

A basic register could contain:

Field	Example
Request ID	DPR-2026-00125
Date received	23 September 2026
Requester	Customer ID 83927
Request type	Erasure
Verification	Completed
Owner	Privacy Operations
Systems reviewed	CRM, billing, marketing
Processor action	Completed
Retention exception	Billing records
Date completed	25 September 2026
Response sent	Yes
Status	Closed

The precise information retained should be limited to what is necessary for governance and compliance

Automating Data Principal Requests

For larger organisations, manual email-based processes can quickly become difficult to manage.

A privacy rights management system can help automate:

• request intake;
• identity verification;
• ticket creation;
• classification;
• workflow routing;
• system discovery;
• processor notifications;
• deadline monitoring;
• approvals;
• response generation; and
• audit logging.

However, automation should not replace legal and privacy judgement.

For example, an automated deletion workflow may incorrectly delete information that must be retained under another law.

High-risk requests should therefore include appropriate human review.

When Should a Request Be Escalated?

Certain requests should trigger additional review.

Consider escalation when:

• the requester cannot be authenticated;
• multiple individuals’ data is involved;
• the request concerns a child;
• a guardian or representative is involved;
• there is an ongoing legal dispute;
• data is subject to a legal retention requirement;
• the requested deletion may affect regulatory records;
• the request involves a personal data breach;
• data has been shared with multiple processors;
• the organisation receives conflicting instructions; or
• the request could materially affect another individual’s rights.

A clear escalation matrix helps prevent inconsistent decisions.

Handling Requests From Parents, Guardians and Nominees

The DPDP framework recognises special situations involving children, persons with disabilities and nominees.

Businesses should therefore have separate procedures for:

• parental requests;
• lawful guardians;
• nominated individuals;
• representatives;
• deceased Data Principals; and
• individuals whose capacity to exercise rights is affected.

The organisation should verify authority before disclosing or changing personal data.

The Act defines Data Principal to include a parent or lawful guardian in relation to a child and a lawful guardian acting on behalf of a person with disability.

Data Principal Requests and Children

Requests relating to children’s personal data require additional care.

The DPDP Act contains specific obligations concerning children’s personal data, including requirements relating to verifiable parental consent and restrictions on certain processing.

The notified Rules provide additional requirements concerning verification of the adult identifying themselves as the parent.

Businesses serving children should therefore establish:

• age-related controls;
• parental verification procedures;
• parent/guardian request workflows;
• appropriate authentication;
• records of verification; and
• escalation procedures.

Data Principal Requests and Employee Data

Employee requests should not necessarily be handled through the same workflow as customer requests.

Employee data may exist across:

• HRIS;
• payroll;
• recruitment systems;
• attendance platforms;
• benefits providers;
• email systems;
• performance-management systems; and
• archived employment records.

The organisation should assess the applicable processing context and other legal obligations before taking action.

What Happens When Personal Data Has Been Shared With Third Parties?

This is one of the most important operational questions.

Suppose an organisation has shared a customer’s email address with:

• a CRM provider;
• marketing platform;
• customer-support platform; and
• analytics provider.

If the customer requests an action affecting that information, the Data Fiduciary needs to know:

• which processors received it;
• what contractual mechanisms exist;
• how instructions are transmitted;
• how completion is confirmed; and
• how exceptions are documented.

This is why Data Processor governance and rights-request management should be designed together.

Handling Erasure When Data Exists in Backups

Backups create a common operational challenge.

An organisation may have:

• production databases;
• disaster recovery databases;
• archived backups;
• offline backups.

A rights request should therefore be assessed against the organisation’s backup architecture and applicable retention requirements.

The objective should not be to create a technically impossible promise such as:

“Your data will disappear from every backup immediately.”

Instead, the organisation should establish a documented approach for:

• active systems;
• replicated systems;
• backups;
• restoration procedures; and
• eventual deletion according to applicable retention requirements.

Data Principal Requests and Data Accuracy

Accuracy becomes particularly important where personal data is used to make decisions affecting the Data Principal.

Section 8 requires the Data Fiduciary to ensure completeness, accuracy and consistency where personal data is likely to be used to make a decision affecting the Data Principal or disclosed to another Data Fiduciary.

Businesses should therefore prioritise correction mechanisms for information that directly influences:

• account access;
• eligibility;
• financial decisions;
• service provision;
• risk assessments; or
• other decisions affecting individuals.

How Businesses Should Handle Repeated or Frivolous Requests

The DPDP Act also places duties on Data Principals, including a duty not to register false or frivolous grievances or complaints and to furnish information that is verifiably authentic when exercising correction or erasure rights.

However, businesses should avoid using the concept of “frivolous request” as a shortcut to reject legitimate rights.

Each request should be assessed objectively.

Where a request is unclear, the organisation can seek clarification or appropriate verification rather than automatically rejecting it.

What If the Request Cannot Be Fully Granted?

There may be legitimate circumstances in which a business cannot fully comply with a request.

For example:

“Please delete all information associated with my account.”

The organisation may determine that:

• certain information can be erased;
• certain records must be retained by law;
• certain information relates to an ongoing transaction;
• certain information cannot be deleted immediately from a backup environment.

The response should clearly explain the outcome and applicable reason without unnecessarily disclosing internal security or confidential information.

Common Mistakes Businesses Make With Data Principal Requests

Mistake 1: Using only a generic privacy email address

A generic inbox may become difficult to manage as request volumes increase.

Mistake 2: No identity verification

This creates a risk of unauthorised disclosure or modification.

Mistake 3: Asking for excessive identity documents

Verification should be appropriate to the request and risk.

Mistake 4: Treating every request as deletion

Different rights require different workflows.

Mistake 5: Ignoring Data Processors

A business cannot effectively manage a request if it does not know which processors hold the relevant data.

Mistake 6: No retention analysis

An erasure request must be assessed against applicable retention requirements.

Mistake 7: No audit trail

If the organisation cannot demonstrate what it received, reviewed and did, proving compliance becomes more difficult.

Mistake 8: No central ownership

Requests can get lost when responsibility is divided between customer support, IT, legal and security teams.

Mistake 9: Inconsistent responses

Different teams may give conflicting answers to similar requests.

Mistake 10: No escalation mechanism

Complex requests require a clear route to privacy, legal or security teams.

DPDP Data Principal Request Checklist

Businesses can use the following checklist to audit their rights-request process.

Intake

• Is there a clearly published rights-request mechanism?

• Can Data Principals easily find it?

• Are request types explained?

• Is a request ID generated?

Authentication

• Is the requester authenticated?

• Is the authentication method proportionate?

• Are representatives appropriately verified?

Processing

• Is the request classified?

• Are relevant systems identified?

• Are relevant Data Processors identified?

• Is the applicable legal position assessed?

• Are retention requirements considered?

Execution

• Has the requested action been completed?

• Have relevant processors been instructed?

• Has completion been verified?

• Have exceptions been documented?

Response

• Has the Data Principal been informed?

• Is the response clear?

• Are limitations explained where applicable?

• Is the grievance route available?

Governance

• Is the request recorded?

• Are records protected?

• Are response times monitored?

• Are recurring problems analysed?

• Is the process periodically audited?

How to Build a Data Principal Rights Management Programme

A mature programme should include five layers.

Layer 1: Policy

Define:

• rights;
• procedures;
• responsibilities;
• escalation;
• verification;
• retention.

Layer 2: Technology

Implement:

• request portal;
• identity verification;
• workflow;
• system discovery;
• audit logs;
• reporting.

Layer 3: People

Assign responsibilities to:

• privacy team;
• legal;
• customer support;
• IT;
• security;
• HR;
• business teams.

Layer 4: Vendors

Ensure Data Processor contracts and operational processes support rights-related actions.

Layer 5: Governance

Track:

• request volumes;
• response times;
• unresolved requests;
• rejection reasons;
• processor delays;
• recurring data-quality issues.

Metrics Businesses Should Track

A useful rights-request dashboard can include:

Request volume

Number of requests received per month.

Request type

Percentage of requests involving:

• correction;
• erasure;
• consent withdrawal;
• grievances;
• other rights.

Response performance

Average time taken to close requests.

Outstanding requests

Number of requests still open.

Escalation rate

Percentage requiring legal/privacy review.

Processor dependency

Percentage requiring action from external processors.

Rejection/partial-compliance rate

Number of requests that could not be fully completed and the reasons.

These metrics can help identify weaknesses in the organisation’s data architecture.

Data Principal Requests and Privacy by Design

Rights management should ideally be considered when systems are designed.

For example, when developing a new application, product teams should ask:

“If a customer requests deletion tomorrow, can we identify and remove their personal data?”

If the answer is no, the system may have a privacy-by-design problem.

A well-designed system should make it possible to:

• identify personal data;
• associate it with a Data Principal;
• determine the processing purpose;
• identify processors;
• apply correction;
• apply deletion where appropriate; and
• maintain appropriate records.

DPDP Compliance and Data Mapping

Data mapping is the foundation of effective rights management.

For every personal-data field, organisations should know:

What?
What personal data is processed?

Why?
What is the purpose?

Where?
Which systems store it?

Who?
Which teams and processors access it?

How long?
What is the retention period?

What happens after a request?
Can it be corrected, updated or erased?

Without these answers, the organisation may struggle to respond consistently to Data Principal requests.

DPDP Data Principal Request Process: A Model SOP

A business can structure its internal SOP as follows:

Stage 1 — Receive

Receive the request through the approved channel.

Stage 2 — Register

Create a unique request ID.

Stage 3 — Verify

Authenticate the requester.

Stage 4 — Classify

Determine the applicable right.

Stage 5 — Locate

Identify relevant systems and processors.

Stage 6 — Assess

Review legal, contractual and operational considerations.

Stage 7 — Approve

Obtain additional review where necessary.

Stage 8 — Execute

Perform the requested action.

Stage 9 — Validate

Confirm that the action was completed.

Stage 10 — Respond

Communicate the outcome.

Stage 11 — Close

Record the final status and retain appropriate evidence.

What the Privacy Team Should Ask IT

A DPDP compliance team should work closely with IT.

Key questions include:

• Can we search personal data by customer ID?
• Can we identify all systems containing a user’s data?
• Can we identify processors receiving that data?
• Can we correct data consistently across systems?
• Can we delete data selectively?
• What happens to backups?
• How are deletion requests propagated?
• Can we produce an audit trail?
• How quickly can systems execute a request?
• What happens if a processor fails to complete an action?

These questions turn DPDP rights from a legal requirement into an executable technical process.

What the Privacy Team Should Ask Procurement

Procurement should also be involved.

For each relevant Data Processor, ask:

• Does the contract address data protection obligations?
• Can the processor support correction and erasure requests?
• How quickly must it respond?
• Can it identify specific Data Principals?
• Does it use subprocessors?
• How are downstream requests handled?
• What happens when the contract ends?
• What happens to backups?

A rights-management programme can fail if vendor contracts do not support the required operational actions.

What the Customer Support Team Should Know

Customer support may be the first team to receive a rights request.

Employees should therefore know how to:

• identify a rights request;
• avoid making unauthorised changes;
• verify the requester appropriately;
• create or route a rights ticket;
• avoid disclosing personal data to an unauthorised person;
• escalate complex requests.

For example, if a customer says:

“Delete all my information under the DPDP Act.”

The support representative should know that this is potentially a formal rights request and route it to the appropriate process.

What Happens if a Data Principal Goes to the Board?

Section 13 requires the Data Principal to exhaust the opportunity for grievance redressal with the Data Fiduciary or Consent Manager before approaching the Board.

The Board can inquire into complaints concerning breaches by a Data Fiduciary of its obligations or rights-related obligations under the Act.

This reinforces the importance of having an effective internal grievance mechanism.

Businesses should therefore retain appropriate evidence showing:

• when the grievance was received;
• how it was investigated;
• what action was taken;
• what response was provided; and
• when the matter was closed.

DPDP Rules 2025: Important Implementation Timeline

The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025.

The Rules use a phased commencement model:

• Rules 1, 2 and 17–21 came into force on publication;
• Rule 4 comes into force one year after publication;
• Rules 3, 5–16, 22 and 23 come into force eighteen months after publication.

Rule 14, which specifically addresses the exercise of Data Principal rights, therefore forms part of the provisions commencing 18 months after publication.

Businesses should distinguish between:

1. rights and obligations already contained in the DPDP Act;
2. detailed requirements introduced through the Rules; and
3. the applicable commencement date of each provision.

The official MeitY repository provides the notified Rules, corrigendum and enforcement timeline.

Organisations should check the latest official notifications when determining the precise implementation status of individual provisions.

Final Takeaway

A Data Principal request is not simply a privacy email.

It can trigger a coordinated process involving:

Identity verification

↓

Request classification

↓

Data discovery

↓

Legal assessment

↓

System and processor coordination

↓

Correction / erasure / withdrawal / other action

↓

Validation

↓

Response

↓

Audit record

For businesses, the biggest challenge is often not understanding that Data Principals have rights. The challenge is being able to execute those rights consistently across complex data environments.

A strong DPDP rights-management programme should therefore connect the organisation’s:

• privacy notice;
• data inventory;
• consent records;
• CRM;
• application systems;
• data processors;
• retention policies;
• security controls;
• grievance mechanism; and
• internal governance.

The notified DPDP Rules reinforce this operational approach by requiring organisations to prominently publish how Data Principals can exercise their rights and what identifiers may be needed, while also requiring an effective grievance redressal system with a published response period of no more than 90 days.

The practical objective should be simple:

When a Data Principal asks, the organisation should know who is asking, what data is involved, where that data exists, what the law requires, what action must be taken, who must take it, and how the outcome should be documented.

That is what turns a rights statement in a privacy policy into a functioning DPDP compliance process.

Frequently Asked Questions About Data Principal Requests

What is a Data Principal request under the DPDP Act?

It is a request made by a Data Principal to exercise a right available under the DPDP Act, such as correction, updating, erasure, grievance redressal or withdrawal of consent where applicable.

What rights can a Data Principal exercise?

The DPDP Act provides rights including withdrawal of consent where consent is the basis of processing, correction, completion, updating and erasure, grievance redressal and nomination.

Can a Data Principal request deletion of all personal data?

A Data Principal can request erasure in accordance with Section 12, but the Data Fiduciary may retain personal data where retention is necessary for the specified purpose or to comply with another applicable law.

How should businesses verify a Data Principal?

Businesses should use an appropriate authentication process that establishes the identity or authority of the requester without unnecessarily collecting additional personal data.

Does the business have to publish a rights-request process?

Rule 14 requires the Data Fiduciary and, where applicable, Consent Manager to prominently publish the means through which Data Principals may make requests to exercise their rights, along with relevant identifiers that may be required.

What is the grievance response period under the DPDP Rules?

Rule 14 requires the organisation to publish a grievance response period, which cannot exceed 90 days, and to implement appropriate technical and organisational measures to support effective response within that period.

Does a Data Fiduciary have to coordinate with Data Processors?

A Data Fiduciary remains responsible for compliance under the DPDP Act for processing undertaken by it or on its behalf by a Data Processor. Organisations should therefore establish contractual and operational mechanisms for processor participation in rights requests.

What happens if personal data must be retained by law?

The organisation should assess the applicable legal retention requirement and retain only what is necessary, while processing the remainder of the request as appropriate. Section 12 expressly recognises retention where required by law.

Can a Data Principal withdraw consent?

Yes. Where consent is the basis for processing, the Data Principal may withdraw consent, and the ease of withdrawal must be comparable to the ease with which consent was given.

Should businesses automate Data Principal requests?

Automation can be valuable for high-volume environments, but requests involving legal retention, children’s data, representatives, disputes or other complex issues may require additional human review.

DPDP Compliance Checklist for Businesses

Before going live with a Data Principal rights process, confirm:

• Rights-request mechanism published

• Privacy contact published

• Request types defined

• Authentication process documented

• Request classification implemented

• Data inventory completed

• Relevant systems mapped

• Data Processors mapped

• Retention exceptions documented

• Correction process established

• Erasure process established

• Consent withdrawal process established

• Grievance process established

• Escalation matrix established

• Request register implemented

• Audit trail implemented

• Staff training completed

• Vendor procedures tested

• Backup handling documented

• Periodic rights-request audits scheduled

Official Sources

For DPDP compliance work, organisations should rely on the Digital Personal Data Protection Act, 2023, the Digital Personal Data Protection Rules, 2025, subsequent official notifications and corrigenda, and other authoritative material issued by the Ministry of Electronics and Information Technology.

The official MeitY repository contains the notified Digital Personal Data Protection Rules, 2025, the corrigendum and the enforcement timeline.

The official text of the Digital Personal Data Protection Act, 2023 is available through MeitY’s repository.

Last reviewed: September 2026

Disclaimer: This article is for general informational purposes and does not constitute legal advice. Organisations should assess their specific processing activities, applicable laws and regulatory requirements before implementing a Data Principal rights-management process.