From Consent to Verified Erasure: Building the DPDP Evidence Chain

PDI DPDP Evidence Chain: one request, nine linked handoffs

This article is operational guidance, not legal advice or certification. Applicability, legal grounds, exemptions and retention duties require qualified review. A completed PDI evidence chain is not a finding that an organization complies with the DPDP Act or Rules.

Statutory and regulatory context: the DPDP Act 2023 is the legal source for the relevant notice, consent, processing and rights provisions. G.S.R. 843(E), dated 13 November 2025, phases commencement of the Act’s provisions. Rules 2025, G.S.R. 846(E), dated 13 November 2025, should be read with the official G.S.R. 892(E) corrigenda dated 10 December 2025. These primary texts, not the workflow below, determine legal obligations.

Phased timing: the Rules specify immediate commencement for rules 1, 2 and 17–21, one year for rule 4, and eighteen months for rules 3, 5–16, 22 and 23. The eighteen-month commencement date used here is 13 May 2027; the one-year stage is 13 November 2026. G.S.R. 843(E) separately identifies the corresponding Act provisions. Do not treat all provisions as having a single commencement date.

PDI operational recommendation: link request/notice or consent context → scope → discovery → owner → decision → approved action → verification → exception → retained evidence. The nine handoffs below are PDI’s evidence-management model, not a statutory form, mandated sequence, regulator-approved checklist or automatic erasure instruction.

Separate the instruction from the decision

Start by recording the incoming event: its channel, received time, reference identifier, asserted identity attributes, and the wording or category of the request. Keep consent changes, withdrawal, correction, and erasure requests distinguishable; they may require different operational handling. Restrict access to the source material and minimize copies of identity data.

The intake record is not itself a legal conclusion. Route it to the organization’s designated privacy or legal process to determine what review is required, what information is needed to resolve identity, and which timelines or exceptions apply. This article is operational education, not legal advice; applicability and legal sufficiency must be assessed by qualified counsel for the relevant facts.

Keep one request reference across handoffs

Use a request reference to connect intake, identity review, discovery results, approval, execution tickets, verification, and exceptions. A reference makes the chain traceable; it does not authorize an action or establish the request’s legal validity.

Resolve the person and discover where data may reside

Use approved identifiers and matching procedures to create a bounded search context. Names, email addresses, account identifiers, and historical aliases may point to different records, but a match should retain the evidence and confidence behind it. Avoid treating a weak match as authorization to delete a record that may belong to someone else.

Run discovery against the approved systems and document coverage: source, owner, data location, scan time, method, result, and limitations. Include operational stores, analytics copies, exports, and vendor-managed locations where the organization’s inventory and agreements indicate they may be relevant. A missed source is not a verified negative.

Assign ownership before asking for action

For each candidate record or system, identify an accountable data or application owner and the operator who can perform the change. Confirm record identity, purpose, dependencies, retention context, and any preservation or exception review required by internal policy. The owner should record a decision and rationale, not merely acknowledge an email.

A useful handoff carries a stable request ID, source path, matched-record evidence, requested disposition, approval state, and the evidence expected back. Keep data minimization in view: an operator should receive enough information to find the correct record, not an unrestricted bundle of personal details.

Keep execution in the system of action

Discovery and governance tooling can help identify records, route work, and preserve decisions. The actual erasure or change is performed by the system and process authorized to act on that data: for example, an application’s supported deletion workflow, a platform operator, or a vendor process. The work queue should link to that system’s change or case reference and record who initiated the action.

Do not claim that a discovery product itself executes erasure unless the relevant system integration and action are explicitly established. For every system, define the expected completion signal, what a successful response means, and how retries or partial failures are handled. A returned “accepted” response is not necessarily proof that all copies are gone.

Verify outcomes across systems and copies

Verification should be designed per system. It may involve a deletion status, a controlled follow-up query, a tombstone or suppression record, a downstream propagation check, or an operator attestation with supporting evidence. Choose a method that demonstrates the intended result without creating another unnecessary copy of the personal data.

Record verification time, method, actor or service identity, outcome, and any residual state that the method cannot test. Where backups, immutable records, legal holds, or derived datasets are handled differently, describe that distinction and route it through the approved policy. Do not turn a system’s limitation into an unqualified “erased everywhere” statement.

Make exceptions visible and time-bound

A system may be unavailable, the identity match may be uncertain, or a record may need a separate retention review. Track each exception with its affected source, reason, decision owner, approval reference, compensating measure where applicable, next action, and review date. Partial completion should remain partial in the status model.

A useful exception queue is ordered by next decision or action, not just age. It should surface blocked approvals, failed execution, ambiguous matches, unverified outcomes, and partner dependencies distinctly so that escalation reaches the team able to resolve the specific obstacle.

Preserve a linked, reviewable evidence chain

The final record should connect intake, discovery, identity decision, ownership, authorization, execution reference, verification, and exceptions under one request identifier. Keep original observations distinct from later decisions, capture timestamps and responsible roles, and store sensitive attachments under the organization’s approved access and retention controls.

For organizations working from PDI’s DPDP materials, the checklist page identifies the official source basis: the DPDP Act 2023, commencement notification G.S.R. 843(E), and DPDP Rules 2025 notification G.S.R. 846(E), both notifications dated 13 November 2025. The eighteen-month commencement date is 13 May 2027; commencement is staged, so this is not a claim that every provision begins on that date. Consult the official texts and qualified counsel for applicability to the relevant facts. The related DPDP enterprise data-control guide and Kestryl DPDP cockpit provide context for discovery and evidence workflows, but neither replaces legal review or the external systems that carry out approved actions.