Most companies prepare for DPDP rights requests by publishing an email address.
A Data Principal sends an email.
Legal forwards it to engineering.
An engineer checks the users table.
Someone checks the CRM.
Someone checks analytics.
A spreadsheet gets updated with whatever each team found.
That is not a rights workflow.
It is a manual investigation with an inbox at the front.
The DPDP Act creates rights around access to information, correction/completion/updating, erasure, grievance redressal and nomination. The final Rules also require Data Fiduciaries to publish the means for making rights requests and the identifier needed to identify the Data Principal. DPDP Act 2023
The engineering problem is to turn those rights into repeatable operations.
The rights you actually need to operationalise
Section 11: Access to information
A Data Principal can request a summary of personal data being processed, processing activities, identities of other Data Fiduciaries and Data Processors with whom the data has been shared and other prescribed information.
That is broader than a CSV export.
Section 12: Correction and erasure
The Data Principal can request correction, completion, updating and erasure, subject to the statutory conditions and applicable legal retention.
Section 13: Grievance redressal
The Data Principal has a right to a readily available grievance mechanism.
Section 14: Nomination
The Data Principal can nominate another individual to exercise their rights in the event of death or incapacity.
The rights are easy to list.
The workflow is where the engineering work begins.
Step 1: Create one intake layer
Do not create five disconnected inboxes.
Use one request system that can classify:
Access
Correction
Completion
Update
Erasure
Grievance
Nomination
The final Rules require the means of making a rights request and the identifier required to identify the Data Principal to be prominently published. DPDP Rules 2025
Every request should receive:
- Request ID
- Data Principal identifier
- Request type
- Received timestamp
- Verification status
- Owner
- Processing status
- Completion timestamp
- Evidence
Step 2: Verify the requester
You cannot fulfil a rights request for the wrong person.
Build identity verification before data retrieval.
A practical flow is:
Request
↓
Identify
↓
Verify
↓
Classify
↓
Authorise
↓
Execute
The exact verification method depends on the product and the sensitivity of the request.
Do not create unnecessary friction for every request.
Do not create so little friction that an attacker can obtain someone else's information.
Step 3: Make the data map your retrieval engine
This is why data mapping matters.
When the request arrives for user 87421, the workflow should not ask an engineer:
"Where does this person's data live?"
It should ask the inventory.
For example:
User 87421
│
├── PostgreSQL
│ ├── users
│ └── subscriptions
│
├── BigQuery
│ └── product_events
│
├── S3
│ └── uploaded_files
│
├── Intercom
│ └── contact + conversations
│
└── Analytics platform
└── user profile + events
Now the request becomes an orchestration problem.
Without the map, it becomes a detective exercise.
See our DPDP data mapping guide.
Step 4: Use a request state machine
Rights requests should have explicit states.
RECEIVED
↓
IDENTITY_VERIFIED
↓
CLASSIFIED
↓
DATA_LOCATED
↓
ACTION_IN_PROGRESS
↓
PROCESSOR_ACTIONS_PENDING
↓
VERIFICATION
↓
COMPLETED
And explicit failure paths:
IDENTITY_FAILED
RETENTION_EXCEPTION
PROCESSOR_TIMEOUT
MANUAL_REVIEW
Do not let the status live in someone's inbox.
Machine-readable states give you SLA tracking, retries, ownership and evidence.
Step 5: Access is more than "download my data"
Section 11 gives the Data Principal access to information about processing, including the identities of other Data Fiduciaries and Data Processors with whom their personal data has been shared, subject to the statutory exceptions. DPDP Act 2023
A useful response should therefore be designed around the request.
Potential components:
Personal data summary
- Relevant categories
- Data being processed
- Processing activities
Sharing summary
- Other Data Fiduciaries
- Data Processors
- Categories of personal data shared
Processing context
- Purposes
- Relevant processing activities
- Applicable basis
The user does not need your internal architecture.
Your team does need a reliable way to derive the answer.
Step 6: Correction needs propagation too
Suppose a user changes their phone number.
You may have:
Application DB
CRM
Support platform
Billing
Analytics profile
Marketing platform
Which system is authoritative?
Define it.
Then define how the correction reaches dependent systems where appropriate.
The workflow becomes:
Request
↓
Validate
↓
Update source of truth
↓
Identify dependent systems
↓
Propagate
↓
Verify
↓
Evidence
Correction is a distributed-state problem just like consent.
Step 7: Erasure is orchestration
Section 12(3) gives a right to erasure unless retention is necessary for the specified purpose or compliance with law. Section 8(7) separately addresses erasure when consent is withdrawn or when the specified purpose is no longer being served, subject to legal retention. DPDP Act 2023
Your erasure workflow needs:
- System inventory
- Deletion method
- Retention exception
- Processor dependency
- Retry logic
- Verification
- Evidence
See our DPDP data deletion guide.
Step 8: Processor actions need tracking
Suppose your system sends a deletion request to a processor.
Record:
Processor
Request sent
Timestamp
Response
Action taken
Evidence
For processors without an API, the workflow should track the manual action and its outcome.
Manual steps are not automatically non-compliant.
Invisible manual steps are the problem.
Step 9: Build retention exceptions into erasure
An erasure request does not automatically mean "delete every byte immediately."
The Act recognises cases where retention is necessary for a specified purpose or compliance with law.
Therefore the workflow should contain an explicit decision point:
Erasure requested
↓
Valid retention requirement?
/ Yes No
↓ ↓
Retain Erase
+ reason ↓
Verify
If data is retained, record:
- What was retained
- Why
- Applicable requirement
- Retention period
- Approver
Do not turn "legal hold" into a generic bypass button.
Step 10: Grievances need their own SLA
A grievance should not disappear into support.
The final Rules require the grievance system to respond within a reasonable period not exceeding 90 days. DPDP Rules 2025
Track:
- Complaint
- Date received
- Owner
- Actions
- Communications
- Resolution
- Escalation
- Closure
The user should be able to understand where the complaint stands.
Step 11: Design nomination now
Nomination is infrequent, but it should still exist in your data model.
The Act allows a Data Principal to nominate another individual to exercise rights in the event of death or incapacity. DPDP Act 2023
Track:
- Nominee
- Identifier
- Status
- Date
- Verification
- Changes or revocation
Do not build it from scratch when the first request arrives.
Step 12: Generate evidence automatically
A rights workflow should produce an evidence record for every request.
Example:
Request ID: DPR-2026-00821
Data Principal: 87421
Type: Erasure
Received: 2026-09-04 10:31
Verified: 2026-09-04 10:33
Systems identified: 11
Systems completed: 10
Processor pending: 1
Retention exception:
Billing records retained under applicable law
Final status:
COMPLETED WITH RETENTION EXCEPTION
The exact fields will vary.
The principle does not:
Every important action should be reconstructable.
Architecture
Data Principal
│
↓
Rights Request API
│
↓
Identity Verification
│
↓
Request Engine
│
┌───────────┼───────────┐
↓ ↓ ↓
Data Map Consent Retention
Ledger Rules
└───────────┼───────────┘
↓
Action Orchestrator
│
┌──────────────┼───────────────┐
↓ ↓ ↓
Internal Processors Storage
Systems APIs Systems
└──────────────┼───────────────┘
↓
Verification
↓
Evidence Store
↓
User Response
That is the difference between a rights inbox and an operational rights system.
Five failure modes
Failure 1: One inbox.
Everything enters privacy@company.com. Nothing is consistently tracked.
Failure 2: Primary database only.
The database is clean. Analytics and support systems are not.
Failure 3: Weak identity verification.
A legitimate rights workflow becomes a data-disclosure vulnerability.
Failure 4: No retention decision.
Teams either delete too much or keep everything because nobody defined the exception.
Failure 5: No evidence.
The request was completed. Nobody can prove how.
The self-test
Take one real user.
- Can you identify every system where their data exists?
- Can you produce the Section 11 information without a manual investigation?
- Can you correct a field across dependent systems?
- Can you erase data while respecting valid retention requirements?
- Can you show which processors were contacted?
- Can you show timestamps for the actions?
- Can you track a grievance to closure?
- Can you execute a nomination request?
If the answer to several is "we would need to figure that out", the problem is not the request form.
It is the infrastructure behind it.
Where Privra fits
Privra connects data discovery, consent, processor mapping, retention and rights workflows into one operational system.
Instead of sending a request into an inbox and asking engineers to investigate, the process can start from a known data map and route the required actions across the systems that actually hold the data.
Talk to Privra about operationalising Data Principal rights.
This article is general information, not legal advice. Legal requirements and Privra's recommended implementation practices are intentionally distinguished.