A customer asks to delete their data after delivery: what happens next?

The short answer depends on what you delivered#

A deletion request after delivery is handled in one of two ways, depending on whether the delivered package can still be linked to the person. Your own obligations come first either way: verify the request and delete the person's data from your systems under your normal process.

If the package was de-identified, the delivered records generally cannot be connected to the requester, so there is nothing for the licensee to locate. If the package kept identifiers, or replaced them with codes someone can reverse, the request reaches the licensee through the contract. The table sets out the common cases.

Why de-identified deliveries are out of reach#

De-identified deliveries are out of reach of a deletion request because the data no longer relates to an identifiable person once identifiers are removed and the recipient is bound not to re-identify. Many state privacy laws may treat properly de-identified data as outside the definition of personal data, though the exact test differs by law and counsel should confirm it.

Do not try to find the requester inside a de-identified package. Building a lookup to locate them would mean re-identifying data the contract says must stay anonymous, recreating the very link that preparation removed. Record instead that the package was checked against the license's de-identification standard and held no linkable data.

One caution applies. If your team kept a mapping table from placeholder tokens back to real customers, the package is pseudonymized rather than de-identified, and the request follows the identifiable path.

How flow-down works when identifiable data went out#

Flow-down is the contract mechanism that passes a deletion request from the supplier to the licensee, and from the licensee to anyone it was permitted to share with. Without the clause, the supplier is asking for a favor; with it, the licensee is obliged to act.

Some state privacy laws, California's among them, may also expect a business to pass deletion requests on to parties it disclosed the data to, with exceptions where that is impossible or would take disproportionate effort. Which laws apply, and whether a given license triggers them, is assessed with counsel, but a flow-down clause covers the practical need either way.

• 1A duty to delete identified records within a defined period after written notice.
• 2A secure channel for sending the minimum identifiers needed to locate the records.
• 3Deletion across working copies and caches, with backups cleared on their normal cycle.
• 4Written confirmation once deletion is complete.
• 5The same obligation passed to any permitted sub-licensee or processor.
• 6Clear treatment of models already trained on the data.

Step by step after the request arrives#

The process after a post-delivery deletion request runs from your intake to the licensee's confirmation, and each step leaves a record. A fixed sequence keeps the privacy team, the deal owner and the licensee working from the same facts.

Step 3 is where most teams stall. A delivery register that records each package, its source systems, date range, de-identification method and recipient turns a long search through old emails into a quick lookup.

• 1Step 1: verify the requester's identity and the scope of the request.
• 2Step 2: delete or suppress the person's data in your own systems.
• 3Step 3: check the delivery register for packages drawn from systems that held the person's records.
• 4Step 4: confirm whether each package was de-identified, pseudonymized or identifiable.
• 5Step 5: for identifiable or pseudonymized packages, send a flow-down notice through the agreed channel.
• 6Step 6: receive and file the licensee's written confirmation.
• 7Step 7: add the person to the suppression list for every future delivery.
• 8Step 8: respond to the requester within the period the applicable law sets.

What to put in the license before the first delivery#

The license should settle post-delivery deletion before any data moves, because negotiating it after a request arrives is slow and leaves the supplier with little leverage. The clauses are short and most licensees expect them.

The trained-model clause deserves attention. Removing one person's influence from a model already trained is generally impractical, so contracts usually separate deleting dataset copies from obligations about models, and a supplier licensing identifiable data should negotiate that line knowingly.

Illustrative: a former user writes in after a support archive was licensed#

Illustrative: a fictional B2B software company licensed a de-identified package of help desk tickets linked to engineering issues. After delivery, a former user at one of its customers emails the privacy inbox asking for all of their information to be deleted.

The privacy lead verifies the request, removes the user from the help desk, the CRM and the product database, and checks the delivery register. The register shows the package met the license's de-identification standard, with names, emails and account numbers replaced, ticket text reviewed and no mapping table kept.

The company records that the delivered package holds no linkable data, adds the user to the suppression list for the next delivery and confirms deletion to the requester. No identifiers go to the licensee, because sending them would only create a new link.

How SourceX prepares for post-delivery requests#

SourceX plans for deletion requests before Delivery, the last stage of the SourceX five-step transaction. During Preparation the supplier approves the de-identification standard, and the license records whether any identifiable fields remain and how flow-down works if they do.

The SourceX Evidence Packet holds the privacy record and permitted use for each package, which gives the supplier the facts it needs when a request arrives. How a particular deletion law applies is assessed deal by deal with counsel.