Data Principal rights under India's Digital Personal Data Protection regime are delivered through a mechanism, not a promise. Rule 14 of the DPDP Rules requires a Data Fiduciary to prominently publish the means by which rights requests are made and any identifier a Data Principal must supply, to publish a grievance-response period that cannot exceed ninety days, to implement measures that make the system actually respond inside that period, and to support nomination of one or more individuals to exercise rights on a Data Principal's behalf.
That is four engineering commitments in one short rule, and none of them is satisfied by a paragraph in a privacy policy. Read rule 14 the way you would read a ticket: a published entry point, an identity scheme, a clock with an enforceable ceiling, and a delegation model. It lands in the eighteen-month tranche alongside notice, consent, safeguards and erasure, so it arrives with everything else rather than after it.
What Rule 14 Requires for Data Principal Rights
Rule 14 is the rights plumbing. It does not restate the rights themselves; it tells you what a Data Fiduciary has to stand up so that a Data Principal can use them, and what you have to tell the world about that machinery before anyone asks.
Three obligations do the work: prominent publication of the means of making a request and any identifier required to make one; a published grievance-response period capped at ninety days, plus measures that make the published period real; and nomination of one or more individuals to exercise rights on the Data Principal's behalf.
Notice what that implies. A request has to arrive somewhere you control, be attached to a person you can identify, be tracked against a clock you published, and be answerable by someone other than the account holder. Each is a product decision with a schema behind it. The DPDP compliance checklist treats rule 14 as one line item; in a sprint plan it is an epic.
Prominently Publish the Means and the Identifier
"Prominently publish" is the part teams skim, and it is a design constraint rather than a disclosure one. The means by which a DPDP rights request is made has to be findable without a reader hunting for it, which rules out burying the route in clause 11 of a policy document that nobody reaches.
Treat prominence as a placement requirement. A named route — a page, a form, an in-product menu item — reachable from the footer of every page and from the account area of the product, described in the same clear language the notice duty demands. If a reasonably motivated person cannot find how to file a request in under a minute, you have published the mechanism without publishing it prominently.
The second half of the obligation is more consequential. You must also publish any identifier a Data Principal needs to supply, which means deciding in advance, and in public, what you will ask for.
The Identifier Asks You to Get Minimisation Right
The identifier scheme is where the rule gets genuinely uncomfortable, because an identifier that asks for more than you need is a privacy problem of its own, and one that asks for too little makes verification impossible. Both failures are real and they pull in opposite directions.
Over-asking is the more common failure, and it is usually well-intentioned. A team worried about fraudulent requests asks for a government ID scan, a selfie and a utility bill. You have now built a collection point for highly sensitive documents, created a new retention question, and started collecting data you had no purpose for until you invented the verification step.
Under-asking fails differently. If an email address alone opens a deletion or disclosure request, anyone who can type an address can act on a stranger's data, and the rights surface becomes an attack surface. The remedy is not more documents; it is better use of what you already hold.
So verify inside the relationship. Ask for the identifier that already binds the person to the account — the registered email or mobile, proven by a challenge to that channel, plus a signal only the account holder would have, such as a recent transaction reference. You collect nothing new, and the published identifier is short and honest because it names something the person already gave you. Where you hold no verified channel, say so in the published scheme and describe the fallback rather than inventing one per request.
Rule 14 forces that decision into the open, which is a favour: an identifier requirement you cannot defend in public is one you should not be operating in private. The same minimisation discipline that governs access control decisions applies — the least data that establishes the claim, and nothing beyond it.
Want your rule 14 surface mapped before May 2027?
Share your work email and we'll map your rights request intake, identifier scheme, nomination record and grievance clock against what rule 14 actually requires.
The Ninety Day Grievance Period Is a Number You Choose
A ninety day grievance period is the ceiling, not the default. Rule 14 requires you to publish the period within which you respond to grievances, caps that period at ninety days, and separately requires you to implement measures so the system actually responds within the period you published.
Those are two distinct duties and the second is where teams get caught. Publishing ninety days and taking a hundred breaches the rule and your own published commitment at once. The number is not a disclaimer; it is a service level you put your name to.
That creates an incentive worth understanding before you pick it. A shorter published period reads better to customers and to enterprise buyers running a diligence questionnaire — and it is a commitment you then have to meet every time, including the holiday week when the person who owns DPDP grievance redressal is on leave. Pick it from measured capacity to close a grievance end to end, including cases needing engineering work, legal review or a processor to act, with headroom for the tail rather than the median.
Then build for the number. "Measures" in practice means a queue with an owner, a due date computed from receipt, escalation before the deadline rather than after, and a report showing the breach rate against the published period. Without that report you cannot evidence the second duty — and the Board weighs mitigation and the duration of a breach when it assesses a penalty.
Nomination Is the Surface Almost Nobody Has Built
Nomination is the genuinely unusual feature in rule 14, and most teams have no product surface for it at all. The rule covers nomination of one or more individuals to exercise rights on the Data Principal's behalf — a delegation model sitting inside a data protection rule.
Think about what shipping that implies. You need a nomination record: a durable object linking a Data Principal to one or more nominees, created by the Data Principal, with a timestamp and a trail of who changed it. One or more means the schema is a collection, not a nullable field, so the obvious shortcut of adding a nominee_email column is the wrong shape from the start.
You need a way to verify the nominee. When a request arrives from someone who is not the account holder, the identity question is now two questions: is this person who they claim to be, and are they the person nominated on this record? That second check is the one systems lack, and it is the one that stops a plausible stranger from inheriting someone's data by assertion.
And you need a way for the nomination to be revoked. A nomination that cannot be withdrawn is a permanent grant of someone else's rights. Revocation has to be as reachable as nomination, take effect immediately against in-flight requests, and leave the prior state visible in the record so you can answer what the arrangement was on a given date.
Scope this surface early. It is the item most likely to be discovered late, because nothing in a typical product roadmap resembles it and no adjacent compliance regime has trained teams to expect it.
The Rule 3 Notice and the Rights Surface Are One Workstream
The rule 3 notice and the rights surface are the same workstream, not two. The notice duty requires the notice to give the communication link and describe the other means by which a Data Principal can withdraw consent, exercise rights and complain to the Board — which means the artefacts rule 14 makes you build are the artefacts rule 3 makes you disclose.
Run them separately and they drift. The notice names a route the product renamed, or the product ships a rights page the notice has never heard of, and the inconsistency is visible to anyone comparing the two. The withdrawal path also carries its own standard: withdrawal must be available with an ease comparable to that with which consent was given. One-tap consent and support-ticket withdrawal fails that test however carefully the notice describes it.
Sequence it as one delivery. Build the intake, identifier scheme, nomination record and grievance queue, then write the notice and the published rights page against what exists. Writing the prose first guarantees you are describing a system you have not built — the same ordering mistake that shows up in GDPR readiness programmes producing documentation ahead of capability.
The Surfaces You Have to Ship
Five surfaces carry rule 14. Shipping them is the compliance work; the published text is the receipt.
| Surface | What it has to do |
|---|---|
| Rights request intake | A prominently published, findable route for making a DPDP rights request — reachable from every page and from inside the product, in clear language, recording receipt time as the start of the clock |
| Identity and identifier handling | Verify the requester using the published identifier and nothing more: a challenge to a channel you already hold, plus a signal only the account holder would have. No new document collection, and a stated fallback where no verified channel exists |
| Nomination | A nomination record supporting one or more nominees, created and revocable by the Data Principal, with nominee verification at request time and full change history retained |
| Grievance tracking against the published clock | A queue with a named owner, a due date derived from the published response period, escalation before the deadline, and reporting on performance against that period |
| Status communication | Acknowledge receipt, tell the requester what identifier or nomination proof is outstanding, and communicate the outcome — through the same means the rule 3 notice names |
Each row has an owner, a data model and a test. Treat the table as the definition of done for DPDP grievance redressal rather than as a summary of a policy.
What Rule 14 Does Not Tell You
Rule 14 does not tell you the scope of each individual right, and that gap matters when you are sizing the work. The rule governs the mechanism — publication, identification, the clock, nomination — and the substantive content of the rights sits elsewhere in the Act and Rules.
So build the mechanism against the rule and resist inferring scope from a summary. A pipeline that can receive a verified request, route it, track it against a published period and communicate an outcome is the part rule 14 is explicit about, and the part that takes quarters rather than weeks. Confirm the content of each right from the Act and the Rules themselves — the Ministry of Electronics and Information Technology publishes them at meity.gov.in — rather than from any summary, including this one.
That gives you a design brief agnostic to right type: model a request as a typed object with a verified requester, an optional nominee, a received timestamp, a due date and an outcome, then attach handling logic per right once you have read the right.
DPDP Rights Request Questions Teams Ask
These are the DPDP rights request questions teams ask once they realise rule 14 describes a system rather than a statement.
Yes. Ninety days is the ceiling rule 14 sets, not a prescribed period. Whatever you publish becomes the commitment the rule then requires you to meet through appropriate measures, so a shorter number is better external signalling and a harder operational promise. Pick it from measured capacity to close a grievance end to end, with headroom for the tail rather than the median.
Rule 14 requires you to prominently publish any identifier a Data Principal needs to supply; it does not hand you a list. The defensible position is to verify inside the existing relationship — a challenge to the registered email or mobile you already hold, plus a signal only the account holder would have. Demanding government ID scans creates a new store of sensitive documents and a new retention problem; accepting a bare email address turns the rights route into an attack surface.
Rule 14 covers nomination of one or more individuals to exercise rights on a Data Principal's behalf, and the substantive duties of a Data Fiduciary carry no size threshold. Plan on needing the surface. Building it means a nomination record that holds more than one nominee, a way to verify a nominee at request time, and a revocation path that takes effect immediately and leaves the prior state auditable.
No. The rule requires prominent publication of the means of making a request, publication of the response period, and measures that make the system respond within it. A paragraph can discharge the publication half if it is genuinely prominent and names a real route, but not the measures half. Without intake, identification, a tracked clock and a nomination record behind it, it describes a capability you do not have.
Rule 14 sits in the eighteen-month tranche, alongside notice, consent, security safeguards, breach intimation, retention and erasure, and cross-border transfer. That tranche is a single cliff rather than a ramp — nothing in it phases in gradually — so the rights surface has to be live at the same moment as everything else. Start it early rather than last.
Turn rule 14 into a tracked build, not a policy paragraph
Book a demo and we'll show how Konfirmity tracks DPDP rights requests, nomination records and grievance SLAs against the response period you published.
Book a demo
Build the Surface Before You Write the Policy Page
Build the surface first, then write the policy page — not the other way round. Teams that struggle with Data Principal rights are the ones that read rule 14 as a drafting exercise, because it is short, it reads like disclosure, and it sits among rules that mostly produce documents. What it produces is a queue, a verification flow, a delegation model and a published clock you are accountable to.
Start with the data model and work outward. Define the request object, the identifier scheme and the nomination record; stand up the queue with a due date and an owner; measure how long you really take to close a grievance; then pick the number you publish and write the notice and the rights page against the system that exists. In that order, the published text is true on the day it goes live, and rule 3 and rule 14 stop describing two different products.
Settle ownership now, too. The rights surface spans product, engineering, support and legal, and an obligation owned by all four is owned by none. Name the owner, give them the grievance report against the published period, and treat a missed deadline as an incident. That is the same exercise as fixing privacy roles and responsibilities, and cheaper before the requests arrive than after.
