You don’t need a portal. You need the right strategy for your size.
India’s Digital Personal Data Protection Act (DPDPA) gives every individual, called a Data Principal the right to know what data you hold about them, correct it, erase it, and raise a grievance if something goes wrong. As an organisation, you are legally required to have a way to receive and respond to these requests. Period.
The instinct for many organisations is to use or buy a dedicated web portal: a slick preference centre where users log in, verify their identity, and submit requests. This is called a Data Principal Request Access (DPAR) or a Preference Centre. But here is the truth that most vendors won’t tell you: not every organisation needs one.
We’ve broken down four practical strategies, from the simplest email-based approach to full enterprise integration and tell you exactly which one fits your situation, with real-world examples and simulated data to make the decision easier.
First, Understand What You Are Actually Building
A Data Principal Request Centre needs to do three things:
- Receive requests – grievances, deletion requests, correction requests, access requests.
- Route them – to the Data Protection Officer (DPO), IT team, legal team, or a business unit.
- Resolve and respond – within the timeframe the law mandates (currently proposed at 30 days under DPDPA draft rules).
Well, the question is not whether to do these three things because you must. But question is how and much infrastructure to build for it. To better understand, think of it like a hospital’s patient complaint system. A 20-bed nursing home and a 2,000-bed government hospital both need a complaint system. But one uses a register at the front desk; the other needs a digital ticketing system with escalation workflows. The law applies equally but the solution does not have to be the same.
The Volume Problem: Why One Size does not Fit All
Before choosing a strategy, estimate your expected request volume. Here is a simulated benchmark based on industry patterns across Indian organisations:
| Organisation Type | Estimated Monthly Requests | Recommended Strategy |
| Small fintech startup (50K users) | 5–15 | Strategy 1 (Email) |
| Mid-size e-commerce (500K users) | 30–80 | Strategy 2 (Help Desk) |
| Large bank or telecom (5M+ users) | 500–2,000+ | Strategy 3 or 4 |
| Hospital / healthcare provider | 20–60 (but sensitive) | Strategy 4 |
| HR / employee data platform | 10–40 | Strategy 2 or 4 |
These numbers matter because your strategy choice affects cost, staffing, and training requirements. Getting it wrong in either direction is a problem: under-building leads to missed deadlines and regulatory risk; over-building wastes budget and creates systems nobody knows how to use.
Strategy 1: The Email Route
Best for: Organisations expecting fewer than 20 requests per month.
This is the most underrated strategy – simple and honest. You simply publish a clear, easy-to-find email address in your Privacy Notice and DPDPA Consent Notice – something like dpo@yourcompany.in – along with the DPO’s name, working hours, and expected response time.
What good looks like in your Privacy Notice:
“To exercise your rights under the Digital Personal Data Protection Act, 2023 – including accessing your data, requesting correction or erasure, or raising a grievance – please write to our Data Protection Officer at dpo@acmecorp.in. Please include your registered mobile number or email ID so we can verify your identity. We will respond within 7 days.”
Simulated example – Example Retail Pvt. Ltd., Pune: Acme runs a regional loyalty programme with 80,000 registered users. In their first six months under DPDPA compliance, they received 9 grievance emails and 4 data deletion requests. All 13 were resolved by their DPO, who spent roughly 45 minutes per request on average. Total effort: under 10 hours across six months. A portal would have cost them lakhs to build and required a third-party vendor SLA.
What this strategy requires:
- A monitored DPO inbox (not a generic info@ address that nobody checks)
- A simple internal template or checklist to verify identity and process the request
- A basic spreadsheet log to track open and closed requests (for audit purposes)
Where it breaks down: If you cross 25–30 requests a month, the DPO’s inbox becomes a bottleneck. Requests get missed. Response timelines slip and that is when you move to Strategy 2.
Strategy 2: Add a Category to Your Existing Help Desk
Best for: Organisations that already run a customer service help desk and expect 30–150 requests per month.
If you use tools like Freshdesk, Zendesk, Zoho Desk, or even an internal JIRA service desk, you already have the infrastructure. You do not need to build anything new. You just need to add a new ticket category – call it “Data Privacy Request” or “DPDPA Request” – and train your agents on how to handle it differently from a regular support ticket.
The key difference from a normal support ticket is this: a data principal request is not just a customer complaint. It may require your IT team to pull records, your legal team to review an erasure request, or your DPO to sign off before responding. A regular L1 support agent cannot resolve this alone.
Simulated example – QuickBills NBFC, Mumbai: QuickBills processes personal loan applications. Their support team uses Freshdesk and handles roughly 800 tickets a month. After DPDPA compliance work began, they estimated 50–70 data principal requests per month (mostly “what data do you hold on me?” and “delete my account” requests from rejected applicants).
They created a new ticket category with a custom form, added a routing rule to assign it to their DPO directly, and set a 30-day SLA flag that triggers an alert at day 20. Training took one afternoon. Integration cost: ₹0 (already in their existing Freshdesk plan).
In their first quarter, they received 61 requests. Average resolution time: 18 days. Zero regulatory escalations.
What this strategy requires:
- An existing help desk platform
- A dedicated ticket category with routing to DPO or privacy team
- Agent training – at minimum, agents must know not to try to resolve data requests themselves and to escalate immediately
- An internal escalation playbook: who handles deletion, who handles access, who handles grievances that allege a data breach
Where it breaks down: If your requests are complex – for example, involving multiple departments, internal investigations, or cross-border data flows – a simple ticket category is not enough. You need workflows. That is Strategy 3 territory.
Strategy 3: Use Your Consent Management Platform’s Built-In Workflows
Best for: Organisations that have already deployed a Consent Management Platform (CMP) and expect growing request volumes with complex routing needs.
Many enterprise-grade CMPs – including OneTrust, Securiti, MineOS, and some Indian-market providers – offer a built-in Data Subject Rights (DSR) module with workflow automation, identity verification, and integration APIs. If your organisation has invested in a CMP, this module is often included or available as an add-on.
The advantage here is that the CMP already knows your data map. When a deletion request comes in, the system can automatically check which systems hold that user’s data – CRM, marketing database, loan origination system, HR platform – and generate a task list for each team to confirm deletion. The DPO reviews the consolidated response before it goes back to the data principal.
Simulated example – HealthFirst Insurance, Bengaluru: HealthFirst holds sensitive health data on 2.2 million policyholders. They deployed a CMP for consent management during their DPDPA readiness programme. When they turned on the DSR module, they found it could connect via API to their Salesforce CRM and their claims management system.
A deletion request now triggers a workflow: CRM team confirms deletion within 5 days, claims system team confirms within 7 days, DPO reviews and sends the closure letter by day 15. Before this, the DPO was manually emailing three departments and chasing responses. Average resolution time dropped from 28 days to 14 days. Their team handled 340 requests in the first six months without hiring additional staff.
What this strategy requires:
- An existing CMP with a DSR/grievance module
- API integrations to at least your major data systems (this is the hard part – budget 2–4 months of IT effort if starting from scratch)
- Defined workflows: who does what, in what order, with what deadline
- Clear ownership: one named person (usually the DPO) who can see all open requests and escalate stuck ones
A critical point many organisations miss: Data principal rights requests are not just a ticketing problem. Some requests will be handled by the DPO alone. Some will need your IT team to run a database query. Some will require legal review – especially if an erasure request conflicts with a document retention obligation under the Companies Act or SEBI regulations. Some requests will need an internal investigation, particularly if the grievance alleges a data breach or misuse. No ticket system handles this automatically. You need people, not just software.
Strategy 4: Full Preference Centre with Admin Dashboard
Best for: Large organisations with high expected volumes, multiple business units, and a privacy team that needs visibility across all requests.
This is the full portal experience: a branded, authenticated web interface where data principals log in (via OTP or linked account), view their consents, download their data, raise grievances, and track the status of their requests. On the admin side, the DPO and privacy team see a dashboard of all open cases, overdue items, and resolution trends.
Several CMPs offer this out of the box. Some organisations build it in-house, though that is rarely advisable given the identity verification complexity.
Simulated example – PeopleFirst HR Tech, Hyderabad: PeopleFirst is a B2B HR platform used by 400 client companies to manage employee data – payroll, performance, attendance. Under DPDPA, employees (as data principals) can raise requests about their personal data. PeopleFirst estimated 800–1,200 requests per month across their client base.
They deployed a preference centre that allows employees to log in with their work email, view what data the platform holds, and raise a request in four categories: access, correction, erasure, and grievance. Routing rules send each request to the relevant client company’s HR admin and copy PeopleFirst’s DPO. The dashboard shows resolution rate, average response time, and overdue requests by client.
In the first three months: 1,140 requests, 97% resolved within 30 days, and a compliance report generated automatically for each client company’s annual audit. Without the portal, this would have required at minimum three full-time staff to manage manually.
What this strategy requires:
- A CMP or purpose-built DPRC vendor with preference centre capability
- Identity verification integration (OTP via Aadhaar-linked mobile, or existing account login)
- Clearly defined SLAs for each request type
- Training for all teams who will receive routed tasks – not just the privacy team, but IT, HR, and operations
- A plan for requests that cannot be automated – because some always will be
The trap to avoid: Many organisations buy a premium preference centre, configure it, launch it – and then do nothing when 90% of requests need human review anyway. Technology speeds up routing and tracking. It does not replace judgment. A deletion request that conflicts with a court order, or a grievance that alleges surveillance by a line manager, cannot be resolved by a workflow rule.
Which Strategy Should You Pick?
Start here: How many data principal requests do you expect per month?
- Fewer than 20 – Use Strategy 1. Publish a DPO email in your Privacy Notice. Set up a monitoring routine. Log everything in a spreadsheet. Review quarterly.
- 20–100, and you already have a help desk – Use Strategy 2. Add a ticket category, train your agents, and set SLA alerts. Bi-monthly check-ins between your DPO and IT team will handle most data rights fulfilment (deletion, access) without heavy automation.
- 20–100, and you are not sure what volume is coming – Start with Strategy 4’s admin dashboard as a lightweight monitoring tool, then shift to Strategy 2 or 3 once volumes stabilise. Several CMP vendors offer a starter tier at lower cost for this reason.
- 100–500, and you have a CMP – Activate Strategy 3. Turn on the DSR module, connect it to your top three data systems via API, and define your internal workflows. Plan for quarterly reviews with IT to add new system integrations as your data map grows.
- 500+, or you are a large enterprise with multiple BUs – Strategy 4 is the right destination. But do not just deploy the portal and assume you are done. Upskill your BPO or contact centre team who will be handling the routed tasks – they need to understand what a data deletion means, what they can and cannot say to a data principal, and when to escalate to the DPO. This upskilling is frequently skipped and is almost always the reason large organisations fail their own SLAs.
The Thing Automation Cannot Fix
Every strategy in this list has a ceiling and there will always be requests that fall outside your standard workflows. A customer who says, “I gave you consent two years ago because I thought it was mandatory – it was not – I want everything deleted and I want to know who you shared it with.” That is not a Form A in your portal. That is a conversation that needs your DPO, possibly your legal counsel, and a careful written response.
A former employee who raises a grievance saying their performance data was shared with their new employer without consent. That is a potential Section 11 DPDPA violation and may require an internal investigation.
Automation routes tickets. It does not make decisions. The organisations that will handle DPDPA compliance well over the long term are the ones that build operational processes – not just software platforms.
A Note on Starting Small and Scaling
The single biggest mistake organisations make is waiting until they have the “right” strategy fully built before they do anything. DPDPA compliance does not wait for your IT roadmap. The recommended path:
- Month 1–2: Put an email address in your Privacy Notice. Log every request manually. This tells you your real volume, not your estimated volume.
- Month 3–6: Use the actual data to choose between Strategies 2, 3, or 4. Make the decision with evidence, not assumptions.
- Month 6–12: Build the operational muscle – training, escalation paths, IT integration – alongside whatever platform you choose.
- Year 2 onwards: Review your volumes, your resolution rates, and your DPO’s workload. Upgrade your strategy when the evidence supports it.
You do not need to solve this all at once. You need to not ignore it.
The right Data Principal Request Centre is the one your team can actually operate, your data principals can actually use, and your DPO can actually oversee. Start where you are. Build from there.
