Is your Company actually ready for a data principal request?

Empowering

Picture this scenario. A customer sends your company an email that reads: "I want to know what personal data you hold about me, who you have shared it with, and I want it deleted." Your support team forwards it to legal. Legal asks IT. IT checks with the CRM team. The CRM team says they only have partial data. The marketing team has a separate database. The HR team has employee data that might be mixed in. The vendor who runs your loyalty programme has another copy. And nobody is sure whether the data was shared with a third-party analytics provider six months ago.

Three weeks pass. The customer has not received a response. They file a complaint with the Data Protection Board of India.

This is not a hypothetical situation. Under the Digital Personal Data Protection Act, 2023 (DPDPA), every individual whose personal data is processed, referred to as a Data Principal, has legally enforceable rights: the right to access their data, the right to correct inaccurate data, the right to have their data erased, the right to file grievances and the right to withdraw consent when these rights are not fulfilled. The DPDP Rules, 2025, further specifies how companies must operationalise these rights, including publishing request mechanisms on their websites, defining response timelines, and maintaining documentation.

Yet most companies in India are unprepared for what happens when a Data Principal actually exercises these rights. They have privacy policies on their websites. They may even have appointed a Data Protection Officer. But the operational infrastructure to receive, verify, process, and respond to a Data Principal request within the legally mandated timeline simply does not exist.

This blog is a practical walkthrough. It examines what the law requires, what actually happens inside most organisations when a request arrives, where the process breaks down, and what you need to build before the first complaint reaches the Data Protection Board.

Chapter 2: What the DPDPA Actually Requires

Before examining operational readiness, it is essential to understand exactly what the DPDPA and the DPDP Rules, 2025, mandate regarding Data Principal rights. These are not aspirational guidelines. They are legally binding obligations with defined penalties for non-compliance.

Right to Access (Section 11)

Every Data Principal has the right to obtain from the Data Fiduciary a summary of the personal data being processed and the processing activities undertaken with that data. This includes the identities of all Data Processors and other Data Fiduciaries with whom the personal data has been shared. The information must be provided in a clear, concise, and intelligible form, preferably in a format that can be downloaded digitally.

This means your company must know, at any given point, exactly what personal data it holds for any individual, where that data resides across all systems, who it has been shared with (including vendors, partners, and processors), and be able to compile and deliver this information in a readable format.

Right to Correction and Erasure (Section 12)

Data Principals have the right to demand correction of inaccurate or misleading personal data and the right to have their personal data erased. Erasure applies when the data is no longer necessary for the purpose for which it was collected, or when the Data Principal withdraws consent. However, this right is not absolute. Retention may be required under other laws (tax records, contractual obligations, regulatory mandates), and these exceptions must be clearly documented and communicated.

Right to Grievance Redressal (Section 13)

Every Data Fiduciary must establish an accessible grievance redressal mechanism. This includes appointing a Grievance Officer whose contact details must be published, and implementing a process to acknowledge and resolve complaints within the timelines defined in the Rules. Rule 14(3) of the DPDP Rules, 2025, requires Data Fiduciaries to publish the specific timeline within which they will address grievances and implement technical and organisational measures to meet those timelines. If the Data Principal is not satisfied with the response, they can escalate directly to the Data Protection Board of India, without needing a lawyer or paying any fee.

Right to Nomination (Section 14)

Data Principals can nominate another individual to exercise their data rights in case of death or incapacity. Companies must have mechanisms to accept, verify, and process nomination requests, and to respond to nominees who exercise the deceased or incapacitated person's rights.

Right to Withdraw Consent (Section 6(4))

A Data Principal has the right to withdraw consent at any time, with the same ease with which consent was given. Upon withdrawal, the Data Fiduciary must cease processing the personal data that was collected on the basis of that consent, unless retention is required under any law. The withdrawal of consent does not affect the legality of processing that occurred before the withdrawal. Companies must ensure that the consent withdrawal mechanism is as simple and accessible as the original consent collection process. If a customer gave consent through a single click on a website, the withdrawal process cannot require them to send a physical letter or visit an office. The Data Fiduciary must also inform the Data Principal of the consequences of withdrawing consent before it is acted upon.

Rule 14: Operationalising the Rights

Rule 14 of the DPDP Rules, 2025, is where the obligations become operational. It requires every Data Fiduciary and Consent Manager to publish on their website or application the specific means by which a Data Principal can submit a rights request. This removes any ambiguity: you cannot rely on informal channels, generic email addresses, or verbal requests. You must have a defined, published, and accessible process.

Chapter 3: Anatomy of a Data Principal Request

When a Data Principal request arrives, it triggers a chain of actions that most companies have never rehearsed. Here is what a properly handled request looks like, step by step.

Step 1: Receiving the Request

The request arrives through the published mechanism on your website or app. Under Rule 14, this mechanism must be clearly described and accessible. The request could be for access ("tell me what data you have on me"), correction ("my address is wrong in your system"), erasure ("delete all my data"), grievance ("I asked for deletion and you did not respond"), nomination ("I am nominating my daughter to handle my data rights") or withdraw consent. The system must log the timestamp, assign a unique reference number, and send an acknowledgement to the Data Principal.

Step 2: Identity Verification

Before acting on any request, the company must verify that the person making the request is actually the Data Principal whose data is involved. This is a critical security step. If someone impersonates a Data Principal and you delete or share data, the company is liable for a data breach. Verification methods might include OTP to the registered mobile number, email verification, Aadhaar-based e-KYC (with separate consent for this verification), or matching against identity details already on file. The verification process must not be so burdensome that it discourages legitimate requests.

Step 3: Request Classification and Routing

Once verified, the request must be classified. An access request follows a different workflow than an erasure request. A grievance about non-response must be escalated differently from a first-time correction request. The request must be routed to the right team: IT for data retrieval, legal for assessing exceptions, the Grievance Officer for complaints, and the DPO for oversight. Most companies fail here because there is no predefined routing logic.

Step 4: Data Discovery Across Systems

This is where most organisations break down completely. A Data Principal's data does not live in one place. It exists across the CRM, the billing system, the marketing automation platform, the customer support ticketing system, the analytics database, email archives, cloud backups, the HR system (if the Data Principal is also an employee), third-party vendors who received the data, and physical records that may have been scanned or filed. Without a comprehensive data inventory and data flow map, it is impossible to locate all instances of a person's data. And if you miss even one system, your response is incomplete and potentially non-compliant.

Step 5: Executing the Action

For an access request, the company must compile a summary of all personal data held, the purposes for which it is processed, and the identities of all entities with whom it has been shared. For a correction request, the update must propagate across every system where the data exists, including notifying Data Processors. For an erasure request, the data must be deleted from all systems, and the company must identify any legal exceptions that require continued retention (tax records, ongoing contracts, regulatory mandates) and communicate these clearly to the Data Principal. For withdrawal of consent, the company must immediately cease processing the personal data that was collected under that consent, propagate the withdrawal instruction to all Data Processors, and inform the Data Principal of any consequences of the withdrawal before acting on it. For a grievance, the Grievance Officer must investigate and provide a reasoned response.

Step 6: Response and Documentation

The response must be delivered within the published timeline. Rule 14(3) requires Data Fiduciaries to publish the timeline within which grievances will be addressed, and grievance redressal must be completed within 90 days. Every step of the process, from receipt to response, must be documented. This documentation is your evidence of compliance if the Data Principal escalates to the Data Protection Board. Without it, you have no defence.

Chapter 4: Where Companies Fail

Based on our experience working with organisations across sectors, here are the most common failure points when a Data Principal request arrives.

1. No Published Request Mechanism

Many companies have a privacy policy that mentions data rights but provide no clear mechanism for exercising them. There is no dedicated form, no specific email address, no defined process. The privacy policy says "contact us" without specifying how. Under Rule 14, this is a direct violation. The mechanism must be published on the website or app, with clear instructions on how to submit each type of request.

2. No Data Inventory or Data Map

When a request arrives, the first question is: where does this person's data actually live? Most companies cannot answer this. Data has accumulated across dozens of systems over years, with no central record of what is stored where, for what purpose, and with whom it has been shared. Without a data inventory, every request becomes a manual treasure hunt across departments.

3. No Identity Verification Process

Companies receive a request and act on it without verifying the requester's identity. This creates a data breach risk: if someone impersonates a Data Principal and gains access to their personal data, the company is liable. Conversely, some companies make verification so difficult that Data Principals give up, which is also non-compliant.

4. No Cross-System Retrieval Capability

Even when the data inventory exists, most companies cannot retrieve a single person's data across all their systems in a unified way. The CRM team can pull their records, but the marketing platform needs a separate export, the analytics database requires a SQL query by someone in IT, and the vendor who runs the loyalty programme has their own timeline. Compiling a complete response requires coordination across five or more teams with no established workflow.

5. No Defined Timelines or SLAs

The DPDPA requires responses within specific timeframes. Most companies have no internal SLAs for Data Principal requests. The request sits in someone's inbox, gets forwarded multiple times, waits for approvals that have no deadline, and by the time anyone takes action, the Data Principal has already escalated to the Data Protection Board.

6. No Documentation or Audit Trail

When the Data Protection Board asks for evidence that a request was handled properly, many companies have nothing to show. No logs, no timestamps, no record of who did what, no documented rationale for any exceptions or partial denials. Without an audit trail, even a properly handled request looks like non-compliance.

7. Erasure Does Not Reach Third Parties

A Data Principal asks for erasure. The company deletes their data from the CRM. But the data still exists with the email marketing vendor, the analytics partner, the payment processor's records, and the cloud backup from three months ago. True erasure requires propagating the deletion across every entity that received the data, and documenting confirmation from each one.

8. Grievance Officer Exists Only on Paper

Many companies have appointed a Grievance Officer to satisfy the legal requirement but have not empowered that person to actually investigate and resolve complaints. The Grievance Officer has no access to the systems where data is stored, no authority to direct IT or marketing teams, and no dashboard to track open grievances. When a complaint arrives, the Grievance Officer has neither the tools nor the mandate to resolve it.

Chapter 5: Building Your Data Principal Request Infrastructure

Readiness is not a document or a policy. It is an operational capability. Here is what your company needs to build.

1. Published Rights Request Portal

Create a dedicated page on your website and app where Data Principals can submit requests. This page should clearly list each type of request (access, correction, erasure, grievance, nomination), explain what information the Data Principal needs to provide, state the expected response timeline for each request type, provide the Grievance Officer's name and contact details, and confirm that exercising these rights is free of charge. The portal should generate a unique reference number for every request and send an automatic acknowledgement.  

2. Comprehensive Data Inventory

Before you can respond to any request, you need to know where personal data lives. Build a data inventory that maps every system that stores personal data (CRM, HRMS, billing, marketing automation, analytics, cloud storage, email archives), every category of personal data in each system (name, email, phone, Aadhaar, PAN, financial data, health data, biometric data), every purpose for which each category is processed, every third party and Data Processor with whom data is shared, and the retention period and legal basis for each category. This inventory must be maintained as a living document, updated whenever new systems are added or data flows change.

3. Identity Verification Protocol

Define a proportionate verification process. For low-risk requests (updating an email address), an OTP to the registered phone may suffice. For high-risk requests (full data access, erasure), multi-factor verification or Aadhaar-based e-KYC may be appropriate. The protocol should balance security with accessibility: verification must not be so complex that it becomes a barrier.

4. Cross-System Retrieval and Action Workflows

Build automated or semi-automated workflows that can pull a Data Principal's data from all systems identified in the data inventory. For correction requests, the workflow must propagate updates across every system. For erasure requests, it must delete or anonymise data across all systems and trigger deletion requests to every third party. For access requests, it must compile and format the data into a clear, downloadable response.

5. Timeline Tracking and Escalation

Implement a tracking system that logs every request, assigns deadlines based on the published timeline, sends automated reminders to the responsible teams as deadlines approach, escalates overdue requests to the DPO or senior management, and generates reports on request volumes, response times, and outcomes. A missed deadline is not just an operational failure. It is a compliance violation that can result in a complaint to the Data Protection Board.

6. Audit Trail and Documentation

Every request must be fully documented: when it was received, how the request was verified, what classification was assigned, which systems were searched, what data was found, what action was taken, what exceptions were applied and why, when the response was sent, and confirmation of receipt. This documentation is your primary evidence if the Data Principal escalates to the Data Protection Board. Maintain these records for a minimum of three years beyond the resolution date.

Chapter 6: What Happens When You Get It Wrong

The consequences of failing to handle a Data Principal request are not abstract. The DPDPA creates a direct pathway from an individual's complaint to significant financial penalties.

The Escalation Path

•        A Data Principal submits a request. The company fails to respond within the defined timeline, or provides an inadequate response, or ignores the request entirely.

•        The Data Principal files a complaint with the Data Protection Board of India. No lawyer is needed. No fee is charged. The Board must accept and investigate the complaint.

•        The Data Protection Board conducts an inquiry. It can require the company to produce records, explain its processes, and demonstrate compliance. If the company has no audit trail, no documented process, and no evidence of timely action, the outcome is predictable.

•        The Board imposes penalties. Under the Schedule of the DPDPA, penalties for a Data Fiduciary range up to Rs 250 crore for failure to take reasonable security safeguards to prevent a personal data breach. Other violations by a Significant Data Fiduciary, including non-fulfilment of Data Principal rights obligations, attract penalties up to Rs 150 crore.

Penalty Framework Under the DPDPA

The Board considers several factors when determining the penalty amount: the nature, gravity, and duration of the violation; the type and volume of personal data affected; whether the company took prompt remedial action; whether the violation was a first offence or a repeat occurrence; and whether the company had a documented compliance programme. A company that can demonstrate a robust Data Principal request system, documented processes, and timely responses will face significantly lower exposure than one that has no system at all.

Beyond penalties, non-compliance damages like customer trust, triggers negative media coverage, and can lead to business losses as customers and partners move to competitors who demonstrate stronger data protection practices.

Chapter 7: Industry-Specific Challenges

Data Principal requests create different challenges depending on the industry. Here is how the complexity varies across sectors.

E-Commerce and Retail

An e-commerce platform collects personal data across browsing behaviour, Wishlist, purchase history, payment information, delivery addresses, returns, reviews, and marketing preferences. A single customer's data may exist across the website platform, mobile app, payment gateway, logistics partner, marketing automation tool, customer support system, and analytics engine. Handling an erasure request means coordinating deletion across all of these, while retaining transaction records required under the GST Act and the Information Technology Act.

Financial Services and Banking

Banks and financial institutions face the most complex balancing act. A customer has the right to erasure under the DPDPA, but the RBI requires retention of KYC records for a minimum of five years after the business relationship ends. The Prevention of Money Laundering Act mandates retention of transaction records for ten years. Tax laws require preservation of financial records for specified periods. Every erasure request must be processed against a matrix of regulatory exceptions, and the Data Principal must be informed of exactly which data is being retained, under which legal mandate, and for how long.

Healthcare

Hospitals and healthcare providers process some of the most sensitive personal data: medical records, diagnostic reports, treatment histories, insurance claims, and prescriptions. A patient requesting erasure may not understand that clinical records must be retained for medico-legal purposes. The challenge is communicating these exceptions clearly while still fulfilling the parts of the request that can be honoured (marketing data, general contact preferences, non-clinical records).

Technology and SaaS Companies

SaaS providers often act as both Data Fiduciaries (for their own customers) and Data Processors (processing data on behalf of their clients' end users). A Data Principal request may arrive at the SaaS provider directly, but the data belongs to the client. The company must have clear procedures for redirecting such requests to the appropriate Data Fiduciary while still maintaining its own obligations as a Processor. Data often resides across multiple cloud regions, backup systems, and logging infrastructure, making complete erasure technically challenging.

HR and Employee Data

Employees are Data Principals too. An employee or former employee can submit an access request covering their entire employment lifecycle: recruitment data, offer letters, performance reviews, disciplinary records, payroll information, benefits data, exit interviews, and post-employment references. Many HR departments are unprepared for the scope of an employee access request, particularly when data is scattered across HRMS, payroll software, learning management systems, and informal records kept by managers.

Chapter 8: How DPDP Consultants Can Help

Building a Data Principal request capability requires expertise across legal interpretation, data management, technology implementation, and organisational change. DPDP Consultants provides end-to-end support.

Gap Assessment

We audit your current data landscape, identify every system that stores personal data, map data flows across departments and third parties, and assess your readiness to handle each type of Data Principal request. The assessment produces a detailed gap report with prioritised remediation steps.

Privacy Framework Implementation

We design and implement the complete Data Principal request infrastructure: the rights request portal, identity verification protocols, cross-system retrieval workflows, timeline tracking dashboards, and documentation templates. Every element is aligned with the DPDPA and the DPDP Rules, 2025.

DPO as a Service

We provide an experienced Data Protection Officer who oversees your Data Principal request programme, ensures timely responses, manages escalations, liaises with the Data Protection Board when required, and continuously improves the process based on request patterns and regulatory developments.

Consent Management

Our Consent Management platform captures, tracks, and manages consent across every touchpoint, ensuring that when a Data Principal withdraws consent or requests erasure, the system can immediately identify what data was collected under that consent and trigger the appropriate actions across all systems.

Grievance Redressal System

We implement a structured grievance redressal mechanism with a dedicated portal, automated acknowledgements, case tracking, timeline monitoring, escalation alerts, and a complete audit trail. Your Grievance Officer gets a dashboard showing every open case, its status, and approaching deadlines.

Third-Party Assessment

We assess every vendor, partner, and Data Processor in your ecosystem to ensure they can support your Data Principal request obligations. This includes verifying their ability to locate and delete specific individuals' data, respond within your defined timelines, and provide confirmation of actions taken.

Frequently Asked Questions (FAQs)

Q: Can a company charge a fee for responding to a Data Principal request?

No. Under the DPDPA, exercising Data Principal rights is free of charge. A company cannot charge any fee for processing access, correction, erasure, or grievance requests. If a company imposes fees or unreasonable barriers, the Data Principal can escalate to the Data Protection Board.

Q: What is the timeline for responding to a Data Principal request?

The DPDP Rules, 2025, require Data Fiduciaries to publish the specific timeline within which they will address requests. Grievance redressal must be completed within 90 days of receiving a complaint. Companies should aim to acknowledge requests within 24 to 48 hours and provide substantive responses well within the published timeline. Failure to meet the timeline is a compliance violation.

Q: Does the right to erasure mean ALL data must be deleted?

Not necessarily. The right to erasure applies to data that is no longer necessary for the purpose for which it was collected or when consent is withdrawn. However, companies may retain data required under other laws (tax records under the Income Tax Act, KYC records under RBI guidelines, employment records under labour laws). The key obligation is to clearly inform the Data Principal about what data is being retained, under which legal mandate, and for how long.

Q: What happens if a Data Principal is not satisfied with the company's response?

The Data Principal can file a complaint directly with the Data Protection Board of India. No lawyer is required, and no fee is charged. The Board will investigate the complaint, examine whether the company followed its own published processes, met the defined timelines, and fulfilled its obligations under the DPDPA. If the Board finds non-compliance, it can impose penalties.

Q: Do Data Principal rights apply to employee data?

Yes. Employees are Data Principals under the DPDPA. They have the same rights to access, correct, and erase their personal data as customers. This includes recruitment data, performance records, payroll information, benefits data, and any personal data processed during and after employment. Companies must ensure their Data Principal request mechanisms are accessible to employees as well.

Q: How should companies handle requests from Data Processors?

If a Data Principal submits a request to a Data Processor (for example, a SaaS vendor processing data on behalf of a client), the Processor should redirect the request to the appropriate Data Fiduciary. However, the Processor must also have internal processes to act on instructions from the Data Fiduciary regarding access, correction, or erasure. Data processing agreements must clearly define the roles and responsibilities for handling Data Principal requests.

Q: Can a Data Principal nominate someone to exercise their rights?

Yes. Section 14 of the DPDPA allows Data Principals to nominate another individual to exercise their rights in case of death or incapacity. Companies must have mechanisms to accept, verify, and process nomination requests. When a nominee exercises the Data Principal's rights, the company must verify the nomination and respond within the same timelines as a direct request.

Q: What documentation should companies maintain for Data Principal requests?

Companies should maintain a complete audit trail for every request: date and time of receipt, method of verification, request classification, systems searched, data found, actions taken, exceptions applied (with legal basis), response sent, and confirmation of delivery. This documentation serves as evidence of compliance if the request is escalated to the Data Protection Board. Records should be maintained for at least three years beyond the resolution date.

Is Your Company Ready? Let Us Help You Find Out.

A Data Principal request will arrive. The question is not if, but when. And when it does, your company will either demonstrate compliance with a well-documented, timely response, or scramble to improvise while the clock ticks toward escalation.

DPDP Consultants builds your complete Data Principal request infrastructure: Gap Assessments, Privacy Framework Implementation, Rights Request Portals, Consent Management, Grievance Redressal Systems, DPO as a Service, and Third-Party Assessments across your entire vendor ecosystem.

Contact us today:

Website: www.dpdpconsultants.com

Email: info@dpdpconsultants.com

Your Data Principals have rights. Build the infrastructure to honour them.

Disclaimer: This document is prepared by DPDP Consultants for informational purposes only. It does not constitute legal advice and should not be relied upon as a substitute for professional legal counsel. The information contained herein is based on the Digital Personal Data Protection Act, 2023, and the DPDP Rules, 2025, as of September 2026. Laws, regulations, and their interpretations may change. Readers should consult qualified legal professionals for advice specific to their circumstances. DPDP Consultants assumes no liability for any actions taken or not taken based on the contents of this document.