DSR Workflow: How Privacy Teams Handle Rights Requests
Last updated: 24 October 2026
A DSR workflow has seven stages, from intake to audit trail. The DPDP Act and Rules set no deadline for access, correction or erasure requests. Rule 14(3) of the DPDP Rules caps the grievance response period each Data Fiduciary and Consent Manager publishes at 90 days, and it isn't in force until 18 months after the Rules were published. PIB's 90-day figure for rights requests is government guidance only. GDPR allows one month, extendable by two further months, and the CCPA regulations allow 45 calendar days, extendable by 45.
Source: IQWorks | Last updated: October 2026
Intake is the visible part of a DSR workflow: a portal, verification and a status tracker. The harder work is finding the data, deciding what to withhold, chasing processors and later proving all of it.
DSR stands for data subject request. Under the DPDP Act it is a request by a Data Principal to exercise her rights. The workflow takes each request from receipt to a closed, evidenced file.
This guide is for DPOs and privacy operations leads at Indian enterprises with EU and Californian customers, and for CISOs who own verification and secure delivery. It covers rights by law, deadlines, the seven stages, routing, a RACI, metrics, failure points and a checklist.
What a DSR workflow has to handle: rights by law
DPDP rights sit in sections 11 to 14 of the Act (DPDP Act, 2023, MeitY), GDPR rights in Articles 15 to 22, handled under Article 12 (GDPR, EUR-Lex). CCPA rights follow the California AG's list (CCPA page, California AG, updated 28 Aug 2026).
| Right | DPDP Act | GDPR (Arts. 15 to 22) | CCPA |
|---|---|---|---|
| Access | s.11: summary of personal data and processing activities; identities of other Data Fiduciaries and Data Processors it was shared with, and a description of what was shared | Yes | Right to know |
| Correction | s.12: correction, completion and updating | Yes | Right to correct |
| Erasure | s.12: erasure, subject to s.12(3) | Yes | Right to delete |
| Portability | No such right | Yes | Part of the right to know: machine-readable copy where technically feasible (Civ. Code §1798.130(a)(3)(B)(iii)) |
| Objection | No general right | Yes | Not on the AG's list |
| Opt out of sale or sharing; limit use of sensitive personal information | No such rights | No rights by these names | Yes |
| Grievance redressal | s.13 | Art. 12(4): if you don't act, say they can complain to a supervisory authority | Not on the AG's list |
| Nomination | s.14 | No right by this name | No right by this name |
Sections 11 and 12 apply to processing for which the Data Principal "has previously given consent, including consent as referred to in clause (a) of section 7" (DPDP Act, 2023, s.11(1) and s.12(1)). Clause (a) of section 7 covers data she volunteered for a specified purpose without indicating she does not consent. No other clause of section 7 is named, so the text does not expressly extend these rights to the other legitimate uses, such as employment (s.7(i)). The s.13 grievance right has no such limit. That is narrower than GDPR, so record the processing basis each request touches.
The DPDP Act has no portability or general objection right, but Indian principals will still send GDPR-style requests, so set a policy in advance. Under s.11(2), the sharing disclosures in s.11(1)(b) and (c) do not apply to sharing with a Data Fiduciary authorised by law, on its written request, for preventing, detecting or investigating offences or cyber incidents, or prosecuting or punishing offences.
Response deadlines by jurisdiction
| Law | Clock | Extension | Notes |
|---|---|---|---|
| DPDP Act and Rules | None for s.11 and s.12. Grievances: your published period, 90 days at most (Rule 14(3), in force from 13 May 2027) | Not applicable | Publish your own SLA (see the PIB explainer below) |
| GDPR | Without undue delay, and within one month of receipt (Art. 12(3)) | Two further months where necessary | Tell the data subject about the extension, with reasons, within the first month |
| CCPA: know (including portability), delete, correct | Confirm receipt within 10 business days (11 CCR §7021(a)); respond within 45 calendar days | Another 45 days (90 in total) with notice | The 45 days run from receipt, not verification (§7021(b)) |
| CCPA: opt out of sale or sharing | As soon as feasibly possible, and within 15 business days at most | Not applicable | California AG, CCPA FAQ |
The DPDP Act and Rules set no deadline for access, correction or erasure requests. The only day count is in Rule 14(3), which requires every Data Fiduciary and Consent Manager to publish its own period for responding to grievances, a reasonable period not exceeding ninety days (DPDP Rules, 2025, G.S.R. 846(E), MeitY).
Rule 14(3) isn't in force yet. Rules 3, 5 to 16, 22 and 23 come into force eighteen months after the Rules were published in the Gazette dated 13 November 2025, that is, on 13 May 2027 (Rule 1(4)). The Act's provisions cited in this guide, other than the s.2 definitions already in force, apply from the same date, including s.6(6), ss.7, 8 and 10 to 17 and s.28 (G.S.R. 843(E), clause (c)).
The 90-day figure for rights requests comes from government guidance only. PIB's explainer, which cites no rule, says Data Fiduciaries "are required to address all requests related to access, correction, updating or erasure within a maximum of ninety days" (PIB, 17 Nov 2025). We recommend answering them within ninety days and publishing your own SLA. A Data Principal must exhaust your grievance route before going to the Data Protection Board (s.13(3)).
If you won't act on a GDPR request, Art. 12(4) requires you to say why within one month, and that the data subject can complain to a supervisory authority and seek a judicial remedy (GDPR Art. 12, EUR-Lex). CCPA timings are from 11 CCR §7021 (CPPA, effective 1 Jan 2026) and the California AG's CCPA FAQ.
The DSR workflow, stage by stage
1. Intake
From 13 May 2027, Rule 14(1) requires you to publish the means for making a data principal rights request, and any identifiers you need to identify her (DPDP Rules, 2025, Rule 14(1)). From the same date, Rule 9 requires every response to include the business contact details of your DPO, if applicable, or of a person who can answer questions about the processing.
Classify each request by type and jurisdiction, start the clock, and acknowledge it. CCPA requests to know, delete or correct need a confirmation within 10 business days that explains your verification process and when to expect a response (11 CCR §7021(a)). Check who is asking:
- Under s.14 and Rule 14(4), a Data Principal can nominate one or more individuals to exercise her rights if she dies or becomes incapacitated.
- Under s.2(j), "Data Principal" includes the parents or lawful guardian of a child, and the lawful guardian of a person with disability acting on her behalf.
- A Californian can use an authorised agent, including a registered business entity. You may require proof of the agent's signed permission, and may also require the consumer to verify directly (California AG, CCPA FAQ).
2. Identity verification
Rule 14(5) gives examples of identifiers a Data Fiduciary issues, such as a customer identification file number, enrolment ID, email address or mobile number. We recommend verifying against these rather than collecting new documents. The Rules prescribe no verification method.
GDPR Art. 12(6) allows a request for additional information where there are reasonable doubts about identity. Under the CCPA regulations, additional information collected to verify identity may be used only for verification, security or fraud prevention, and must be deleted as soon as practical after the request is processed, except as needed for the §7101 records (11 CCR §7060(d)).
Scale the check to what is being asked for. The CCPA regulations require a business to match the identifying information a consumer gives against personal information it already holds before asking for more, or to use a third-party verification service that complies with the section (11 CCR §7060(c)(1)). "Sensitive personal information shall warrant a more stringent verification process" (§7060(c)(3)(A)). A business may not require identity verification for a request to opt out of sale or sharing or a request to limit use of sensitive personal information, though it may ask for what it needs to complete the request (§7060(b)).
The Data Principal's duties not to impersonate anyone (s.15(b)) and to give only verifiably authentic information for correction or erasure (s.15(e)) belong in your rejection reason codes (DPDP Act, 2023, s.15).
3. Finding the data
Discovery is where enterprise workflows break. One person's data can sit in a CRM, a warehouse, support tickets, email archives, marketing tools, backups and undocumented systems. Manual searches can't be proved complete, and a static data map has the same gap: a new SaaS tool, a team's own database or an old archive stays invisible until someone adds it.
You need a current inventory of structured and unstructured stores, backups and processors. Section 11(1)(b) adds a sharing register listing every other Data Fiduciary and Data Processor that received the data, and what they received. A RoPA that stays audit-ready can hold it.
At IQWorks, the ComplyIQ DSR use case describes how DiscoverIQ "keeps a current map of where personal data resides, so discovery is not a per-request investigation", and how ClassifyIQ labels personal data "with AI that understands context, bringing unstructured documents and free text into scope". The hand-off from a verified request to a scoped discovery scan is walked through in closing the loop from data discovery to DSR fulfillment.
4. Review and exemptions
Erasure has exceptions. From 13 May 2027, under s.12(3) you must erase on request unless retention is necessary for the specified purpose or for compliance with law, and s.8(7) has the same law-required exception.
From 13 May 2027, Rule 8(3) requires a Data Fiduciary to retain personal data, associated traffic data and processing logs for at least one year from processing, for the Seventh Schedule purposes. Its illustrations say this applies "even if X deletes her account", and to data held by a Data Processor. The Act and Rules do not say expressly how this minimum interacts with an erasure request under s.12(3). Record what you kept and under which provision, and tell the Data Principal. Check this with your legal counsel for your setup.
Chapter III (the rights chapter) does not apply in the s.17(1) cases, such as enforcing a legal right or claim, or preventing, detecting, investigating or prosecuting offences. Send claimed exemptions to legal and record the clause. Redact third-party data from access responses and check legal holds before erasing.
5. Responding
Use a CISO-approved secure channel. A s.11 response carries the s.11(1)(a) summary and s.11(1)(b) sharing disclosures, and every response carries the Rule 9 contact and the grievance route. Answer electronic GDPR requests electronically where possible, unless asked otherwise (Art. 12(3)).
6. Following through with processors
From 13 May 2027, Section 8(1) keeps the Data Fiduciary responsible for compliance in processing done for it by its Data Processors. On erasure, s.8(7)(b) requires you, unless retention is necessary for compliance with law, to cause your Data Processor to erase the data you made available to it. Rule 8(3) separately requires the processor's copy and logs to be kept for at least one year from processing. On withdrawal of consent, s.6(6) requires you to cease, and cause your processors to cease, processing within a reasonable time. Instruct each processor in writing, get written confirmation, and log both. For the evidence side of withdrawal, see proving valid consent under India's DPDP Act.
7. The audit trail
At every stage, log who acted, what they did and when, which systems were searched, and what was decided and why. That shows who verified identity, where you searched and why a record was withheld.
The Data Protection Board has civil court powers to inspect "any data, book, document, register, books of account or any other document" (s.28(7)(c)). With one-year log retention required under Rule 6(1)(e) and Rule 8(3) from 13 May 2027, keep the DSR file at least that long.
One workflow, three laws: making jurisdiction a property of the request
A routing table keyed on jurisdiction picks the clock, scope and template.
| Request | DPDP Act | GDPR | CCPA |
|---|---|---|---|
| Access | s.11 template; our 90-day target | Access template; one month | Know template; 45 days |
| Correction | s.12(2); our 90-day target | Rectification; one month | Correct; 45 days |
| Erasure | s.12(3), s.8(7) processor step; our 90-day target | Erasure; one month | Delete; 45 days |
| Portability | Policy response (no right) | Portability; one month | Know template; 45 days |
| Opt out of sale or sharing | Policy response | Policy response | Opt-out; 15 business days at most |
| Grievance | s.13; published period up to 90 days | Complaint route in Art. 12(4) | Policy response |
Our DPDP targets follow the PIB explainer quoted above. When laws conflict:
- Use the strictest clock when a request spans laws.
- Include any item that any applicable law requires in the response.
- Write policy responses for rights missing from some laws, such as objection, opt-out of sale, and portability under the DPDP Act.
Who does what: a DSR RACI
| Role | Owns | Stages |
|---|---|---|
| DPO or grievance officer | Programme and grievance route; for a Significant Data Fiduciary, the grievance point of contact (s.10(2)(a)(iv)) | All; signs off refusals |
| Privacy operations | Runs each request, the clock and the file | 1, 5, 7 |
| System owners and IT | Search, extract, correct and erase in their systems | 3, 4 |
| CISO and security | Verification standard, secure delivery, access logs | 2, 5, 7 |
| Legal | Exemptions, legal holds, novel requests | 4 |
| Customer support | Intake and first acknowledgement | 1 |
| Processors | Act on instructions and confirm in writing | 6 |
Our DPDP RACI and DPO role and duties pages cover the wider programme.
What to automate and what to keep with people
Automate intake routing, identity checks, discovery, deadline tracking, processor confirmation chasing, response assembly and audit logging.
Leave exemptions, third-party redaction, refusals and partial refusals, and other legal calls to people.
On the ComplyIQ DSR use case page, ComplyIQ "runs identity verification proportionate to the sensitivity of the data being requested" and "every decision and action is recorded to a defensible, timestamped audit trail."
How to tell the workflow is working: metrics
Track against your own baseline:
- Time to acknowledge and to verify, from receipt.
- Time to close against the clock for that request's jurisdiction.
- Share of requests extended, and share refused with reason codes.
- Systems searched per request (discovery coverage).
- Processor confirmation lag, from instruction to written confirmation.
- Repeat requests and grievances escalated to the Board.
Where DSR workflows usually break
Automation speeds up intake, and the stages after it still fail: a workflow built on an incomplete data map produces incomplete responses faster. Four failure points recur:
- Discovery is incomplete. A missed system makes the response wrong, and without a sharing register no s.11(1)(b) answer is complete.
- Identity checks are off balance. Weak checks risk wrong disclosures; heavy ones collect more data and cause delay.
- Unstructured data is missed. Schema-based search cannot see personal data in email archives, shared drives, tickets, PDFs and scanned documents, and pattern matching struggles with free text (more on this in why regex alone misses sensitive data).
- Deadlines conflict. One request can face a one-month GDPR clock and a 45-day CCPA clock. Without the strictest-clock rule, analysts miss one or apply the wrong scope.
Two of the four, incomplete discovery and missed unstructured data, come back to the data map. Each failure has a quick fix and a fix at the root:
| Failure | Quick fix | Fix at the root |
|---|---|---|
| Incomplete responses | Add connectors by hand | Continuous discovery that includes undocumented systems |
| Missed unstructured data | More regex rules | Classification that reads context |
| Missed deadlines | More reminders | Clock and scope set by jurisdiction |
| Verification friction | Loosen checks | Checks scaled to the sensitivity of the data |
DSR workflow checklist
- Publish the means for making requests and the identifiers you need (Rule 14(1)).
- Publish a grievance response period of no more than ninety days (Rule 14(3)) and an SLA for s.11 and s.12 requests.
- Put the Rule 9 contact details in every response template.
- Record jurisdiction and processing basis; verify against identifiers you already issue.
- Scale verification to the sensitivity of the data (11 CCR §7060(c)(3)(A)).
- Don't require identity verification for CCPA opt-outs or requests to limit (11 CCR §7060(b)).
- Confirm CCPA requests to know, delete or correct within 10 business days (11 CCR §7021(a)).
- Accept nominees, parents and lawful guardians (s.14, s.2(j)) and CCPA authorised agents.
- Keep a current inventory, unstructured stores included, and a s.11(1)(b) sharing register.
- Check s.12(3), s.8(7), Rule 8(3) and legal holds before erasing.
- Get written confirmation from every processor (s.8(7)(b), s.6(6)).
- Log every stage, and keep logs at least one year (Rules 6(1)(e), 8(3)).
- Apply the strictest clock to multi-law requests; route CCPA portability to the Know template.
Related reading: one login and one data layer across a DPO's tools.
Key Takeaways
- Make processor follow-through its own stage.
- The DPDP Act and Rules set no deadline for access, correction or erasure. Rule 14(3) caps the published grievance period at 90 days from 13 May 2027.
- GDPR gives one month plus up to two more; CCPA gives 45 days plus 45.
- Erasure has to respect s.12(3), s.8(7) and Rule 8(3).
- Fix the data map first, because discovery and the sharing register depend on it.
Frequently asked questions
How long do we have to respond to a data principal's request under the DPDP Act?
The DPDP Act and Rules set no deadline for access, correction or erasure requests. Rule 14(3) caps the grievance response period each Data Fiduciary and Consent Manager publishes at 90 days, and that rule isn't in force until 13 May 2027, 18 months after the Rules were published. We recommend answering within ninety days, as the PIB explainer suggests, and publishing an SLA.
Does the DPDP Act include a right to data portability?
No. The rights are access to information (s.11), correction and erasure (s.12), grievance redressal (s.13) and nomination (s.14). When an Indian principal asks for portability, explain that the Act does not provide it, offer the s.11 summary, and include your Rule 9 contact and grievance route.
Can we refuse an erasure request under DPDP?
In part. Section 12(3) allows retention necessary for the specified purpose or for compliance with law, and s.8(7) has the same law-required exception. From 13 May 2027, Rule 8(3) also requires personal data, traffic data and processing logs to be kept for at least one year from processing. Explain what you kept and under which provision.
Who can make a request on behalf of a Data Principal?
A nominee, if the Data Principal dies or becomes incapacitated (s.14; Rule 14(4) allows one or more nominees). Parents or lawful guardians of a child, and the lawful guardian of a person with disability, count as the Data Principal (s.2(j)). Under the CCPA, authorised agents can act; you may require proof of signed permission and may also require the consumer to verify directly.
Do we need separate workflows for DPDP, GDPR and CCPA?
No. Build one workflow where jurisdiction is a request attribute that sets the clock, scope and response format. Parallel workflows multiply errors. Where a request falls under several laws, apply the strictest clock (one month under GDPR Art. 12(3), 45 days under 11 CCR §7021(b)) and include every disclosure any of them requires.
What has to be in the response to a DPDP access request?
A summary of the personal data being processed and the processing activities (s.11(1)(a)), and the identities of all other Data Fiduciaries and Data Processors you shared it with, plus a description of what was shared (s.11(1)(b)), subject to the carve-out in s.11(2). Rule 9 adds your DPO's or responsible person's business contact details.
Do processors have to act on DSRs?
The obligation sits with you, because from 13 May 2027 s.8(1) keeps the Data Fiduciary responsible for processing done on its behalf. Section 8(7)(b) requires you to make processors erase, and s.6(6) to make them cease processing after consent is withdrawn. Instruct each processor in writing, ask for written confirmation, and log both.
Why do DSR workflows break even when intake is automated?
One cause is the data map. If discovery misses a system or an unstructured store, an automated workflow returns an incomplete response sooner, and s.11(1)(b) also needs a complete sharing register. Fix the data map, scale verification to the data (11 CCR §7060(c)(3)(A)), and let jurisdiction set each clock.
The short version
Publish how to make requests. Record jurisdiction and processing basis at intake, verify against identifiers you already issue, and search an inventory with a sharing register. Check exemptions and retention before erasing, have processors confirm in writing, and log every step for a year or more, on the strictest applicable clock. If you are choosing software, our roundup of DSR workflow automation platforms compares the options, and the DSR implementation guide covers rollout.
If you are moving rights requests into one tracked process, ComplyIQ is the IQWorks product for it. Its DSR automation solution page says: "The queue shows each request's type, status, owner and age, and flags anything due soon or overdue." To see how that would work with your own request types and deadlines, contact the IQWorks team.
Our verdict
29 ratings, from Customer Success Research.
Free DPDP Implementation Workshop
A 90-minute session for your team, on-site or remote: the DPDP Act applied to your organization, a 90-day roadmap, and the top five actions per department.
Book the workshop
