DPDP Data Principal Rights: How Indian Businesses Must Handle Access, Correction, Erasure and Grievance Requests Before May 2027

Every article in this series so far has dealt with what a business must do with personal data: how to collect it, how long to keep it, how to report a breach, how to govern vendors. This one deals with the other side of the table: what the person whose data you hold can require you to do. Sections 11 to 14 of the Digital Personal Data Protection Act, 2023 give every Data Principal, your customers, employees, users and patients, four enforceable rights, and Rule 14 of the DPDP Rules, 2025 requires your website or app to carry a working mechanism through which those rights can actually be exercised. These provisions sit in the eighteen-month commencement tranche and become enforceable on 13 May 2027, eighteen months after gazettal on 13 November 2025, which from the date of this article is 215 days away.

The central misconception to correct is that rights compliance is a drafting exercise. A privacy-policy paragraph saying "you may contact us to exercise your rights" is not a rights-management system. When a Section 11 access request arrives, someone must verify the requester, search every system that holds their data, identify every processor it was shared with, compile a lawful response and keep evidence that all of this happened. That is an operational capability spanning your website, customer support, CRM, vendors and legal function, and it cannot be assembled in the week before the deadline. For the overall statutory frame, the pillar reference is Data Privacy Compliance in India: The DPDP Act Framework.

What Rights Does a Data Principal Actually Have Under DPDP?

The Act creates four rights, and precision about their content and their limits is where most commentary goes wrong:

Three boundary points matter as much as the list. First, Sections 11 and 12 are consent-scoped. The access and correction rights run against a Data Fiduciary to whom the Data Principal has previously given consent, including consent referred to in Section 7(a); they are not a flat overlay on every legitimate-use head in Section 7. Grievance redressal and nomination carry no such limitation. Businesses processing employee data or statutory data under legitimate uses should map which rights actually attach to which dataset instead of assuming everything is answerable to everything. Second, DPDP deliberately omits rights that GDPR-trained teams expect. There is no general right to data portability, no right to object to processing and no right against solely automated decision-making; importing those into Indian compliance papers misstates the law, and the contrast with the European framework is mapped in our GDPR compliance guide for SMEs in Europe. Third, rights come with duties. Section 15 obliges Data Principals not to file false or frivolous grievances and to provide authentic information, with a penalty of up to Rs 10,000 for breach, which gives businesses a legitimate, documented basis for refusing abusive requests.

The Access Request Is More Complicated Than "Send Me My Data"

Section 11 looks simple until you try to answer it. The Data Principal is entitled to a summary of their personal data and processing activities, and, critically, the identities of the Data Fiduciaries and Data Processors with whom the data has been shared. That second component converts every access request into a data-mapping and vendor-inventory test. If the business cannot determine which CRM, analytics service, cloud provider, support platform, payment gateway and marketing tool received the individual's information, and which sub-processors sit behind those, it cannot produce a truthful Section 11 response. A business whose vendor list lives in a founder's head or a procurement spreadsheet last updated two years ago is holding an unanswerable legal obligation.

Two further disciplines follow. Identity before disclosure: an access response delivered to the wrong person is itself a personal data breach, so the request workflow must verify the requester against identifiers the business already holds before anything is compiled. Redaction before release: the summary covers the requester's data, not the data of other customers, employees or family members whose information may sit in the same records, and sloppy compilation creates a second violation while answering the first.

Rule 14: Your Website Needs a Real Rights-Request Mechanism

This is the provision that turns rights from statute into product design. Rule 14(1) requires every Data Fiduciary, and where applicable a Consent Manager, to prominently publish on its website or app the means through which a Data Principal may make a rights request, together with the identifiers required to identify that Data Principal. Read together with the contact-publication obligations elsewhere in the Rules, the compliant end-state is a visible, structured pathway: privacy page, exercise-your-rights entry point, request category selection, identifier capture, identity verification, ticket or reference number, internal routing and a response record. The Rule does not mandate any particular technology, a well-run form plus a tracked queue can satisfy it, but it does mandate that the means be published and real, and the publication obligation exists so that individuals can actually find the door.

One timing clarification deserves emphasis because conflicting claims are circulating. The 90-day ceiling in Rule 14(3) attaches to the grievance-redressal mechanism: the business must publish its grievance response period, and that period cannot exceed ninety days. It is not a statutory SLA for every access, correction or erasure request, for which the Act requires effective fulfilment without fixing a single outer number. Content announcing seven-day acknowledgement clocks or ninety-day erasure deadlines as universal statutory requirements is reading more into the Rule than the Rule contains. The safe operational design is to set your own published timelines for each request type, materially shorter than ninety days for ordinary requests, and to treat the grievance ceiling as the hard outer wall it is.

Correction and Erasure: The Request Must Propagate Through the Stack

Correction is the cleanest illustration of why rights fulfilment is a systems problem. A customer asks you to fix an email address. Updating the master account database while the old value persists in the CRM, the marketing-automation platform, the support desk and the analytics pipeline is not correction; it is the appearance of correction, and the next campaign to the wrong address is the evidence. A meaningful Section 12 workflow identifies every system, including every processor and sub-processor, where the data point lives, propagates the change, collects confirmation and logs the outcome.

Erasure presents the same architecture with a sharper edge, because erasure collides with retention law. Section 12(3) permits refusal where retention is required for compliance with law or remains necessary for the specified purpose, and the DPDP Rules add their own retention floor for certain logs. The correct response to an erasure request is therefore never a reflexive delete and never a reflexive refusal: it is a reconciliation of the request against the purpose test and the statutory retention matrix, executed across the full stack, with the reason for whatever is retained documented in the response. That reconciliation machinery is built in detail in our DPDP data retention and erasure rules guide, and the processor-instruction layer, getting vendors and their sub-processors to actually execute deletions and prove them, is covered in The Hidden Liability in Your Tech Stack.

Grievance Redressal Is the Gateway to the Data Protection Board

Section 13 does something structurally important: it makes your grievance desk the mandatory first stop and, in consequence, your first regulatory defence layer. A Data Principal with a complaint must exhaust the Data Fiduciary's grievance mechanism before approaching the Data Protection Board. Rule 14 requires the mechanism to be published, implemented and answered within a period you publish, capped at ninety days. Two consequences follow for how this function is staffed. A grievance that receives a substantive, documented, lawful response usually ends at the desk; a grievance that meets silence, boilerplate or delay graduates into a Board proceeding, carrying penalty exposure of a different order. And because every grievance is by definition about your own processing, the grievance log is simultaneously a compliance-early-warning system: recurring complaint themes are the audit findings you did not pay for. The discipline that matters is ownership: one named owner, one tracked queue, defined escalation to legal for any grievance touching security, children, processors or refusal of a statutory request.

The Overlooked Right to Nominate

Section 14 is the right that generic DPDP content will omit, and the one most likely to catch product teams unprepared. A Data Principal may nominate one or more individuals to exercise her rights in the event of death or incapacity, and Rule 14 requires nomination to operate through the Data Fiduciary's own mechanism. For most businesses this is an entirely new account-level capability, and it raises design questions no template answers off the shelf:

• Recording: where in the account or customer relationship is the nominee captured, and how are changes handled?
• Trigger events: what proof of death or incapacity will the business accept, a death certificate, medical certification, a court order, and who reviews it?
• Authentication: how does the nominee prove identity and authority before being given access to another person's data?
• Scope: which rights can the nominee exercise against which data, access to the account contents, correction, erasure, or merely closure?
• Aftermath: what happens to the account, subscriptions and retained data once the nominee has acted, reconciled with the retention rules?

The sectors where this bites hardest are exactly the ones with long-lived digital relationships: fintech and wealth platforms, healthcare and patient records, insurance, subscription services, and any product whose accounts outlive their users' ability to manage them. Building nomination capture into onboarding is trivially cheap now and painfully retrofitted later.

Build the Data Principal Request Workflow Before May 2027

Rights fulfilment is one workflow with branching actions, not four separate projects. The operational sequence below is the working instrument, and every stage should leave evidence:

Two disciplines make the workflow real. The vendor register is the linchpin: steps six and nine fail silently wherever the business does not actually know which processors hold personal data, which is why the rights programme and the vendor-governance programme are the same programme. Rehearse before the deadline: a tabletop access request and a tabletop erasure request run in the next quarter will surface the broken search paths, missing vendor contracts and unowned queues while fixing them is still an afternoon's work rather than a Board proceeding.

The Bottom Line

The May 2027 challenge is not knowing that customers have rights; every privacy policy already recites them. It is being able to identify the requester, locate every copy of their data across your systems and your vendors' systems, decide what the law permits or requires, propagate the action through the stack, respond within a published timeline and prove that the workflow happened. Sections 11 to 14 and Rule 14 are precise about what individuals can demand, including the consent-scoping of access and correction, the 90-day ceiling on grievance response and the nomination capability almost nobody has built, and the businesses that treat those provisions as an operations programme rather than a drafting exercise will be the ones whose grievances end at the desk instead of the Data Protection Board. There are 215 days to build it. The clock is ticking.

This article is published for general informational purposes and reflects the DPDP Act, 2023 and the DPDP Rules, 2025 as gazetted, as at 10 October 2026. It does not constitute legal advice on any specific set of facts.