How backups complicate a customer deletion request

A deletion request becomes harder when the information has several copies. A business may hold a live database, replicas, exports, supplier records and recovery backups. The business needs a plan for those copies before promising a customer that everything has disappeared.

Backups create a practical tension. They support recovery after loss or corruption, but they may also preserve information removed from the live service. Treating that tension as an automatic exemption is unsafe. Treating every historical backup as instantly editable may be technically unrealistic. The response requires an explicit legal and operational assessment.

As of 22 October 2026, the main DPDP duties are scheduled for 13 May 2027 under the commencement notification. The approach below is preparation guidance, not a claim that the final law provides a general backup exception.

Distinguish a backup from an ordinary spare copy

Start by listing copies and their purpose. A restricted recovery snapshot differs from a spreadsheet that staff open for daily work. Calling the spreadsheet a backup does not change its active use or justify keeping it indefinitely.

Record where each copy sits, who can access it, how it is restored and when it expires or is overwritten. Include supplier-managed recovery arrangements. If the supplier cannot explain its retention and restoration process, the business cannot confidently describe its own deletion outcome.

A hypothetical training provider discovers that a former administrator’s monthly learner exports remain in a shared folder. Those files are not necessarily essential recovery media. They may be redundant operational copies that should be addressed directly through the ordinary retention process.

Apply the legal retention analysis to the data

Section 8(7) of the Act addresses erasure on withdrawal or the end of purpose, subject to retention needed for compliance with law, and relevant processor copies. Section 12 provides erasure rights for processing based on prior consent, including section 7(a), and allows retention where necessary for the specified purpose or compliance with law.

The final Rule 8(3) also 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 further lawful retention applies. Rule 6 has a separate security-related retention requirement.

These provisions need to be incorporated into the decision. Neither an indiscriminate “delete immediately” rule nor an indefinite “backups are exempt” rule captures the required analysis. Document the categories, purposes, applicable requirements and treatment of the relevant copies.

Control what happens during restoration

Suppose the provider removes a learner’s optional profile from the live system, then restores an older snapshot after a database failure. Without additional controls, the profile may reappear and be used again.

A recommended design is to maintain enough appropriately protected information to identify actions that must be reapplied after restoration. The exact method depends on the system and retention analysis. It should avoid preserving the entire deleted profile merely to remember that a request occurred.

Restrict restored environments until necessary corrections, restrictions and erasures have been reconciled. Test the process using suitable test data where possible. A written instruction that nobody has practised may fail during an urgent recovery.

Give suppliers specific questions

Ask whether deletion reaches live records, replicas and backups; how long recovery copies remain; who can restore them; and how the supplier prevents deleted information from returning to active use. Request the contractual commitments and operational evidence appropriate to the arrangement.

The future Rule 6 safeguards include continuity measures and contractual provisions concerning processors. These are reasons to examine recovery and supplier responsibilities together, not to assume that an availability requirement cancels erasure obligations.

If a supplier cannot perform a requested operation, escalate the limitation for an informed decision. Do not convert a technical inconvenience into a legal conclusion without examining the relevant obligations and possible alternatives.

Communicate the outcome with care

A completion message should distinguish live-system actions from any justified retained information and explain the applicable limitations plainly. Avoid the phrase “permanently deleted from everywhere” unless it is both legally and technically accurate.

Keep the request decision, relevant supplier responses, retention reasoning and evidence of implemented controls. Review the design when backup products or recovery processes change.

The aim is a system in which recovery does not silently reverse a valid data decision. That requires coordination between the person handling the request, the people operating backups and the owner responsible for retention, rather than leaving each team to make a different promise.