Leadership and readiness
A customer wants their records removed after delivery: what happens?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
When a customer wants its records removed after a dataset was delivered, the outcome depends on the license. Future deliveries are fully in your control: add the customer to a suppression list. Copies already delivered generally come back only if the agreement includes a removal-on-notice clause, so negotiate that clause before the first delivery, not after a request.
Key takeaways
- Future deliveries are fully in the supplier's control, and a suppression list keyed to account IDs keeps a customer out of every refresh.
- Copies already delivered can be pulled back only to the extent the license requires the licensee to delete on notice.
- Models already trained on the records are usually outside a removal clause unless the parties agreed otherwise in writing.
- A business customer's objection usually turns on its own contract with you, so counsel should read that contract before anyone replies.
- The cheapest time to settle removal mechanics is before signing, when the clause costs nothing to add.
What happens when a customer asks to be removed after delivery?#
A customer removal request after delivery reaches three separate things, and each follows different rules: the records you have not yet sent, the copies the licensee already holds, and any model the licensee has trained. You control the first completely. The other two depend on what the license agreement says.
Treat the request as three questions rather than one. Can we keep this customer out of everything we send from now on? Does the licensee have to delete what it already received? Does anything follow the records into trained models? Answering them separately keeps the reply accurate and avoids promising what the contract cannot deliver.
| Layer | Who controls it | What usually happens | Clause that decides it |
|---|---|---|---|
| Future deliveries and refreshes | The supplier | The customer's records are excluded from the next build | Scope and exclusions schedule |
| Copies already delivered | The licensee, under the contract | Deleted and certified if the license requires removal on notice | Removal-on-notice and certification |
| Working copies, backups and contractors | The licensee and its vendors | Covered only when the duty flows down | Flow-down and backup handling |
| Models already trained | The licensee | Usually unchanged; later training runs may exclude the records if agreed | Derived works and retraining terms |
A response sequence for legal and privacy teams#
A removal request is easiest to handle with a fixed response sequence that confirms the facts before anyone replies on the merits. The order matters: the first thing to establish is whether the customer's records shipped at all, and in what form, because preparation may already have removed or generalized them.
Run the steps below from one internal request log, and give the licensee only the identifiers it needs to act.
- Log the request: who asked, on whose behalf, the date, and exactly what they want removed.
- Check the manifest and privacy record for each delivery to see whether the customer's records shipped, and in what prepared form.
- Pull the customer agreement and the rights review file for that account, and send both to counsel.
- Add every identifier the customer has across systems to the suppression list so the next build excludes it.
- If the license has a removal-on-notice clause, send a notice that cites delivery IDs and record IDs.
- Collect the licensee's deletion certification and file it with the original request.
- Reply to the customer in writing with what was done, and avoid promises about trained models.
Check your own customer contract before you reply#
The customer contract decides how serious a removal request is, so counsel should read it before anyone answers the customer. A business customer that objects usually points to its master services agreement, order form or data processing addendum, and the wording of those documents determines whether its records belonged in scope at all.
If the contract permitted the use, the request becomes a relationship decision, and honoring it for future deliveries is usually sensible because excluding one account costs little. If the contract restricted the use, the question becomes how the records were cleared during rights review and what remedy the customer may have. That is a matter to assess with counsel, not to settle in an email.
Requests from individuals run on a different track. When a person rather than a company asks for deletion, statutes like the CCPA or GDPR can give that person rights, but whether they reach the delivered records turns on where the person lives, which law covers your company and how identifiable the records still are. Some privacy laws may also expect a business that deletes a person's data to pass the request on to parties that received it, which is one more reason to have a working notice mechanism in the license. Counsel should assess which rights and remedies apply to each request.
| Clause in the customer agreement | What to look for |
|---|---|
| Confidentiality | Whether support tickets, project files or usage records count as the customer's confidential information |
| Data use or aggregated data rights | Whether you may use de-identified or aggregated records for other purposes, including licensing |
| Data processing addendum | Whether you act only on the customer's instructions for the personal data in those records |
| Return or deletion at termination | Whether a former customer already asked you to delete its records, which should have kept them out of scope |
| Publicity and name use | Whether the customer's name may appear in materials shared outside the company |
Future deliveries: build a suppression list#
A suppression list is the supplier's tool for keeping a customer out of every future delivery, and it should be keyed to system identifiers rather than names. Use the account ID in Salesforce or HubSpot, the organization ID in Zendesk or Intercom, the customer number in NetSuite, and the email domains the customer uses.
Names alone miss too much. The same customer can appear as a parent company, a subsidiary, a former trade name and many individual contacts. Map every identifier the customer has across systems, then run the list against each new build before the manifest is final.
Mentions inside other records need their own rule. A customer's name can surface in another account's support ticket or in an internal Slack thread about an outage. Decide whether those mentions are redacted, generalized or the whole record is dropped, and apply the same rule to every refresh.
Copies already delivered: the clause that decides it#
A removal-on-notice clause is the most reliable way to pull records back from a licensee, because without one the licensee may have no contractual duty to delete anything it lawfully received. A licensee may cooperate when asked, but cooperation is goodwill, not an obligation you can enforce.
Negotiate the clause before the first delivery, while it costs nothing to add. The elements below cover most situations, and each one prevents a specific argument later.
- Trigger: written notice from the supplier that identifies records by delivery ID and record ID, never by the customer's name.
- Scope: whether the duty covers only identifiable records or every record linked to the customer, including de-identified ones.
- Action: deletion from production copies, working copies and evaluation sets, with backups purged on their normal rotation and never restored.
- Flow-down: the same duty for contractors, cloud vendors and any permitted sub-licensee.
- Proof: a written certification of deletion signed by an officer of the licensee.
- Replacement: whether the supplier provides substitute records and whether fees change.
- Limits: who bears the cost of processing notices and whether their frequency is capped.
What about models already trained on the records?#
Models already trained on delivered records usually sit outside a removal clause, because removing the influence of specific records from trained weights is technically difficult and retraining on demand is costly. Agreements therefore tend to address what happens next instead.
The practical terms to seek are narrower: removed records may not be used in any future training run, fine-tuning job or evaluation set, and the licensee confirms that in its deletion certification. If a customer worries that its identity could be learned, the stronger protection sits earlier, in preparation, where customer names, domains and account identifiers are removed before anything ships.
Illustrative: a client objects after a support archive ships#
Illustrative: a fictional vendor of dispatch scheduling software licenses a prepared archive of Zendesk tickets together with the Jira issues they escalated into. After the first delivery, a logistics client hears about the program during a renewal call and asks to be removed. Its master services agreement treats support submissions as confidential information.
Counsel reads the agreement and the rights review file. The review had cleared aggregated use, but the client's screenshots of its own configuration were arguably its confidential materials. The company adds the client's Zendesk organization ID, Salesforce account ID and email domains to the suppression list, then sends the licensee a removal notice citing delivery and ticket IDs.
The license includes a removal-on-notice clause, so the licensee deletes the matching tickets, purges backups on rotation and returns an officer's certification. The company supplies replacement tickets from accounts with clear terms. The client receives a short letter confirming future exclusion and certified deletion, and the renewal proceeds. The company adds a confidentiality-clause screen to every future rights review.
How the SourceX process limits removal problems#
The SourceX process limits removal problems by putting Rights before Preparation in the SourceX five-step transaction, so customer contracts are reviewed and exclusions are set before records are prepared or anything moves. Restricted accounts are carved out while the scope can still change cheaply, which keeps many removal requests from arising at all.
Because each delivery carries its own SourceX Evidence Packet, with its release authorization and privacy record, a later removal notice can cite the exact delivery and record IDs instead of describing the customer. Any replacement delivery goes through the same supplier approval as the original.
Frequently asked questions
Should we tell the licensee which customer asked?
Usually not. Identify the records by delivery ID and record ID so the licensee can find them without learning who objected. Naming the customer can itself disclose confidential information and may draw more attention to the account than the original records did. Keep the customer's name in your internal request log only.
Does a removal request mean we breached the customer's contract?
Not necessarily. Many agreements allow de-identified or aggregated use, and a request can come from preference rather than a contractual right. Whether a specific use was permitted depends on the clause wording and the preparation applied, so have counsel review the agreement and the rights review file before you respond on the merits.
Can removal reduce what the licensee pays?
It can if the agreement links fees to record counts or coverage. Some suppliers prefer to offer replacement records from accounts with clear terms instead of adjusting fees. Whatever you choose, write it into the license before the first delivery so a removal notice does not reopen commercial terms.
What if the customer's records were properly de-identified?
Then the licensee may hold nothing that identifies the customer, and deletion may be neither possible nor required. You can still exclude the customer from future deliveries as a goodwill step. Explain plainly what was removed during preparation, without sharing the license itself unless the agreement allows it.
How should we confirm the outcome to the customer?
Send a short written confirmation: the customer is excluded from future deliveries and, where the license provides for it, the licensee has certified deletion of matching records. Keep it factual, avoid technical promises about trained models, and file a copy with the original request and the notice you sent.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.