Intake, identity verification, routing, fulfilment and response for every right the DPDP Act grants — access, correction and erasure, grievance redressal, and nomination — each closing with a case file you could hand to the Data Protection Board. Never metered, never charged by volume, on any plan.
Get the list right and half the confusion in this market disappears (DPDP Act 2023, Sections 11–14, plus s.6(4)).
| Provision | The right |
|---|---|
| Section 11 | Access to information about personal data. A summary of the personal data being processed and the processing activities undertaken; the identities of all other Data Fiduciaries and Data Processors with whom it has been shared, with a description of what was shared; and any other prescribed information. |
| Section 12 | Correction, completion, updating and erasure. On a correction request, the Fiduciary shall correct inaccurate or misleading data, complete incomplete data, and update it. On an erasure request, it shall erase — unless retention is necessary for the specified purpose or for compliance with any law in force. |
| Section 13 | Grievance redressal. Readily available means of raising a grievance about any act or omission regarding the Fiduciary's obligations or the exercise of her rights. She must exhaust this before approaching the Board. |
| Section 14 | Nomination. The right to nominate one or more individuals to exercise her rights in the event of her death or incapacity. |
| Section 6(4) | Withdrawal of consent, at any time, with ease comparable to that with which it was given. |
Consiva handles intake, verification, routing, fulfilment and evidence for all of these.
Worth stating explicitly, because several platforms in this market offer a “portability request” type and it is a mistake with consequences.
The word does not appear in the DPDP Act. A data portability right existed in the 2019 Personal Data Protection Bill and was dropped from the legislation that was eventually passed. It is a GDPR Article 20 concept.
Why it matters practically: if your rights intake form offers portability, you have created an expectation you have no statutory basis to fulfil and no statutory framework to bound. A Data Principal who requests it and is refused now has a grievance. A vendor who built the option into your workflow has handed you an obligation the law did not.
Section 11 gives a right to a summary of personal data and processing activities. That is a different thing from a machine-readable export of the data itself, and Consiva's access workflow is built to Section 11 as written.
This is the single most commonly misstated thing in Indian privacy software, and we would rather be precise than reassuring.
For grievances under Section 13, there is a prescribed period. Rule 14(3) requires every Data Fiduciary to prominently publish its grievance response period, which must not exceed ninety days, and to implement appropriate technical and organisational measures to actually respond within it. The ninety days is a ceiling on the period you publish, not a default you get to assume.
For access, correction, erasure and nomination, DPDP prescribes no response deadline at all. Neither the Act nor the Rules set one. Rule 14(1) requires you to publish the means of making a request and the identifiers needed to authenticate the requester. That is the extent of it.
So where does the “30 days” everyone quotes come from? GDPR Article 12(3). It is not a DPDP figure.
If a vendor shows you a hardcoded 30-day countdown and calls it the DPDP clock, ask which rule. There isn't one.
Rights requests are unlimited on every Consiva plan, including Free. They are never charged by volume, and there is no overage. This is a permanent commercial position, not a launch promotion.
The reasoning is statutory rather than generous. Sections 11 to 14 create these rights unconditionally — there is no volume qualifier, no proportionality carve-out, and no exemption based on cost to the Fiduciary. Section 8(10) separately obliges the Data Fiduciary to establish an effective grievance-redressal mechanism. Nothing in either is contingent on what you pay a vendor.
So a platform that meters rights requests creates a structural conflict: at the moment your request volume spikes — which is exactly when a public incident, a press story or a viral complaint has just made rights fulfilment urgent — your tooling either stops working or starts billing you. Neither is a position a compliance function should be put in by its own software.
| Free | Pro | Enterprise | |
|---|---|---|---|
| Rights requests accepted | Unlimited | Unlimited | Unlimited |
| Public intake and identity verification | ● | ● | ● |
| Case file and export | ● | ● | ● |
| Automated routing and escalation | — | ● | ● |
| Service SLA timers and alerts | — | ● | ● |
| Custom rights types and system-of-record integration | — | — | ● |
You can handle a thousand requests on the free plan. You will do more of the work by hand.
From a public form to a closed, defensible case file — shown here as a workflow before the detail below.
This is the case list. Each row is one request: a reference, the right being exercised with its section, the verified requester, the named owner, and the clock. Note there are two clocks and they are different things — a service SLA you set for access, correction, erasure and nomination, where DPDP prescribes no deadline, and your published grievance period for Section 13 requests, which Rule 14(3) caps at ninety days. Cases escalate before either runs out. Opening a case shows the verification record, the systems searched, the action taken, and the response as it was sent — which together are the file you would produce if the request were later disputed.
On erasure specifically. Section 12(3) requires erasure on request unless retention is necessary for the specified purpose or for compliance with any law in force. Consiva records a refusal on that basis as an explicit, reasoned entry in the case file rather than leaving the request silently unfulfilled — which is the difference between a defensible decision and an apparent failure.
Per case: the request as submitted · the identity verification record and method · the systems searched · what was found · the action taken · any refusal with the statutory provision relied on · the response document as sent, including Rule 9 contact details · every state change with a timestamp and an actor.
Per export: a case file as PDF, suitable for attaching to a Board response or handing to an auditor.
Aggregate: volume by right, by month; time to close against your service SLA and your published grievance period, separately; escalation and overdue history.
What Consiva cannot see, stated plainly. Consiva searches the systems it is connected to. Where personal data sits in a system with no integration, the case file records that a manual search was assigned to a named owner and what that owner reported — an attested manual step, which is the majority path in most Indian mid-market estates. It is recorded as attested rather than verified, because that is what it is. Exports say so.
A healthcare services group receives an erasure request from a former patient. Support forwards it to legal, legal asks IT what is held, IT asks which systems, and nine days pass before anyone establishes that her records exist in three places. Nobody has told her the request was received.
With rights management in place, the same request arrives through the public form, is verified by OTP within minutes, and creates a case with the DPO as owner and a clock running. The search identifies three systems. Two erasures execute. The third — a set of clinical records — is refused, with the specific retention obligation recorded as the basis, and the refusal is explained to her in the response along with the Rule 9 contact details for follow-up. Total elapsed time, four days. If she later files a grievance or approaches the Board, the file shows a verified requester, a reasoned partial refusal citing a statutory provision, and a documented response.
The point is not the four days. It is that the refusal is defensible because it was reasoned and recorded at the time, rather than reconstructed afterwards.
Illustrative. Not based on a named Consiva customer.
Rights handling is where teams without a dedicated privacy function feel the gap most sharply, because requests arrive unpredictably and each one has a clock. This is the strongest fit for an operated engagement in the whole platform.
Privacy Point-of-Contact — Consiva staffs the Rule 9 contact role: the published person who answers a Data Principal's questions about processing, and whose details appear in every response.
Managed Privacy Officer — Consiva operates the queue day to day: intake triage, verification, coordinating searches with your systems owners, drafting responses, and keeping the evidence current.
Your team retains all decision authority, including every refusal. Consiva does not make legal determinations on your behalf.
The operational handling of requests from individuals exercising their rights under the DPDP Act: intake, identity verification, routing to an owner, searching the systems that hold their data, executing or reasonably refusing the request, responding, and keeping evidence of the whole sequence. The rights are access to information (Section 11), correction and erasure (Section 12), grievance redressal (Section 13) and nomination (Section 14), plus withdrawal of consent under Section 6(4).
It depends which right, and this is widely misreported. For grievances under Section 13, Rule 14(3) requires you to prominently publish your response period and caps it at ninety days. For access, correction, erasure and nomination, DPDP prescribes no response deadline at all — neither the Act nor the Rules set one. The frequently quoted "30 days" is GDPR Article 12(3), not DPDP. We recommend adopting a service SLA anyway, and labelling it as a service commitment rather than a statutory period.
No. The word does not appear anywhere in the Act. Data portability was in the 2019 Personal Data Protection Bill and was dropped from the version that passed; it is a GDPR Article 20 right. Section 11 gives a right to a summary of the personal data being processed and the processing activities undertaken, which is a different obligation. Be cautious of any platform offering a DPDP portability request type — it creates an expectation with no statutory basis and no statutory bounds.
Public intake that does not require an account; identity verification calibrated to the consequence of the request type; a named owner per case; separate tracking of the service SLA and the published grievance period; escalation before a deadline rather than after; automatic inclusion of Rule 9 contact details in every response; the ability to record a reasoned refusal against a statutory provision; and an exportable case file. And it should never meter request volume.
Because the failure mode is silent. A request in a shared inbox has no clock, no owner and no verification, and the first anyone hears of the problem is a grievance or a Board complaint. The specific things a spreadsheet cannot give you: proof the requester was who she claimed to be, a record of which systems were actually searched, and a reasoned refusal recorded at the time it was made rather than reconstructed under pressure months later.
No. Rights requests are unlimited on every plan including Free, are never charged by volume, and have no overage. Sections 11 to 14 create these rights unconditionally and Section 8(10) requires an effective grievance mechanism; none of that is contingent on what you pay a software vendor. A platform that meters rights requests bills you hardest precisely when fulfilment matters most.
Public intake, OTP verification, and a case file for every request — live in minutes.