Exit data provisions are among the easiest clauses to agree and the hardest to enforce. Both parties accept the principle immediately: on termination, the customer gets its data back and the vendor deletes what it holds. The clause is short, uncontroversial and signed. Years later, at termination, the customer asks for its data and discovers that the clause answers almost none of the questions that actually matter.
Which data is in scope? The records the customer uploaded, clearly, but also configuration, audit logs, support tickets, derived analytics, models trained on customer data and aggregated statistics. In what format? A vendor can satisfy a bare return obligation with PDF exports or a proprietary dump nothing else reads. From which systems? Production, certainly, but backups run on their own retention cycles, archives may sit in cold storage, and subprocessors hold copies the vendor has to reach. And proved how? Most clauses require no evidence at all, which makes deletion an assertion.
None of this indicates bad faith by vendors. Deletion across production, backup, archive and subprocessor estates is genuinely hard, and a vendor asked to do it with no defined scope will do the straightforward part. The customer’s leverage to require more exists at signature and disappears at termination, which is exactly the wrong way round unless the clause was written properly the first time, which is the same asymmetry behind auto-renewal clause risk in enterprise SaaS contracts.
What an exit data clause has to specify
The elements below are the ones that convert a principle into a deliverable. Each corresponds to a place where a bare clause fails.
- Data scope, enumerated, customer-submitted data, configuration and metadata, logs, support records, derived and aggregated data, and any models or indices built from customer data.
- Return format and mechanism, a named structured format with a schema, delivered by a specified mechanism, with a defined window and a size-appropriate method for large volumes.
- Deletion deadline and trigger, the period for deletion and what starts it, typically confirmed completion of return rather than the termination date itself.
- Backup, archive and permitted retention, how backup and archive cycles are handled, any retention permitted by law with its basis and duration, and what protections apply to retained copies.
- Subprocessor flowdown and evidence, the vendor’s duty to procure deletion by subprocessors, and a certificate of destruction identifying systems, scope, method and dates.
Each of those is a tracked obligation at exit, with a date and an owner on both sides. Treating them as one clause to be invoked is how exits run long: the return happens, the deletion is asserted, the certificate never arrives, and the customer closes the file anyway because the project has moved on. Teams working through SaaS vendor contract sprawl hit this at every consolidation.
A deletion deadline running from the termination date pressures the vendor to delete before the customer has verified that the returned data is complete and usable. Anchor deletion to the customer’s written confirmation that return is complete, with an outer backstop date so confirmation cannot be withheld indefinitely. That sequence protects both parties.
Where exit data obligations fail
These are the recurring failures, in rough order of how often they cause a problem.
- Format is unspecified so exports are unusable. A return obligation without a named format and schema is commonly met with proprietary dumps or PDFs that cannot be loaded into a successor system.
- Backups outlive the deletion deadline. Production deletion happens; backup and archive copies persist through their retention cycle. Without explicit treatment, the vendor has complied literally and the data still exists.
- Derived data is excluded by silence. Analytics, indices, embeddings and models built from customer data are frequently treated as vendor property unless the clause names them.
- Subprocessors are out of reach. The vendor cannot evidence subprocessor deletion because its own subprocessor agreements lack the flowdown, which is the same gap one tier down.
- No evidence is required. Without a certificate identifying systems, scope, method and dates, the customer has a statement. With one, it has a record that can be tested and relied on.
A five-step roadmap to make exit data duties real
Step 1, Write the data scope list into the template
Enumerate the categories in scope in your standard terms rather than negotiating scope at each contract. A named list, referenced by the clause, can be updated without amending live agreements.
Step 2, Specify format, schema and mechanism
Name the return format and require a schema or data dictionary, with a delivery mechanism appropriate to volume. For high-volume services, require a documented export capability rather than a best-efforts extract.
Step 3, Sequence return before deletion
Anchor the deletion clock to confirmed completion of return, with an outer backstop. Require the vendor to hold data intact until that confirmation, and require the customer to confirm within a set period.
Step 4, Address backups, archives and permitted retention
Require deletion from backups within their retention cycle with a stated maximum, require identification of any legally retained data with its basis and duration, and require access controls on retained copies.
Step 5, Require and track the certificate of destruction
Specify the certificate content: systems covered, data categories, deletion method, dates, subprocessors included, and signature by an accountable officer. Track it as a dated exit obligation with an owner who closes the file only when it arrives.
Track exit data duties to a closed certificate
Aavenir turns return, deletion, backup and certificate duties into dated exit obligations with owners and evidence attached.
Why this matters more as AI enters the stack
Derived data used to be a marginal category: indices, caches, aggregated statistics. It is no longer marginal. Where a vendor uses customer data to train, fine-tune or ground a model, deletion of the source records does not remove the customer data’s influence from the resulting artefact, and the practical question of what deletion means changes shape. Contracts are beginning to address this directly, by restricting training use at the outset, by requiring that derived artefacts built on customer data be deleted or that the customer’s contribution be excluded from future versions, and by requiring disclosure of what derived artefacts exist. Customers negotiating exit data terms now should decide their position on derived artefacts at signature, because there is no realistic remedy at termination. Vendors adopting contract lifecycle management for hi-tech and software increasingly hold a standard position on derived artefacts so deal desk does not negotiate it from scratch.
Exit data obligation reference
The table sets out each duty with the specification required and the evidence that closes it. Terms should be tailored to the service, the data sensitivity and the applicable data protection framework.
| Exit duty | What to specify | Evidence | Owner |
|---|---|---|---|
| Data return | Scope list, format, schema, mechanism, window | Delivered export plus completeness confirmation | Customer service owner |
| Production deletion | Deadline from confirmed return, method | Certificate of destruction naming systems | Vendor security officer |
| Backup and archive deletion | Maximum period, retention cycle treatment | Certificate covering backup estate with dates | Vendor security officer |
| Subprocessor deletion | Flowdown duty, list of subprocessors covered | Vendor certificate confirming subprocessor scope | Vendor contract owner |
| Permitted retention | Legal basis, data categories, duration, controls | Retention schedule with basis stated | Customer privacy owner |
Exit data provisions are a textbook case of leverage timing. Everything a customer needs, meaning enumerated scope, a usable format, backup treatment, subprocessor flowdown and a certificate of destruction, is straightforward to obtain at signature and effectively unobtainable at termination. The clause costs a page. Not having it costs an exit that ends with unusable exports, an asserted deletion and a file closed on trust. Track the duties as dated exit obligations and close the file on the certificate, not on the assurance.
For related guidance, see Open source license clauses in customer contracts, When the order form and the MSA disagree and Capacity reservation clauses in semiconductor supply deals.
