A DPDP data principal request workflow is the machinery behind the rights programme. The policy may explain available routes and outcomes. Operations must capture a request from any reasonable channel, associate it with the right person, translate free text into work packages, search distributed systems, coordinate actions, deliver a safe response, and preserve a lean audit record.
Use the Digital Personal Data Protection Act, 2023 on India Code, MeitY's Digital Personal Data Protection Rules, 2025 collection, and the current official enforcement timeline. CERT-In's section 70B Directions page may matter to separate security and record-handling processes. Do not collapse privacy requests and security incidents into one queue merely because both involve personal data.
This article goes deeper into case execution than the related rights pillar. It does not decide whether a particular request is valid, which outcome is required, or what exception applies.
How should every request channel feed one controlled queue?
Publish a clear request route, then assume requests will arrive elsewhere. Support, sales, HR, social, postal mail, account teams, and security staff need a recognition and routing script. They should preserve the person's words, avoid asking for extra identity documents, and forward through a protected internal route instead of a broad mailbox.
At intake, create a case ID and capture:
- original message, attachment, channel, and receipt time;
- contact or account details already supplied;
- relationship, product, service, or employment context;
- request in the person's own words;
- language, format, accessibility, and communication preferences;
- representative, guardian, or nominee context if raised; and
- any apparent security, fraud, safety, or grievance signal.
Do not force a premature request type. “I want you to fix what you know about me and explain where it went” may create multiple work packages. Preserve one case and route the parts separately.
| Intake signal | Case action | Separate route that may be needed |
|---|---|---|
| Account appears compromised | Restrict exposure and escalate verification | Security or fraud response |
| Complaint about prior handling | Link the earlier case | Grievance review |
| Suspected data exposure | Preserve facts and alert authorised team | Incident assessment |
| Request covers several products | Assign a coordinating owner | Multiple system searches |
| Accessibility need | Record delivery requirement | Approved support process |
How can identity assurance stay proportionate and secure?
Match verification to the risk of the requested action and information. A logged-in path may be suitable in one situation but weak where the account appears compromised. A former employee or customer may need an alternate association route. Qualified advisers should approve the available procedures.
Build identity assurance as a gate with multiple approved paths, not a demand for government identification in every case. Use data already held where appropriate. Collect only what is necessary. Store verification material separately from general notes, restrict access, and retain the result rather than duplicating raw documents across systems.
Document the method, checks performed, outcome, limitations, reviewer, and date. Include escalation for mismatched details, lost account access, representatives, minors, shared accounts, deceased persons, impersonation indicators, and high-risk disclosures. Never expose internal fraud signals in a response template.
How should free-text requests become precise work packages?
After the approved intake and verification steps, parse the request into actions without rewriting its meaning. Keep the original statement beside the operational scope. Identify date ranges, products, identities, systems, records, correction fields, erasure targets, communications, and grievance issues. Ask a focused clarification only when necessary and through the approved procedure.
Create a scope map:
| Work package | Inputs | Output evidence |
|---|---|---|
| Locate records | Identifiers, systems, date range | Search attestations and result links |
| Prepare access material | Responsive set and approved review rules | Reviewed response package |
| Correct information | Source field, asserted correction, downstream map | Before-and-after system evidence |
| Erasure action | Approved target and constraints review | Deletion log, provider attestation, or exception record |
| Grievance | Disputed event and requested remedy | Independent review and communication |
Assign one coordinating owner even when several teams act. The person should not have to manage the organisation chart. Each work package needs an accountable system owner, internal milestone, dependency, completion test, and escalation route.
What makes a system search complete enough to review?
The data inventory is the search blueprint. Map customer, device, employee, email, phone, account, contract, ticket, and other approved identifiers across production systems, archives, logs, document stores, communications, analytics, marketing platforms, and processors. Do not run every possible identifier everywhere. Document why each is relevant and permitted.
Require a search attestation containing system, owner, query or procedure, identifiers, coverage period, run date, result location, exclusions, limitations, and completion statement. Preserve results in their source system or controlled workspace. Avoid turning the request case into an uncontrolled copy of all responsive data.
Use this sequence:
Scope approved → identifiers mapped → system owners assigned → searches run → gaps reconciled → provider results received → responsive set reviewed → action packages released
Test searchability with synthetic identities before live requests arrive. The exercise often finds orphaned SaaS accounts, identifiers that changed format, inaccessible archives, missing processor contacts, and systems that support deletion only through manual engineering work.
How should correction and erasure actions propagate safely?
A change in one interface may not update the source of truth, derived profile, backup, downstream processor, or reporting system. Build a dependency graph for each material field and processing activity. The approved decision should identify exactly which systems and records are included, what constraints or exceptions were assessed, and what completion evidence is required.
For correction, preserve the asserted value, approved source, old and new system state, propagation results, conflicts, and communication. For erasure, use an authorised target list, check connected retention and hold processes, execute through controlled tools, record failures, and obtain processor evidence where appropriate. Do not claim deletion because a front-end record disappeared.
A four-eyes release is useful for high-impact actions:
- The action matches the approved request scope.
- The correct identity and tenant are selected.
- Holds, dependencies, and approved exceptions were reviewed.
- Downstream systems and processors are included.
- Completion evidence is stored without excess personal data.
- Failed or partial actions have an owner and response impact assessment.
How can response assembly prevent disclosure and delivery errors?
Separate collection from disclosure review. Responsive material may contain another person's data, confidential business information, security detail, duplicate records, unreadable exports, or material requiring legal review. Apply approved review and redaction procedures. Preserve the reviewed version and its relationship to the source.
Before sending, check recipient, identity result, scope, action evidence, attachment set, redactions, file integrity, language, accessibility, secure-delivery method, and grievance route. Open the final package as the recipient would. A technically complete export can still be unusable if codes are unexplained or files require internal software.
Maintain a delivery ledger with approved version, recipient, channel, dispatch, access or delivery result, failed attempts, and corrected reissue. Secure links need expiry and support procedures. Never put confidential response material in ordinary ticket comments.
Review Gotham's privacy information and security approach during platform diligence. Verify the actual deployment's permissions, audit history, encryption, provider routing, backups, exports, and retention. Product information cannot determine the organisation's statutory role or compliance.
What should quality review and closure prove?
Closure should prove that the request was routed, verified, scoped, searched, decided, actioned, reviewed, delivered, and linked to any grievance or remediation. Lock the official history against silent edits. Narrow temporary access and apply the approved retention schedule.
Review case samples for substantive quality:
- The original request and later clarification remain visible.
- Verification was proportionate and minimised.
- Work packages cover every part of the request.
- Search attestations identify systems and limitations.
- Actions reached approved downstream systems.
- Disclosure review and delivery evidence are complete.
- Late information can reopen or link to the case.
- Repeated defects create product, inventory, or provider remediation.
Track operational friction such as misrouting, verification rework, unavailable system owners, search gaps, failed actions, undelivered packages, and repeated grievances. Use internal targets drawn from the current approved obligation register. Do not publish or hard-code an unverified legal deadline.
For the legal-rights and governance layer, read the DPDP data principal rights workflow. Teams can explore Gotham workflows, review security and deployment information, or contact Gotham about controlled privacy operations. Good case management makes evidence and handoffs dependable. It does not decide the requester's entitlement or replace qualified advice.
