Offboarding is the stage of the vendor lifecycle that receives the least attention and creates some of the most durable exposure. The contract ends, the invoices stop, and the data frequently stays: in the production system for a grace period, in backups for longer, and in a support tool or analytics platform nobody thought to include in the termination notice.
Article 28(3)(g) of the General Data Protection Regulation (GDPR) requires that, at the controller's choice, the processor deletes or returns all personal data after the end of the provision of services, and deletes existing copies unless European Union or member state law requires storage. This article covers how to make that obligation operate and what evidence to keep.
Decide return or deletion before you need it
The choice is yours, and it should be made deliberately rather than defaulted. Return is appropriate where you need the data for continuity, migration, or a legal hold. Deletion is appropriate where you do not, and it is generally the lower-risk option because retained exports create their own obligations.
Where you choose return, settle the format and the mechanism early. An export delivered in a proprietary structure you cannot use is a technical satisfaction of the clause and a practical failure. Ask for a documented, machine-readable format and confirm that it includes the fields you actually need.
Map everything the vendor holds
The common offboarding error is treating "the data" as one thing. A software vendor typically holds your personal data in several places, and a termination request aimed at the primary system leaves the rest untouched.
Ask specifically about:
- The production database.
- Backups and disaster recovery copies, with their retention cycles.
- Log files, telemetry, and error reports.
- Support tickets and their attachments, which frequently contain personal data pasted by your own staff.
- Analytics and product usage data derived from your records.
- Any data held by sub-processors in the chain.
- Copies held by the vendor's own staff, such as exports made during an implementation.
The sub-processor layer is the one that most often survives the termination notice. Article 28(4) requires the processor to impose the same obligations on the entities it engages, so deletion should propagate, but you should ask for confirmation that it did rather than assume it.
Backups are the honest difficulty
A carve-out for backup systems is common and, handled properly, reasonable. Immediate deletion from immutable backups is often technically impossible without destroying the recoverability the backups exist to provide.
What separates a workable clause from a defective one is boundedness. A workable backup carve-out states:
- The maximum period before backup copies expire.
- That the data will not be restored to active use during that period.
- That the same security measures continue to apply until expiry.
- That deletion from backups is confirmed once the cycle completes.
An open-ended carve-out with no expiry period is not a carve-out; it is an indefinite retention right. Our Data Processing Agreement review checklist treats this as a clause to resolve before signature rather than at exit.
Legal retention exceptions
The obligation to delete yields where European Union or member state law requires storage. Tax, accounting, and employment records are the usual cases.
Where a vendor invokes a retention requirement, ask which law, which data, and for how long. A general assertion that "regulatory requirements" prevent deletion is not sufficient, and the exception should be scoped to the specific records concerned rather than applied to the whole data set.
Get the evidence in writing
Deletion you cannot evidence is deletion you may have to argue about. Ask for a written confirmation that identifies:
- What was deleted or returned, by system and data category.
- When each step completed.
- The treatment of backups and the date by which copies expire.
- Confirmation that sub-processors have done the same.
- The name and role of the person confirming.
Retain that confirmation with the vendor file. It is the artifact that closes the relationship in your records, and it is the one most often missing when an organization is later asked what happened to a former supplier's copy of its data. Our articles on audit-ready vendor evidence and evidence retention cover how to hold it.
Close the record, not just the contract
Offboarding also has a records dimension. When a vendor leaves:
- Update the Article 30 processing record to remove the processing or mark it ended, with a date.
- Update the transfer records, since a destination may no longer be in use.
- Remove the vendor from monitoring watchlists and review cycles.
- Retain the historical record rather than deleting it, since accountability may require showing what the position was.
That last point matters. Removing a former vendor from your records entirely destroys the evidence that the relationship was governed properly. Mark it ended; do not erase it. Our article on keeping records accurate as vendors change covers the maintenance discipline.
A sequence that works
- Decide return or deletion, and confirm the format if returning.
- Issue the termination notice referencing the specific contractual clause.
- Send the system map and ask for confirmation against each item.
- Confirm the sub-processor position.
- Obtain and file the written deletion confirmation.
- Diary the backup expiry date and obtain final confirmation then.
- Update the processing and transfer records.
- Remove from monitoring and close the vendor file.
The diarised backup step is the one most often skipped, and it is the one that turns a partial deletion into a complete one.
Frequently asked questions
Can a vendor keep aggregated or anonymized data?
If the data is genuinely anonymized so that individuals are not identifiable, it falls outside the GDPR and the deletion obligation does not reach it. The question is whether the anonymization is real. Pseudonymized data remains personal data, and vendors sometimes describe the latter as the former.
How long should deletion take?
Set a deadline in the contract, typically counted in days from termination for active systems, with a separate stated period for backups. Clauses that say "within a reasonable period" provide nothing to hold a vendor to.
What if the vendor has already gone out of business?
Approach the administrator or successor entity, record your requests, and document the outcome. An unresolved position that you have evidenced and pursued is materially better than one you did not.
Does a free trial need offboarding?
If it processed real personal data, yes. Abandoned trials are a common source of forgotten copies.
Where DPAFlow fits in
Offboarding depends on knowing what the vendor's chain looked like while the relationship was live. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis and records what changed with dated evidence including captured page text and change differences, so the historical record of who held your data is preserved rather than reconstructed from memory at exit.
DPAFlow does not execute deletion and does not provide legal advice. The evidence model is described on the evidence page.
This article describes an offboarding process. It is not legal advice, and retention exceptions in particular should be confirmed with your counsel.