What raw data deleted should mean in a contract

Almost every data licence includes a promise that raw data will be deleted. The phrase sounds complete, but it leaves a lot open: which data, deleted from where, by when, and how anyone would know. A good clause answers each of those questions in writing.

This is general information, not legal advice. Any contract you sign should be reviewed by your own counsel.

In a data licence, there are usually two versions of your data. The raw archive is what was pulled from your tools during the evaluation: real names, real email addresses, real customer details. The delivered dataset is what remains after anonymization, where every person, company, address, email, phone number and account has been replaced with a consistent token, and credentials and other sensitive items have been removed.

The buyer licenses the delivered dataset for training and evaluation. The raw archive exists only so that anonymization can be done and checked. Once that work is finished and you have signed off on it, there is no reason for the raw archive to exist. A deletion clause should say so explicitly, so nobody treats the raw copy as something worth keeping.

Start with when the obligation begins. "After delivery" and "after the licence ends" can be months or years apart. A cleaner trigger is the seller's sign-off on the anonymized output, because that is the moment the raw data stops being needed.

Then set a deadline. Our own commitment is deletion within 30 days of sign-off, written as a contract obligation rather than a policy statement. A policy can change; a contract term cannot change without your agreement. Whatever the window, it should be a number of days, not "promptly" or "in due course".

Raw data rarely lives in one place. Copying, processing and checking it creates other copies along the way. A clause that says the raw archive will be deleted should make clear that it covers all of them:

• The primary archive pulled from your tools
• Working copies created during anonymization and quality checks
• Intermediate files, caches and staging areas
• Exports or extracts made for internal review
• Backups and snapshots that contain raw content
• Logs that captured raw text, such as error logs that include message bodies

Backups deserve a sentence of their own. Some backup systems cannot remove a single dataset on demand and instead expire on a schedule. If that applies, the contract should say so and state when the last backup containing raw data will expire.

It also helps to know who else might hold a copy. In our process, no third party touches raw data, which keeps that list short. Where a provider does use subcontractors or outside services, the clause should extend to them and the provider should be responsible for their deletion too.

A deletion certificate turns a promise into a record. It is worth agreeing its contents in advance, so you are not left with a one-line email. A useful certificate states:

• Which data was deleted, referring to the scope annexed to the contract
• The date deletion was completed
• The locations covered, including backups and working copies
• The method used, described in plain terms
• Who is certifying it, by name and role

Keep it with the licence agreement. If a director, auditor, acquirer or liquidator later asks what happened to the company's raw data, that document is the answer. For a company that is winding down, it can also go into the closing file.

A few situations come up often enough that they are better handled in the contract than left to goodwill.

Re-processing is the first. If you find a problem in the anonymized sample and something has to be redone, the deletion clock should run from your final sign-off, and the clause should say so. That removes any ambiguity about whether raw data can be kept "just in case" after the work is done.

Legal holds are the second. Occasionally a legal obligation requires data to be preserved. The contract can say that if this happens, the provider will tell you, keep the data only as long as required, and delete it afterward under the same certificate process.

Lookup tables are the third, and the one most often missed. Consistent tokenization means that, during processing, some link exists between each token and the real identity behind it. Ask how that link is handled, and make sure it falls under the same deletion obligation as the raw archive. Once it is gone, the tokens in the delivered dataset no longer point back to anyone. Re-identification risk and how to reduce it covers why this matters.

Finally, think about who receives the certificate. If the company is closing, it may need to go to a liquidator or assignee rather than the founders who signed. Naming the recipient in the contract saves a search later.

Deletion terms are easy to skim because they concern what happens after the deal is done. They are also the terms that decide how much of your data exists in the world a year from now. A clear trigger, a fixed deadline, a complete list of locations and a specific certificate are not demanding asks, and a provider that handles raw data carefully should be comfortable agreeing to all four.

Our full approach to anonymization and deletion is set out on the trust page. If you would like to see how these terms read in an actual licence, book an intro call.