Deleting an account is not the same as deleting its data

A customer presses “Delete account” and sees a success message. The login disappears, but order records, support attachments and a marketing export may still exist. That result may contain both justified retention and an operational failure. The business needs to know which is which before calling the entire request complete.

Account closure is an action on a service relationship. Personal data erasure is a decision and a set of actions across relevant records and systems. They often happen together, but designing them as identical events can produce misleading promises.

As of 22 October 2026, the main DPDP erasure and retention provisions are scheduled for 13 May 2027 under the commencement notification. This is a readiness design for that phase, with existing legal requirements considered separately.

Define the customer’s request before acting

A customer may want to stop logging in, withdraw consent for a particular use, delete an optional profile or exercise an erasure right. A simple interface should help them express the intended outcome without requiring legal vocabulary.

The Act’s section 12 provides correction and erasure rights for processing based on prior consent, including the specified section 7(a) situation. Section 8(7) separately addresses erasure on withdrawal or the end of the specified purpose, subject to lawful retention. These provisions should be read together rather than reduced to a universal promise that all information vanishes when an account closes.

Verify the request appropriately and avoid exposing information during verification. If the user cannot access the account, provide a reasonable alternative route instead of requiring the very login they are trying to close.

Map what the account connects to

A hypothetical subscription meal service holds a profile, delivery preferences, payment references, invoices, support correspondence and a fraud-investigation record. These may sit in different systems with different purposes and owners.

The profile can be disabled promptly as part of account closure. That does not determine the treatment of the invoice or investigation record. Each category needs a documented decision, including whether information must be retained, restricted or erased.

Include processors, integrations and exported files. Section 8(7) addresses causing processors to erase personal data made available to them when the relevant erasure duty applies. A business should therefore know how a request reaches its support platform, delivery supplier and other relevant processors.

Account for the final Rules’ retention provisions

Rule 8(3) requires personal data, associated traffic data and processing logs to be retained for at least one year from processing for the Seventh Schedule purposes, followed by erasure unless a further lawful requirement applies. Rule 6 has a separate security-related provision.

This means a deletion flow must distinguish stopping an active use from retaining information for a required purpose. It should not continue personalising promotions merely because some records must remain in restricted storage.

Other applicable laws may require particular records to be retained. Record the actual requirement and category; do not use the word “compliance” as a blanket reason to keep every profile field indefinitely.

Make the workflow resilient to partial completion

Use a request record that tracks each system and outcome. The main application might complete its step while a supplier job fails. A single green tick should not hide that failure.

Assign retries, escalation and a person who can review unresolved items. Where automated deletion is available, test what it actually changes. Does it erase records, disable access, remove an identifier or merely hide the account from the ordinary interface? Those are different outcomes.

Backups need a separately designed treatment, including access restrictions and controls against restoring erased data into active use. Avoid promising immediate removal from every historical medium unless the architecture and legal analysis support that promise.

Tell the customer what happened accurately

A useful completion message explains that the account is closed, identifies the categories erased and describes any justified retained categories in understandable terms. It should indicate the purpose or legal reason for retention and the route for questions or disagreement, without exposing internal security details.

If work remains unresolved, say so rather than declaring complete erasure. Keep the action record, supplier responses and exception decisions so another employee can explain the outcome later.

Finally, check the marketing and analytics paths. A closed account that continues receiving personalised campaigns may reveal a missed system or purpose. The strongest deletion design connects the customer’s request with actual treatment across the business, while making lawful limits clear before the customer relies on an overbroad promise.