Closing a Data-Processing Contract When Backups Cannot Be Deleted Immediately

Ending a supplier relationship that involves personal data is rarely as simple as pressing delete. The live account may close while copies remain in backups, archives or a subprocessor environment. That does not let the supplier keep personal data indefinitely or make a vague deletion assurance enough.

Under the UK GDPR, the controller chooses return or deletion of all personal data when processing services end. The processor must also delete existing copies unless domestic law requires storage. The ICO recognises that backup deletion may not be immediate, but only with appropriate safeguards, an appropriate retention period and subsequent deletion as soon as possible.

For businesses in England and Wales, a clear exit plan should distinguish live data from residual backup copies, cover subprocessors and record what was actually done. This guide explains those decisions and the contract terms that support them.

What does the UK GDPR require when processing services end?

The key rule sits in Article 28 of the UK GDPR. Your processor contract must say that, at the controller's choice, the processor will either delete or return all personal data after the end of the provision of services relating to processing. It must also say that the processor will delete existing copies unless domestic law requires storage of the personal data.

That wording matters for two reasons.

First, the decision belongs to the controller. If your business is the controller, the supplier should not decide for itself whether it will return data, retain it for convenience or simply issue a standard deletion certificate. The processor contract should leave that choice with you.

Second, the rule covers more than the main working dataset. It refers to all personal data being processed and to existing copies. In practice, that pushes the exit discussion beyond the live production environment to backups, archives, exports, logs and subprocessor copies that contain the controller's personal data.

There is one legal exception built into Article 28(3)(g): if domestic law requires storage, the data may need to be retained for that reason. That is not the same as saying a processor may keep copies because deletion is inconvenient, because a policy says it prefers longer retention, or because the subscription has ended but the technical offboarding has not started.

It also helps to separate this issue from two other common questions:

• Ending processing services is not the same as cancelling a software subscription. Commercial termination steps may happen first, but the data position still needs to be dealt with properly.
• It is also not the same as responding to an individual's erasure request. Here, the question is what the processor must do for the controller when the service relationship ends.

Why backups are different from live data, but not exempt

Backups create a genuine operational problem. A processor may be able to remove access to live customer data quickly, yet still be unable to extract and delete a single customer's dataset from encrypted or system-wide backups without affecting the integrity of the backup process.

The ICO recognises that reality. The ICO's guidance on processor contract end provisions says it may not be possible for data in backups or archives to be deleted immediately on termination of a contract. However, that is a qualified position, not a free pass.

For delayed deletion of backups or archived data to be acceptable, the ICO says appropriate safeguards should be in place. One example is that the data is put immediately beyond use. The retention period must also be appropriate, and the data should then be deleted as soon as possible, such as on the processor's next deletion or destruction cycle.

That means a processor should be able to explain three things clearly:

• why immediate deletion is not technically feasible for those backup or archive copies;
• what safeguards apply while the copies remain in place; and
• when and how those copies will be removed through the ordinary deletion cycle.

What it does not mean is that all backups are automatically outside the contract exit obligation. Nor does it create a fixed number of days for deletion. The legal position is more practical than that: a justified delay may be acceptable, but only with safeguards, appropriate retention and later deletion as soon as possible.

If you are the processor, avoid broad statements such as "all backups are exempt" or "our internal retention policy overrides the contract". If you are the controller, avoid assuming that any mention of backups means the supplier is non-compliant. The real question is whether the backup treatment is narrow, justified and evidenced.

What should an exit plan cover in practice?

A good exit plan is more useful than a bare promise because it breaks the legal duty into operational steps. It should cover current copies, backup copies and any onward processing chain.

For live and accessible data, decide whether the processor will return it, delete it or do both in sequence. Many controllers want a structured export first, followed by confirmed deletion of the live environment after the transfer is complete. If data is returned, specify format, timing and whether any metadata, audit history or attachments are included.

For archived backups, ask for a separate treatment. The processor should identify whether the data remains only in immutable backups, disaster recovery sets or other non-live repositories. It should then state what "beyond use" means in its environment. That might include removing ordinary access, limiting restore rights, preventing routine business use and applying security controls until the next destruction cycle.

For subprocessors, ask whether any personal data was passed to hosting providers, support providers or other specialist service providers acting on the processor's behalf. Article 28 also requires equivalent obligations to be imposed on those subprocessors. From an exit perspective, that means the main processor should be able to coordinate return or deletion instructions down the chain and explain any backup limitations there too.

Useful contract and exit questions include:

• What categories of personal data are in scope at exit?
• What data will be returned to the controller, and in what format?
• What data will be deleted from live systems, and when?
• Which copies may remain temporarily in backups or archives?
• What safeguards apply while those copies remain?
• What is the relevant backup retention or destruction cycle?
• Do any subprocessors hold copies, including backup copies?
• Is any retention required by domestic law?
• What evidence will be provided after the exit steps are carried out?

If these points are dealt with only after termination, negotiations can become rushed. It is often better to build them into the Data Processing Agreement at the start, then revisit them when exit is approaching.

A realistic exit example

Imagine a retail business uses a customer support platform to handle complaint records, order queries and account notes. The platform provider acts as processor. The retailer decides to move to a new supplier and gives notice to terminate.

The contract says that at the end of processing services, the retailer can choose return or deletion of personal data. The retailer asks for a full export of open and closed ticket data, attached documents and user account history. It also instructs the processor to delete the live workspace once the export has been checked and received.

The processor confirms it can remove the live workspace and active database copies. It also explains that encrypted disaster recovery backups are created at system level and cannot be edited customer by customer. Those backups are not available to ordinary support staff, are retained only for a defined operational period and are overwritten or destroyed in the normal cycle. Pending that cycle, the processor states the data will be beyond ordinary use and kept subject to its security controls.

The retailer then asks a few sensible follow-up questions. Are any subprocessors hosting or replicating backup copies? Can the processor confirm that no restored copy will be used again for ordinary service delivery? What evidence will be provided once the live deletion is complete, and later when the relevant backup cycle has run?

That exchange is stronger than a one-line certificate saying "all data deleted". It identifies the difference between current data and backup data, preserves the controller's choice, and leaves an audit trail showing what the processor could delete immediately and what would be removed later.

What evidence should you ask for at the end?

Article 28(3)(h) requires the processor to make available the information necessary to demonstrate compliance with Article 28 and to allow for and contribute to audits and inspections by the controller or its mandated auditor. That does not mean every exit needs a formal audit, but it does support a sensible request for evidence.

For many SMEs, proportionate evidence at exit may include:

• a written confirmation of whether data was returned, deleted or both;
• confirmation that live systems and accessible copies were dealt with;
• an explanation of any backup or archive copies that remain temporarily;
• the safeguards applied while those copies remain;
• the applicable deletion or destruction cycle; and
• confirmation that subprocessor instructions have been issued or completed where relevant.

In some arrangements, particularly where the processing is sensitive or business critical, a controller may also want system logs, a copy of the destruction procedure, or an audit right that can be used where there is a genuine concern.

The key point is that evidence reduces uncertainty, but it is not a guarantee that no trace of data could ever exist anywhere in a complex technical estate. A deletion certificate can be helpful, but on its own it may say very little. What matters is whether the evidence matches the actual data flows and the processor's architecture.

Likewise, if you are the processor, avoid promising absolute technical outcomes that you cannot verify. It is better to describe accurately what has been deleted, what remains only in safeguarded backups, and when final deletion will occur.

How should contracts deal with delayed backup deletion?

The best drafting usually combines a clear legal obligation with a practical mechanism.

The legal obligation should reflect Article 28(3)(g): controller choice, return or deletion of all personal data after the end of services, deletion of existing copies, and the domestic-law storage exception.

A clear data retention policy can support the operational process, but it does not replace the statutory assessment or the contract. The practical mechanism should then explain how exit works operationally. For example, the contract might set out the return format, the period in which export access remains available, the deletion method for live systems, the treatment of archived backups that cannot be deleted immediately, and the evidence the processor will provide.

It can also help to define responsibilities during transition. If the controller must download data before the account closes, say so. If the processor will only hold returned exports available for a short period, make that clear. If deletion instructions must be given in writing by an authorised contact, include that process.

For subprocessors, the contract should require equivalent data protection obligations to flow down and should make clear that the main processor remains responsible to the controller for that chain. At exit, that supports a cleaner instruction route and avoids a situation where the controller is told to chase multiple technical providers separately.

Even well-drafted clauses are not magic. They improve accountability and reduce room for argument, but they do not guarantee perfect execution. You still need offboarding steps, named owners on each side and records of what was completed.

FAQ

Can a processor keep backup copies forever if they are never restored?

No. The ICO's position is not that backups can be retained indefinitely. The retention period must be appropriate, appropriate safeguards must be in place and the data should be deleted as soon as possible, for example on the next deletion or destruction cycle.

Does the controller always have to choose deletion rather than return?

No. Article 28(3)(g) gives the choice to the controller. Depending on the circumstances, the controller may want return of the data, deletion, or a managed sequence where data is returned first and live environments are deleted afterwards.

Is a processor allowed to rely on its standard retention policy instead of the contract?

Not simply because it is standard. The contract needs to reflect the UK GDPR position, and any retention beyond the end of services must fit within the legal framework. A processor cannot treat its internal policy as a substitute for the controller's contractual rights or for a domestic-law storage requirement.

Do subprocessors need to be part of the exit discussion?

Yes, where they process the controller's personal data on the processor's behalf. Practical exit planning should cover whether subprocessors hold live copies, archived copies or backup copies, and how return or deletion instructions will be passed down.

Is a deletion certificate enough on its own?

Usually not. It may form part of the evidence pack, but it is better to ask for details showing what was deleted immediately, what remains temporarily in backups, what safeguards apply and when later deletion is expected.

Key Takeaways

• Article 28(3)(g) starts with the controller's choice to require return or deletion of all personal data at the end of processing services.
• The processor must also delete existing copies unless domestic law requires storage.
• Backups and archives are not automatically exempt, but immediate deletion may be impractical if appropriate safeguards apply, retention is appropriate and deletion follows as soon as possible.
• Exit planning should distinguish live data, backup data and subprocessor-held data rather than relying on a one-line deletion promise.
• Evidence matters, but no document alone guarantees technical erasure across every system. Clear clauses, realistic processes and records of execution are all part of managing the risk.

If you are reviewing a processor agreement, negotiating exit wording, planning a supplier offboarding or checking backup and subprocessor obligations, Sprintlaw's legal team can help. Call 08081347754 or email team@sprintlaw.co.uk to discuss your data-processing contract, privacy compliance and contract exit documents.