Track an erasure request across more than one system

An erasure request rarely ends with one delete button. The same person may appear in a customer database, a spreadsheet export, a processor’s system and a backup. Some records may need to be erased, while others require restricted retention under an applicable rule.

The first task is to establish the requested scope and the relevant records. The second is to decide what should happen to each record class. Only then can the team create a deletion job that means something.

Decide the outcome before dispatching tasks

The DPDP Act’s sections 8(7) and 12 address erasure through different provisions. Section 8(7) covers withdrawal or the end of purpose, whichever is earlier, subject to legally necessary retention. Section 12 covers erasure rights within its stated consent-based scope, including section 7(a), with its purpose and legal-retention qualifications. The final Rules, including rule 8(3), also contain retention provisions that must be considered.

Rule 8(3) specifies at least one year of retention from processing for personal data, associated traffic data and processing logs for the Seventh Schedule purposes, subject to the text’s further-retention qualification. It is not a general permission to reuse that retained information for marketing.

These substantive provisions are scheduled for 13 May 2027 under the commencement notification, as checked on 22 October 2026. This matters when designing future workflows. It also means the team should avoid promising immediate, universal deletion without examining applicable obligations.

Create a decision record for each data class: erase, restrict pending a retention period, retain for an identified requirement, or investigate because scope is uncertain. Have a qualified owner resolve legal retention questions rather than embedding a guess in code.

Make the system list concrete

For a hypothetical equipment-rental business, the request might involve an active customer profile, returned-equipment photographs, invoices, a support conversation and an outsourced messaging contact.

Map each class to the system holding it and the person who can act. Include exports and attachments, not only the database named in the privacy policy. Where information has been transformed into an index, identify the relationship between the source and its derived records.

A vector database is one example of a separate lifecycle. Pinecone’s deletion documentation describes deletion within its own index namespace and notes visibility delays. That operation does not establish what happened to the original file or other application copies.

The principle is broader than any vendor: each storage or processing location needs an appropriate action and evidence.

Keep retained records out of ordinary use

In the rental example, an invoice may require a different decision from a promotional contact list. A retained invoice should not automatically keep the person eligible for marketing or make all profile fields available to customer-service staff.

The workflow should distinguish retention from active reuse. Restrict access according to the documented purpose, record the reason and review the expiry or release condition. If a hold is linked to a dispute, identify who reviews it when the dispute ends.

Explain the distinction to the requester in plain language. “Your data was deleted” is inaccurate if relevant records remain. “Nothing can be deleted because we have invoices” may be equally inaccurate if unrelated active records can be removed.

Track completion at each destination

Use one parent case with linked tasks. A processor acknowledgement, an accepted API request and a verified deletion are different states.

Each task should show the target, approved action, attempt history, result and any remaining dependency. Where a service uses eventual consistency, verify the documented outcome through the appropriate read or status mechanism rather than assuming an immediate query is definitive.

Avoid logging the full deleted content as proof. A reference, bounded count, result and authorised reviewer may provide useful evidence without recreating the data in the audit trail.

Backups need a documented handling policy, including what happens during restoration. If a restore can reintroduce records that were already removed from active use, the restoration process should reapply the relevant deletion or restriction decisions before normal processing resumes.

A closure checklist

Before closing the hypothetical rental request, confirm:

• The person and requested scope were established.
• Each relevant data class has an approved action.
• Retention reasons are specific and reviewable.
• Processor tasks have reached an evidenced outcome.
• Derived indexes and exports were considered.
• Retained material is separated from unrelated active uses.
• Backup restoration behaviour is documented.
• The explanation accurately describes what remains.

Where a task cannot finish, keep the limitation visible and owned. A well-designed erasure workflow can explain both its completed actions and its boundaries. It should never convert a complex, partially completed process into an unconditional success badge merely because the first system accepted a request.