What happens to licensed data when a contract ends: the destruction clause

What happens to licensed data when a contract ends is settled by one clause, usually headed return or destruction, and by how far it reaches into the copies your systems made during the term. This guide sets out what such a clause asks, what it tends to leave standing (backups, records kept by law, derived data and models), and how a data team finds every copy, removes it and proves the removal. It reports what a published template, open licences and official guidance say. None of it is legal advice: each clause point is a drafting point or a question for your counsel.

The uses a data licence grants are set out in what a data licence covers. This guide works through one line of that post: what must be deleted at the end of the term.

What the destruction clause says happens to licensed data when a contract ends

When a data licence ends, the agreement decides what happens to your copies. A destruction clause typically ends your right to use the data and tells you to remove or return every copy within a set number of days, often with written confirmation. Its wording on backups, records kept by law, derived data and models decides what you may keep.

Read a draft clause for five parts: the trigger (expiry, termination by either side, the end of one subscription among several), the object (delivered files only, or every copy, extract and reformatting), the action (return, delete or destroy), the deadline, and the proof.

A published template shows the parts at work: the Data Subscription Agreement for AWS Marketplace, AWS's optional standard contract for data products on AWS Data Exchange, in a file dated 14 July 2022. Its section 8.5 says, in summary:

• On termination or expiry of a subscription or of the agreement, the subscriber's authorisation to use the data ends.
• Within 90 calendar days the subscriber removes the data from the AWS infrastructure used under its own account and from any other computer systems operated by it or for it.
• The subscriber destroys all other copies if the provider instructs it to.
• The sections on proprietary rights and confidentiality are among those that survive the end of the agreement.

The same template defines derived data separately, as what is derived from or created by or for the subscriber using the data, unmodified data excluded. Section 8.5.1 names no backup, no certificate and no record the subscriber must keep by law: those are points for a negotiated agreement.

Losing access is a separate event. The AWS Data Exchange user guide says that once a subscription expires you immediately lose access to the product's data sets and APIs. Copies you exported earlier are yours to remove.

Termination of a licensed data contract: deletion and return obligations

Deletion and return obligations at termination come from the words of the agreement, and published texts differ widely. The commercial template above sets a removal deadline. The open licences in the table end the rights and order no deletion. The EU's standard clauses for transfers of personal data require deletion with a certificate, or return, at the exporter's choice.

Three ideas appear: an end to permission, a duty to remove, and proof with a rule for law that forbids deletion. The standard contractual clauses govern personal data and serve here as a published model of the third. Check that a draft states each.

What the industry debate adds on models and outputs

In March 2026 the Alternative Data Council of FISD, the Financial Information Services Division, published version 1.0 of a buy-side paper, Understanding Investment Firms' Use of Licensed Data with GenAI. It says that vendors have traditionally required deletion of raw licensed data when an agreement expires, and that some now seek duties reaching model artefacts. Its position is that requiring a customer to retrain models or recalculate outputs only to remove past use of a vendor's data is commercially impracticable, can compromise audit trails and may conflict with regulatory record-keeping requirements. That is the buy side speaking, and a vendor may hold another view.

Where licensed data ends up, and what the clause means for each place

Use these ten places as the skeleton of an exit inventory.

Removing a copy: recovery windows and the official definition of sanitising media

A delete statement is where removal starts. Managed platforms keep deleted data recoverable for a documented period, and each period belongs in your timetable.

For the storage underneath, a public reference is NIST Special Publication 800-88 Revision 2, Guidelines for Media Sanitization, of September 2025. It defines sanitising as rendering access to target data on the media infeasible for a given level of effort, by one of three methods:

• Clear. Logical techniques on all user-addressable storage locations, against simple, non-invasive recovery.
• Purge. Physical or logical techniques that make recovery infeasible with state-of-the-art laboratory techniques and leave the media potentially reusable.
• Destroy. Recovery is infeasible by the same measure, and the media can no longer store data.

For logical or virtual storage such as cloud storage, it says cryptographic erase, which sanitises the keys that encrypt the data, may be the only viable purge technique, because the data owner typically has no direct access to the physical media. It cites a precondition from ISO/IEC 27040: no sensitive data was earlier stored there unencrypted. A clause that says destroy and names no standard leaves the method open.

Backups

The UK Information Commissioner's Office, in its guidance on the right to erasure of personal data, says a valid erasure request with no exemption requires steps to ensure erasure from backup systems as well as live systems, that data may remain in a backup environment until it is overwritten, and that the key issue is to put it "beyond use": used for no other purpose and held only until replaced on an established schedule. The ICO marks that guidance as under review after the Data (Use and Access) Act. A licence clause can borrow the idea for licensed rows: no restore outside disaster recovery, no other use, and expiry on the existing schedule by a stated date.

Records kept by law

FINRA's summary of the books and records rules for US broker-dealers says FINRA Rule 4511 requires firms to preserve for at least six years those FINRA books and records with no specified retention period, and that an electronic recordkeeping system under Exchange Act Rule 17a-4 must keep a complete time-stamped audit trail or preserve records exclusively in a non-rewriteable, non-erasable format. Ask counsel which of your records, if any, hold licensed values under a rule of this kind, and name them in the clause.

How to find every copy and prove it is gone

Lineage is the record of which tables, files and models were built from which. It turns a clause about the data into a list of objects, and the guide to governing licensed data with Unity Catalog shows it on one platform.

1. Build the delivery register: every bulk export and every API key that pulled the data, with periods and dates.
2. Walk the lineage downstream from each landing location: every table, view, extract, index and model that reads from it.
3. Search for what lineage misses: the vendor's company key and dataset names in every catalogue, and extracts held outside managed systems.
4. Classify each object: a copy of rows, a table holding copied values, an output computed from rows, or a copy held by someone else.
5. Stop the feeds, then delete from the furthest copy back to the landing files, so no pipeline rebuilds what you removed.
6. Close the recovery windows and note the date each one ends.
7. Instruct service providers and recipients in writing, and file their confirmations.
8. Verify by repeating steps 2 and 3, then certify.

NIST's guideline says a certificate of sanitization should be completed for each sanitised medium, with details that include its manufacturer, model and serial number, the method and technique, the tool and its version, the verification method, and who verified and validated, with dates. A certificate for a data licence works at the level of datasets and systems:

• the datasets and periods covered, from the delivery register
• each object removed, with its system, method and date
• the date each recovery window and backup cycle ends
• exceptions, each with the clause relied on
• confirmations from providers and recipients
• who verified, who approved, and when

An illustrative example: Acme Robotics exits a licence

This example is illustrative. Acme Robotics is an invented company, and the clause, systems and dates are invented to show the method. The clause is taken from no agreement and is not a recommended form.

Assumptions:

• Acme Robotics licenses Technology Changes and Hiring Activity for internal use. The agreement began on 1 April 2025 and expires on 31 March 2027.
• The clause: delete every copy within 60 days of expiry; backups may expire on their schedule, unrestored, no later than 180 days after expiry; certify in writing within 10 days of the deletion deadline; outputs that reproduce no licensed values may be kept.
• The warehouse keeps a dropped table recoverable for 30 days of time travel and a further 7 days of fail-safe.
• Backups copy live tables only. Nightly backups are kept 35 days. A monthly backup is taken on the first of each month and kept 12 months.
• Lineage and a catalogue search find 14 objects: 2 landing locations, 4 raw tables, 3 staging tables, 2 enriched tables, 1 dashboard extract, 1 table of account scores and 1 model.

Working:

1. Deadline. Sixty days after 31 March 2027: 30 days reach 30 April, 60 reach 30 May 2027.
2. Warehouse. A dropped table stays recoverable for 30 + 7 = 37 days. Back from 30 May, 30 days reach 30 April and 7 more reach 23 April. Tables must be dropped by 23 April 2027, 23 days after expiry.
3. Nightly backups. The last one holding the rows is taken on 22 April and expires 35 days later, on 27 May (8 days to 30 April, then 27), inside the deadline.
4. Monthly backups. The last one holding the rows is taken on 1 April 2027 and expires on 1 April 2028. Day 180 after expiry is 27 September 2027 (30 April is day 30, 31 May day 61, 30 June day 91, 31 July day 122, 31 August day 153). On that date the backups of 1 October 2026 to 1 April 2027 are still held: 7 backups hold licensed rows past the limit.
5. Objects. 2 + 4 + 3 + 2 + 1 = 12 hold licensed values and are deleted. The account scores and the model reproduce none and are kept: 12 + 2 = 14.
6. Certificate. Ten days after 30 May is 9 June 2027.

Result: two findings to act on before signing. The 60-day deadline is a 23-day deadline for the warehouse. The monthly backup cycle cannot meet a 180-day limit: Acme Robotics either deletes the 7 monthly backups early or asks for the limit to run to 1 April 2028, 367 days after expiry.

Where Fokals deliveries fit an exit inventory

We license Fokals data by written agreement, for internal use, embedding in a product or redistribution, and deliver it by REST API and as bulk exports. A bulk export can come as a package of files with a manifest naming its period, its versions and its licence, so a folder of manifests is a delivery register from the first load. Every dataset that describes a company carries the stable Fokals company ID, one key for the search in step 3. Daily and weekly datasets are written once and never revised, so a deletion scoped by dataset and period names the same rows when it is certified as when they were delivered. The delivery page sets out both routes.

Frequently asked questions

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.