How to Build a DSR Portal for DPDP Requests

The delete button worked. The account disappeared from the application, the support ticket closed and the customer received a confirmation. A week later, the marketing system sent them a renewal offer.

That is an illustrative failure, but it captures the central engineering problem: a privacy request crosses systems, teams and vendors. A form can collect it. The rest of the service has to carry it out.

A DSR portal is a way to receive and manage requests about personal data. DPDP uses the term Data Principal, so the legal scope comes from the person's rights under Sections 11 to 14 of the Act, alongside consent withdrawal under Section 6. The Act does not prescribe a product called a “DSR portal” or require a particular software architecture.

This guide sets out a practical design for teams building that service, from intake to evidence of completion.

Updated 3 October 2026. The main rights provisions and relevant Rules are scheduled to commence in May 2027 under the government's commencement notification. The engineering patterns below are recommendations unless identified as legal requirements.

Establish the legal scope before designing the queue

Sections 11 to 14 of the DPDP Act cover access, correction and erasure, grievances, and nomination. They do not all ask your system to do the same thing.

Sections 11 and 12 are framed around data for which the person previously gave consent, including the reference to Section 7(a). Build a review route for scope and exceptions rather than assuming every request authorises an unrestricted export or deletion.

Rule 14 requires the means of exercising rights and any required identifying particulars to be prominently published on the website or app. Rule 9 also requires the appropriate business contact information, including in responses to rights communications.

A dedicated portal can make this easier to operate. The Rules do not prescribe a portal UI. If you accept requests through email or another published channel, the underlying handling and records still need to work.

The 90-day limit belongs to grievance redressal

Rule 14(3) provides for a published grievance-response period that is reasonable and does not exceed 90 days. It is not a blanket 90-day deadline for every access, correction, erasure or nomination request.

Keep the statutory requirement separate from the operational targets your organisation sets. Your request record should contain the received time, the applicable deadline or published commitment, its basis and any internal target. A grievance's receipt date matters under Section 13(2). Do not quietly start its clock later because verification or assignment took time.

For other request types, set documented targets appropriate to the applicable requirements and the service. A target is useful only if owners can see when it is approaching and understand what remains unfinished.

A support complaint can also become a privacy grievance. Preserve the original message and timing when it is reclassified instead of creating a fresh ticket that loses the history.

Build the data map before the connectors

Choose a representative person and identify the systems that hold their data. Include current and former account identifiers, support records, billing systems, analytics stores, warehouses and processors. A list of production database tables is rarely the whole map.

For each system, record:

• How the individual is identified and how identifiers change over time.
• Which data categories and purposes are involved.
• Who owns the system and can approve an action.
• Whether retrieval, correction and deletion have APIs or require manual work.
• Which retention requirements or holds may prevent an action.
• What counts as evidence that the action completed.

Our data-audit guide covers discovery. For the portal, the output needs to be executable: “CRM, customer ID, support operations owner, deletion ticket, confirmation required” is more useful than “sales data.”

Watch for identity collisions. A shared family phone number or a reassigned work email may point to more than one person. Matching an identifier should locate candidates for review, not trigger an automatic export of everything associated with it.

Keep intake easy and disclosure difficult to abuse

Accept enough information to find and understand the request. Avoid making identity-document uploads the default for every visitor.

For a signed-in user, a recent authenticated session can be part of verification. High-impact actions may justify re-authentication or another check. For a former customer, verification through a previously established contact channel may work, with a reviewed alternative if they have lost access.

An OTP establishes control of the channel at that moment. Consider what happens with a compromised email account, a recycled mobile number or a shared inbox before treating it as conclusive identity evidence.

For nominee or guardian requests, use a separate review path for identity, authority and the relevant circumstances. Restrict access to supporting documents and avoid retaining more of them than the assessment requires.

On the public form:

• Acknowledge receipt with a reference that does not expose personal information.
• Avoid confirming whether an email address has an account before appropriate verification.
• Apply proportionate abuse controls and offer an accessible alternative when they block a legitimate person.
• Explain what further information is needed and why.
• Keep attachments private and separate from ordinary support logs.

These controls protect both the requester and the people whose information might be disclosed by mistake.

Separate the request from the work needed to fulfil it

One request may create ten tasks. Giving each task its own status makes partial completion visible.

A useful model has three layers:

Store references to sensitive evidence where possible. Copying a complete identity document into every task or log line creates another set of personal data to secure and retain.

For example, an erasure request might contain these tasks:

This is an example of task design, not a legal retention schedule. Establish the applicable requirements before assigning the action.

Erasure needs a decision before a delete operation

Section 12(3) contains the erasure right and its retention exceptions. Section 8(7) addresses erasure following withdrawal or the end of a purpose, and requires the fiduciary to cause its processor to erase the data made available to it, subject to the legal-retention exception.

There is no Section 12(4) in the Act. Do not build a supposed universal “cascade to every other fiduciary” around that reference. Distinguish processors acting on your behalf from independent fiduciaries with their own purposes and obligations.

The final Rules also matter. Rule 8(3) requires a minimum one-year retention period for the covered personal data, associated traffic data and processing logs, for the Seventh Schedule purposes. Rule 6 contains a security-related retention requirement. Other applicable law may require longer retention.

Your decision engine therefore needs to answer three questions for each relevant record:

1. Can and should the active processing stop now?
2. Must some information be retained, under which provision and for what purpose?
3. When and how will the retained information be reviewed or erased?

A retained invoice should not remain available for unrelated marketing merely because finance must keep it. Separate the retention decision from permissions to continue using the data.

For backups, document the actual limits and controls. A restore-suppression mechanism can help prevent erased records being reintroduced into active systems. It does not, by itself, establish a legal exemption for keeping copies indefinitely. Review the backup retention period and technical options against the applicable requirements.

Make retries safe and failures visible

A processor returning “request accepted” has not necessarily completed deletion. Model acceptance and completion separately. If the processor provides asynchronous status, track it. If the process is manual, assign an owner and capture a meaningful confirmation.

Use an idempotency key for each system action so a retry does not create a second destructive operation or contradictory evidence. Keep failed tasks open with the cause, next attempt and escalation owner. A successful main-database task must not automatically close the whole request.

A new system added after the request was submitted creates another edge case. Record which systems were assessed and reconcile the task set before closure. Otherwise the customer can disappear from yesterday's map while remaining in today's integration.

Your processor agreements should support this operating model: contacts, assistance, response expectations, evidence and escalation. Repeated follow-up emails are evidence of attempts, not proof that deletion happened.

Deliver an answer the person can understand

For access, Section 11 calls for a summary and specified information about processing and sharing. An unfiltered database dump can expose other people, internal secrets or confusing technical fields without answering the request.

Prepare a readable response, apply relevant exceptions and review third-party information. Send sensitive material through a suitable protected channel. If using a download link, make it short-lived and access-controlled; avoid placing the export in a public bucket or attaching it indiscriminately to a support email.

For a partially fulfilled erasure request, explain what was erased, what is retained and the reason for retention at a level the person can understand. Include the required business contact information and the relevant grievance route. Do not label the request “fully deleted” when a required processor task is still pending.

Retain proportionate evidence of the response and its delivery. Set the retention period using applicable requirements and documented need. The Act does not prescribe a universal three-year retention period for every DSR case file.

Test the awkward cases before launch

A clean demo with one user and one database tells you little about how the process will behave under pressure. Include these scenarios in acceptance testing:

Start with a small set of real systems and a complete path through them. A manual task with an owner and verifiable evidence can be a sound first implementation. An automated connector that silently misses half the records cannot provide the same assurance.

Frequently asked questions

The main DPDP business duties discussed below are scheduled to commence in May 2027 under the government's commencement notification. Existing sectoral and cybersecurity requirements operate on their own timelines.

Does DPDP require a dedicated Data Principal request portal?

The DPDP Rules require prominently published means for exercising rights; they do not prescribe a dedicated portal interface. A published email route or another channel can be part of the arrangement if requests are actually received, verified, handled and answered. A portal is useful when it improves ownership and evidence across systems. The important test is whether the process works, including for people who no longer have an account.

Sources: DPDP Rules, Rules 9 and 14.

Do all DPDP access and erasure requests have a 90-day deadline?

The 90-day limit in Rule 14(3) applies to the published period for responding to grievances. It is not a blanket deadline for every access, correction, erasure or nomination request. The grievance period must also be reasonable, so 90 days is a ceiling rather than an automatic target. Record the applicable requirement, published commitment and internal target separately for each request type.

Sources: DPDP Rules, Rule 14(3); DPDP Act, Section 13.

Does the DPDP access right require a download of every record about the person?

Section 11 provides access to a summary of personal data being processed and the processing activities, information about sharing subject to the statutory exception, and any other information prescribed. It should not be described as a GDPR-style right to download every underlying record. Design the response around the applicable DPDP requirements, review it for other people's information, and distinguish optional export features from the statutory access right.

Sources: DPDP Act, Section 11.

Should every requester have to upload an identity document?

An identity-document upload should not be the automatic design choice for every request. Rule 14 addresses the particulars needed to identify the person, without prescribing one universal document upload. A recent authenticated session or a check through an established contact channel may be suitable in some cases; sensitive disclosures, shared identifiers and guardian requests need closer review. Choose verification proportionate to the request and protect the supporting information.

Sources: DPDP Rules, Rule 14.

How should the portal handle an erasure request when some records must be retained?

An erasure request needs a decision for each relevant record category. Sections 8(7) and 12 recognise necessary retention for applicable legal requirements, and the Rules add retention duties of their own. Track what can be erased, what must be retained, the reason and the responsible owner. Explain the partial outcome to the requester and restrict retained records to their justified uses. One retained category should not automatically block the whole request.

Sources: DPDP Act, Sections 8(7) and 12; DPDP Rules, Rule 8.

Does a DPDP deletion request require every company that received the data to delete it?

Under Section 8(7), the fiduciary's erasure duty includes causing its processor to erase personal data made available for processing, subject to necessary legal retention. A recipient acting as an independent fiduciary needs its own assessment. Do not treat every recipient as a processor or assume one request automatically erases every independent company's records. Map the roles, send the appropriate instructions and record confirmations or justified exceptions.

Sources: DPDP Act, Sections 2(i), 2(k) and 8(7).

Choosing what to build and what to buy

Compare products and an internal build using your hardest representative request. Ask each option to show how it handles identity matching, retention decisions, processor delays, response review and an auditable export of the case history.

Request volume matters, but system diversity and the ability to maintain integrations often matter more. Your team will still need to know where data lives and what legal decisions apply, even if a platform manages the case process.

ComplyZero is a DPDP compliance platform for Indian businesses, built by data protection lawyers and cybersecurity experts. Book a walkthrough to discuss how your request process can connect to owners and evidence. Bring one representative data flow: it will make the discussion much more concrete than a list of portal features.