Rights are where DPDP stops being a policy document and becomes an engineering requirement. India's Digital Personal Data Protection Act, 2023 gives every Data Principal a set of enforceable rights — and each one obliges you to build something. Here is what the rights are, what they require you to operate, and how a sane request workflow looks.
The rights, by section
The Act grants Data Principals four operative rights against a Data Fiduciary:
- Right to access information about their personal data (§11) — what you hold, the processing activities, and with whom it has been shared.
- Right to correction and completion, and right to erasure (§12) — fix inaccurate data, complete incomplete data, and delete data no longer needed.
- Right of grievance redressal (§13) — a working channel to raise and resolve complaints.
- Right to nominate (§14) — name another individual to exercise rights in the event of death or incapacity.
Underpinning all of them is the right to withdraw consent at any time, which must be as easy as giving it (§6(4)).
What to do: Treat each right as a feature with an owner, an SLA, and a test — not a line in a privacy policy.
The timing reality — read this carefully
There is widespread, incorrect copy online asserting fixed deadlines like "access within 15 days, erasure within 30." Under the DPDP Rules, 2025, the only stated rights timer is for grievance redressal: a reasonable period not exceeding 90 days (Rule 14(3)). The Rules set no day-count for access, correction, or erasure.
That does not mean "whenever you like." You must respond within a reasonable, policy-defined time, and sector regulators or your own terms may impose tighter targets. But do not publish invented statutory deadlines.
What to do: Set explicit internal SLAs (a sensible default is to mirror the 90-day grievance ceiling or beat it), state them in your notice, and meet them consistently.
Right to access: what you must build
To honour an access request, you need to find all of a person's data across your systems and present it intelligibly, plus the purposes and the recipients it was shared with.
What to do: Maintain a data inventory keyed to a resolvable identifier so an access request becomes a query, not an archaeology project. Without inventory, access requests are unanswerable at scale.
Right to correction and erasure
Correction means updating inaccurate or misleading data and completing what is incomplete. Erasure means deleting data when the purpose is served or consent is withdrawn — unless retention is required for a legal obligation, in which case you erase what you can and document why the rest must stay.
What to do: Build deletion as a first-class operation that cascades across primary stores, caches, backups (on their cycle), and downstream processors — and record partial-fulfilment reasons for anything you must legally retain.
Right of grievance redressal
Every fiduciary must offer an effective grievance mechanism (§13) and publish a contact for it (§8(9); Rule 9), resolving complaints within 90 days (Rule 14(3)). This is distinct from the DPO that only SDFs need — see the Grievance Officer guide.
What to do: Route grievances into a tracked queue with status, owner, and a 90-day clock — never a shared inbox.
Identity verification: the gate before every right
You must fulfil rights for the right person — and not hand one user another's data. Before acting on any request, verify the requester is the Data Principal (or their nominee), proportionately to the sensitivity involved.
What to do: Define a verification step that starts the SLA clock only after identity is confirmed, and log the verification for audit.
What a request workflow looks like
| Stage | Action |
|---|---|
| Intake | Receive request via a published channel; capture type and identity claim |
| Verify | Confirm the requester is the Data Principal or nominee |
| Locate | Query the data inventory for all matching records |
| Action | Fulfil access, correction, or erasure; note legal-retention exceptions |
| Respond | Deliver the outcome in plain language within your SLA |
| Record | Log the full timeline to an immutable audit trail |
What to do: Instrument each stage so you can prove, after the fact, who requested what and when you responded. The audit trail is the compliance artifact.
How rights connect to the rest of your stack
Rights depend on the inventory you build for breach reporting, the consent records behind withdrawal, and — if you are a vendor — your duty to help customers fulfil their users' requests (DPDP for SaaS). They commence with the substantive Rules on 13 May 2027.
Why self-service beats a manual queue
It is tempting to handle rights requests by hand at first — a shared inbox, a spreadsheet, a person who runs database queries. That breaks the moment volume arrives, and it carries real risk: manual fulfilment is slow, error-prone, and easy to handle inconsistently across requesters.
Building rights as self-service product features flips the economics. An access request becomes a button that returns the requester's data; an erasure request becomes a workflow that cascades deletion across your stores and processors; a grievance becomes a tracked ticket with a 90-day clock. The user gets a faster answer, and you get a consistent, logged, auditable process rather than a pile of ad-hoc email threads.
There is a commercial upside too. Enterprise customers increasingly ask whether you can fulfil their users' rights, and a self-serve "export or delete this data subject" capability becomes a point you can demonstrate in a security review rather than promise.
What to do: Treat access, correction, erasure, and grievance as features with owners and SLAs from day one. Designing them in is far cheaper than retro-fitting them under the pressure of a regulator's deadline or a customer audit.
Frequently asked questions
Is there a 15-day or 30-day deadline to answer an access request?
No. Despite widespread copy claiming fixed deadlines, the only rights timer in the Rules is the 90-day grievance ceiling (Rule 14(3)). For access (§11) and correction or erasure (§12), respond within a reasonable, policy-defined time and set your own SLA.
Can we charge a fee to fulfil a rights request?
The Act frames rights as facilities the fiduciary must make available, and provides means for Data Principals to exercise them. [VERIFY: confirm whether any fee is permissible for specific request types with counsel.] Plan to fulfil routine requests without friction.
Do we have to verify the requester's identity first?
Yes. You must fulfil rights for the correct person and avoid disclosing one individual's data to another. Verify identity proportionately to sensitivity, and start your SLA clock only once identity is confirmed.
Does DPDP include a right to data portability?
No. Unlike GDPR, the DPDP Act does not grant an explicit right to data portability. Data Principals have access, correction, erasure, grievance, and nomination rights — see our DPDP vs GDPR comparison for the full contrast.
How Sammati helps
Sammati is a consent management platform (CMP) and Data Processor — not a registered Consent Manager — built around rights fulfilment:
- A unified request intake for access, correction, erasure, and grievance, with identity verification gating the SLA clock
- Configurable SLAs with the 90-day grievance ceiling (Rule 14(3)) enforced and reasonable targets for the rest
- Withdrawal recorded as an immutable, hash-chained artifact tied to the original consent
- A complete, exportable audit trail of every request and response
Check your DPDP compliance readiness
62 questions · 15 obligation areas · Instant results · No login