Building a DPDP-Compliant DSR Portal: Requirements and Implementation

If you have ever searched your codebase for every table that stores a user's email address and wondered how you would pull all of that into a single response on demand, you already understand the core engineering problem behind a DSR portal. The legal name is "Data Subject Request" (or, in DPDP terminology, a Data Principal rights request). The engineering reality is: you need a system that accepts an incoming request, verifies who is asking, queries half a dozen internal services, assembles a coherent response, and logs every step for an auditor who might ask about it eighteen months from now.

The DPDP Act 2023 (full text) does not use the phrase "DSR portal." What it does is grant Data Principals four distinct rights under Sections 11 through 14, and the DPDP Rules 2025 add a 90-day response deadline plus a requirement to provide a publicly accessible mechanism for exercising those rights. If you are the person tasked with building that mechanism, this post is for you.

Key Takeaways

• The DPDP Act 2023 requires Data Fiduciaries to provide a publicly accessible mechanism for Data Principals to exercise four rights: access (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), and nomination (Section 14).
• Every request must be resolved within 90 days under the DPDP Rules 2025. There is no complexity-based extension.
• Identity verification must be robust enough to prevent unauthorized disclosure, but proportionate enough not to deter legitimate requests.
• Erasure requests under Section 12(4) cascade to every downstream Data Processor and Data Fiduciary that received the data. Your portal needs to trigger and track that cascade.
• A complete audit trail of every request, action, and response is not optional; it is the evidence that saves you when the Data Protection Board comes asking.

What Requests Must a DSR Portal Handle?

Before writing a single line of code, you need to understand the four request types your portal must support. Each maps to a specific section of the DPDP Act 2023, and each has different data retrieval and workflow requirements.

For a full legal breakdown of these rights, Supriya covers them section by section in our guide to Data Principal rights under DPDP. What follows is the engineering view: what each right means for your system architecture.

Request Type	DPDP Act Section	What the System Must Do	Typical Complexity
Access	Section 11	Query all data stores for the requester's personal data, aggregate into a summary, return in digital form	Medium to High
Correction / Completion / Update	Section 12(1)-(2)	Locate the specific data point, validate the correction, update across all systems including downstream processors	Medium
Erasure	Section 12(3)-(4)	Delete personal data from all systems, trigger cascading deletion at processors, verify completion	High
Grievance	Section 13	Accept a complaint, route to the designated grievance officer, track resolution, log outcome	Low to Medium
Nomination	Section 14	Register a nominee's identity and contact details, verify nominee claims when activated, transfer rights	Low (registration) / Medium (activation)

A common mistake I have seen in early implementations: teams build the access request flow first because it feels like the "main" feature, then bolt on erasure as an afterthought. Erasure is the hardest to implement correctly because of the cascading obligation under Section 12(4). If you share personal data with three payment processors, two analytics providers, and a CRM, your portal needs to trigger deletion at all five, confirm completion from each, and log that confirmation. Build the erasure pipeline early. It will influence your entire data architecture.

How Should You Verify the Identity of Requesters?

Identity verification is where many DSR implementations either create a security hole or create so much friction that legitimate users give up. Neither outcome is acceptable.

The DPDP Rules 2025 specify that Data Principals submit requests using an identifier previously provided by the Data Fiduciary. In practice, this means the email address, phone number, or account ID they used when they first gave you their data.

Here is the verification approach I recommend, calibrated by risk level:

Authenticated Users (Logged-In Sessions)

If the Data Principal is logged into your application when they submit the request, verification is straightforward. The session token confirms their identity. Your portal should accept the request directly from within the user's account settings.

This is the path of least friction and highest confidence. Build it first.

Unauthenticated Requests (No Active Session)

For requests submitted through a public-facing form, such as an ex-customer who deleted their account but wants to know what data you still hold, you need a verification step:

1. The requester provides their registered identifier (email or phone number).
2. Your system sends a one-time verification code to that contact method.
3. The requester confirms the code to prove ownership of the identifier.
4. The request is accepted and enters your processing queue.

This is the same pattern you already use for password resets. The infrastructure exists. Do not overcomplicate it with government ID uploads or notarised documents unless you process high-sensitivity data categories (health, financial, biometric) where the risk of unauthorized disclosure justifies the additional friction.

Nominee Verification (Section 14 Activation)

When a nominee claims rights on behalf of a deceased or incapacitated Data Principal, verification is necessarily more involved. The nominee must provide:

• Proof of their own identity
• Evidence of the nomination (if you have a recorded nomination on file)
• Supporting documentation (death certificate, medical certificate of incapacity)

This is a manual review workflow. Do not try to automate it fully. Route nominee activation requests to a designated reviewer with appropriate training, and set an internal SLA that still leaves room within the 90-day outer limit.

What Does the System Architecture Look Like?

A DSR portal has four layers, regardless of whether you build it in-house or adopt a platform. Understanding each layer helps you estimate scope and avoid the gaps that cause compliance failures later.

Layer 1: Intake

This is the public-facing interface. At minimum, it needs:

• A request form accessible from your website or app (the DPDP Rules 2025 require this to be publicly available)
• Request type selection (access, correction, erasure, grievance, nomination)
• Identifier input (email, phone, account ID)
• Identity verification flow (OTP or session-based, as described above)
• Acknowledgement with a unique request reference number

Two implementation details that matter more than they seem. First, generate the reference number immediately upon submission, before verification completes. The Data Principal needs a receipt. Second, send an automated acknowledgement via the same channel they used to submit. If they emailed, acknowledge by email. If they used an in-app form, acknowledge in-app and via email.

Layer 2: Orchestration

Once a request is verified and accepted, the orchestration layer takes over. This is where most of the engineering complexity lives.

For an access request, the orchestrator must:

1. Query every data store that contains personal data indexed by the requester's identifier
2. Aggregate the results into a coherent summary (not raw database dumps)
3. Apply any legal exceptions (Section 11(2) carves out data shared with law enforcement)
4. Package the summary in a digital format for delivery

For a correction request, it must:

1. Locate the specific data point across all systems
2. Validate the correction (is the new value well-formed? does it conflict with any integrity constraints?)
3. Apply the update to the primary data store
4. Propagate the update to all downstream systems and processors
5. Confirm propagation

For an erasure request, it must:

1. Identify all instances of the requester's personal data across every system
2. Check for legal retention requirements that override the erasure right (tax records, regulatory mandates)
3. Delete data where no retention override applies
4. Trigger deletion at every downstream Data Processor via API or notification
5. Collect deletion confirmations from each processor
6. Handle partial failures (what happens if one processor's API is down?)

If you built a proper data audit and flow map during your compliance setup, you already know which systems hold personal data and which processors receive it. That map is the input to your orchestration layer.

Layer 3: SLA Tracking

The DPDP Rules 2025 set a hard ceiling of 90 days for all request types. Your system needs:

• Per-request deadline calculation: Start the clock at the timestamp of verified submission, compute the 90-day deadline, and store it alongside the request record.
• Status tracking: Every request moves through states: Received → Verified → In Progress → Pending Processor Response → Completed → Closed. Each transition is timestamped.
• Escalation alerts: If a request hits day 60 without resolution, someone needs to know. If it hits day 80, leadership needs to know. These thresholds are configurable, but they must exist.
• Dashboard visibility: The compliance lead needs a single view showing all open requests, their current status, and days remaining. You also need historical views for quarterly reporting and audit preparation.

Ninety days sounds generous until you consider that an erasure request involving five processors in different time zones, one of whom takes two weeks to respond to deletion API calls, can eat through that runway faster than you expect. I have seen it happen.

Layer 4: Audit Trail

This is not a logging afterthought. The audit trail is the compliance artefact that matters most when the Data Protection Board of India examines your DSR handling.

For every request, log:

• Submission details: Timestamp, channel, identifier used, request type, verbatim request content
• Verification outcome: Method used, verification timestamp, success/failure
• Processing actions: Every query executed, every system touched, every update or deletion performed
• Processor interactions: Every outbound deletion or correction request sent to a processor, the processor's response, and the timestamp of confirmation
• Response delivery: What was sent to the Data Principal, when, and through which channel
• Resolution: Final outcome (fulfilled, partially fulfilled, denied with reason), closure timestamp

Store audit records for at least three years beyond the resolution date. The DPDP Act does not specify a retention period for DSR records, but when the Board adjudicates a complaint under Section 13, they will ask for your records. "We only keep logs for six months" is not a defensible position.

What Does the 90-Day SLA Mean in Practice?

The 90-day response window under the DPDP Rules 2025 applies uniformly across all request types. There is no provision for extending it based on complexity, unlike GDPR which gives you 30 days plus a 60-day extension for complex cases.

Here is what that means for your engineering team:

Request Type	Realistic Processing Time (Well-Instrumented System)	Realistic Processing Time (Manual Process)	Buffer Days
Access (simple, single system)	1-3 days	5-10 days	80+
Access (complex, multi-system)	5-15 days	20-40 days	50-70
Correction	1-2 days	3-7 days	83+
Erasure (single system, no processors)	1-3 days	5-10 days	80+
Erasure (multi-system, multiple processors)	10-30 days	30-60 days	30-60
Grievance	5-15 days	10-30 days	60-75
Nomination registration	1-2 days	3-5 days	85+

The risk zone is the complex erasure request. If you have a dozen SaaS vendors processing personal data on your behalf, and each takes 7-14 days to confirm deletion through their support tickets, you are looking at 30-60 days just waiting for processor confirmations. Add your internal processing time, and the 90-day window starts to feel tight.

The solution is not to rush; it is to parallelize. Send deletion requests to all processors simultaneously on day one. Track each processor's response independently. Escalate non-responsive processors on day 14, not day 60.

How Should You Handle Cascading Erasure Under Section 12(4)?

Section 12(4) of the DPDP Act 2023 states that when a Data Fiduciary has shared personal data with another Data Fiduciary or Data Processor, it must ensure the downstream entity also corrects or erases the data upon request. This is a cascading obligation, and it is the single hardest part of DSR implementation.

There are two approaches, and the right one depends on your vendor landscape.

Approach 1: API-Based Deletion (Ideal)

If your Data Processors expose a deletion API (most modern SaaS platforms do), integrate it directly into your orchestration layer. When an erasure request is processed:

1. Your system calls the processor's deletion endpoint with the Data Principal's identifier.
2. The processor returns a confirmation (synchronous) or a callback/webhook (asynchronous).
3. Your audit trail logs the request, the response, and the timestamp.

This approach scales well and produces clean audit records. The challenge is that not every processor offers a programmatic deletion API. Older enterprise systems, agencies handling data manually, or regional vendors without API infrastructure will require a different approach.

Approach 2: Notification-Based Deletion (Pragmatic Fallback)

For processors without API support:

1. Your system sends an automated email notification to the processor's designated contact, specifying the Data Principal's identifier and the data to be erased.
2. You track the notification in your audit trail.
3. You set a follow-up reminder (day 14, day 30) to confirm deletion if the processor has not responded.
4. Upon receiving confirmation (email reply, support ticket closure), you log it as completed.

This is slower and less reliable, but it is the reality for many Indian businesses working with a mix of modern and legacy vendor stacks. The key is documentation: if a processor fails to confirm deletion despite multiple follow-ups, log every attempt. That record demonstrates good faith when the Data Protection Board reviews your compliance.

Your data processing agreements should specify the processor's obligation to respond to deletion requests within a defined window. If your DPAs are silent on this, renegotiate them before enforcement begins.

Should You Build or Buy?

This is the trade-off conversation every engineering team has. Here is how I think about it.

Factor	Build In-House	Buy / Adopt a Platform
Time to launch	6-12 weeks (minimum viable), 3-6 months (production-grade)	Days to weeks
Customisation	Full control over workflows, UI, integrations	Limited by platform capabilities; may require workarounds
Maintenance burden	You own every bug, every update, every regulatory change	Platform vendor handles compliance updates
Data residency	Full control; deploy wherever you want	Depends on vendor; verify Indian data hosting
Cost (first year)	Engineering time: 200-500 hours (₹10-25 lakh in loaded developer cost for a mid-tier team)	Platform subscription: varies, typically ₹2-8 lakh/year
Audit readiness	You build the audit trail; quality depends on your discipline	Pre-built audit trails designed for regulatory review
Scalability	Depends on your architecture	Typically designed for multi-tenant scale

For a 20-person startup processing personal data from a few thousand users, a well-designed internal tool built on your existing stack can work. The request volume will be low, the data sources are few, and your team knows the codebase intimately.

For a company with 50,000+ users, multiple SaaS integrations, and processor relationships across payment, analytics, marketing, and infrastructure providers, the build-from-scratch path absorbs engineering bandwidth that is almost certainly better spent on your core product. The compliance platform handles the intake, orchestration, SLA tracking, and audit trail, and your team focuses on the data connectors that plug your specific systems into it.

I have seen both approaches succeed and both fail. The failures were never about the technology choice. They were about incomplete data mapping (the portal cannot query systems it does not know about), missing processor integrations (erasure stops at your database and never reaches the CRM), and non-existent audit trails (everything worked perfectly until someone asked for proof).

What Are the Common Pitfalls?

Every DSR implementation I have reviewed, including two I built myself, has run into at least one of these:

Pitfall 1: Treating the portal as a standalone project. A DSR portal is an integration surface that touches every system storing personal data. If your data map is incomplete, your portal is incomplete. Start with the data audit, not with the portal UI.

Pitfall 2: Forgetting about backups. When a Data Principal requests erasure, Section 12 does not distinguish between production databases and backup tapes. If your backup retention policy keeps data for 90 days and you receive an erasure request on day one, you need a process to mark that data for deletion when the backup rotation completes. Some teams maintain an "erasure ledger" that flags identifiers for exclusion from any future backup restore.

Pitfall 3: No rate limiting on the intake form. Without rate limiting, a malicious actor (or an automated bot) can flood your portal with thousands of requests, overwhelming your processing queue. Implement sensible rate limits per identifier and per IP address. The Act does not require you to process duplicate requests for the same data from the same person within a reasonable window.

Pitfall 4: Ignoring the grievance redressal requirement. Teams often build the access and erasure flows and forget that Section 13 requires a separate grievance mechanism. The DSR portal is the natural home for this. Add a "File a Complaint" option alongside "Access My Data" and "Delete My Data." Route complaints to your designated grievance officer, not to the same engineering queue that handles technical requests.

Pitfall 5: Over-engineering identity verification. I have seen portals that require government ID uploads, selfie verification, and postal address confirmation just to submit an access request. For most businesses, email OTP verification is sufficient and proportionate. Save the heavier verification methods for high-sensitivity scenarios or nominee activation.

Frequently Asked Questions

Does the DPDP Act require a self-service portal, or can I accept DSR requests by email?

The DPDP Rules 2025 require a "publicly accessible mechanism" for Data Principals to submit requests, available through your website, application, or a dedicated portal. Email technically qualifies as a mechanism, but it creates significant operational risk: no structured intake, no automatic SLA tracking, no audit trail without manual effort. A purpose-built form or portal, even a simple one, is strongly recommended. You can accept email as an additional channel, but it should not be your only one.

How many DSR requests should a typical Indian SMB expect?

Volume depends on your user base and industry. As of February 2026, the DPDP Act is not yet enforceable (full compliance deadline is May 13, 2027), so most Indian businesses have not experienced DPDP-specific DSR volumes yet. For reference, GDPR experience across companies with 10,000 to 100,000 users in comparable verticals suggests 5 to 20 requests per month during normal operations, with spikes of 50 to 100 following a publicised data incident or a major privacy news cycle. Plan for the spike, not the baseline.

Can I charge a fee for processing DSR requests?

No. The DPDP Act 2023 does not authorise Data Fiduciaries to charge Data Principals for exercising their rights under Sections 11 through 14. Unlike GDPR, which allows a "reasonable fee" for manifestly unfounded or excessive requests under Article 12(5), the DPDP Act contains no equivalent provision. You must process all valid requests at your own cost.

What happens if a Data Processor refuses to confirm deletion?

The obligation under Section 12(4) is on you, the Data Fiduciary, to ensure downstream deletion occurs. If a processor is non-responsive, escalate through your contractual relationship. Document every attempt. If the processor ultimately refuses or fails to delete, this becomes a breach of your data processing agreement and should be reported in your compliance records. Consider whether continuing to share data with a non-responsive processor is a risk your organisation should accept.

Do I need to support DSR requests in multiple Indian languages?

The DPDP Rules 2025 require privacy notices and consent mechanisms to be available in English and the 22 scheduled Indian languages. The DSR submission form should at minimum be available in English and Hindi. If a significant portion of your user base communicates in a regional language, supporting additional languages in your DSR intake form reduces friction and demonstrates good faith. The responses and data summaries you provide can be in English unless the Data Principal specifically requests another language available on your platform.

Simplify Your DPDP Compliance

This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.

Building a DSR portal from scratch means stitching together intake forms, identity verification, multi-system data queries, processor deletion workflows, SLA tracking, and audit logging, all before you handle your first real request. ComplyZero's self-serve platform includes a pre-built DSR portal with automated request routing, 90-day deadline tracking, cascading processor notifications, and audit-ready records, designed specifically for Indian businesses that need to be compliant without rebuilding their tech stack.

Join the waitlist →