How to verify that a buyer deleted your data

The verification ladder: from attestation to technical evidence#

The verification ladder runs from a buyer's word to evidence you can check yourself, and each rung adds assurance and effort. No rung lets you watch another company's systems directly, so the realistic goal is an accountable signer at minimum and independent confirmation where the package warrants it.

Match the rung to the package. A de-identified set of order exceptions calls for less than a package carrying customer names or source code, and many licenses combine the first two rungs by default while reserving the third and fourth for higher-risk packages or for cause.

Pick the rung when you scope the package, not when the term ends. A buyer that agreed to an audit right at signing will expect it; one asked for an audit after the fact may reasonably refuse.

Where copies hide inside a licensee#

Copies hide wherever data was moved, transformed or backed up after delivery, and a credible certificate names each location. Ask for the licensee's data handling map at signing, so you know what the certificate should cover when the time comes.

Backups need explicit handling. Purging one dataset from backups is often impractical, so licenses commonly let backups expire on their normal cycle, as long as nobody restores the data or reads from those backups before they expire.

• 1The delivered package itself: drives, download folders and landing buckets.
• 2Working copies in storage used for cleaning, filtering or labeling.
• 3Derived datasets, such as tokenized, deduplicated or reformatted versions of your records.
• 4Evaluation and test sets carved out of the package.
• 5Copies held by contractors, labeling vendors or permitted sub-licensees.
• 6Backups and snapshots that roll off on their own schedule.
• 7Exports on laptops or in notebooks used by individual researchers.

What a deletion certificate should contain#

A deletion certificate should let someone who never saw the deal match it to the license and to the delivery. Vague certificates that say only that all data has been deleted are common, and they are hard to rely on when a question surfaces years later.

Send the buyer the element list below with the deletion notice. Asking for a specific format up front is easier than chasing missing details after a certificate arrives.

Trained models are a separate question#

Trained models are a separate question from deleted copies because a model stores patterns learned from your records rather than the records themselves, so there is no file to point at and erase. Retraining without your package is the only certain way to remove its influence, and that has to be negotiated explicitly rather than assumed.

Decide what you need before signing. Options include letting models trained during the term survive, barring new training after the term ends, requiring retirement of models built mainly on your package, or limiting outputs that reproduce your records. Whatever the choice, the certificate should state it as a named exception rather than leave it unsaid.

Technical evidence you can check yourself#

Technical evidence is strongest when the supplier, not the buyer, controls what makes the data readable. If the buyer works on data kept in your storage through scoped, expiring credentials, ending access is something you do and log yourself.

Key-based approaches work the same way for copies that stay encrypted. When a package is delivered encrypted and the key sits in a key management service under your control or in escrow, revoking or destroying the key leaves those copies unreadable, and the service's logs show when it happened. Decrypted working copies are not covered, so they still need deletion and a line in the certificate.

Where the buyer's systems produce them, ask for supporting logs alongside the certificate: storage deletion events, retention policy changes and the ticket from the team that ran the deletion.

Illustrative: a consulting firm closes out a license#

Illustrative: a fictional management consulting firm licensed a de-identified package of proposals, project review notes and internal playbooks for a fixed term. The license required a certificate of destruction at term end and gave the firm an audit right exercisable for cause.

When the term ends, the firm's general counsel sends a deletion notice quoting the package identifier. The certificate that comes back lists the landing bucket, two derived datasets and a labeling contractor's copy, says backups expire on the buyer's normal cycle, and records that models trained during the term survive, as the license allowed.

Counsel compares the certificate with the data handling map from signing, notices that an evaluation set is missing, and asks for a corrected certificate rather than invoking the audit. The corrected version is filed with the license and the release authorization.

How SourceX approaches deletion verification#

Deletion terms and the level of proof are settled at Approval, the fourth stage of the SourceX five-step transaction, so they are fixed before Delivery. The supplier decides what proof each package needs, and large datasets can stay in the supplier's own storage, which keeps access under the supplier's control.

Permitted use and release authorization in the SourceX Evidence Packet record what the buyer may do with the package and for how long, which gives the deletion certificate a clear reference point when the term ends.