Honoring past deletion requests before licensing an archive

Why old deletion requests are an archive problem#

Old deletion requests are an archive problem because most deletion workflows only reach the systems that were live when the request arrived. When a customer asked to be deleted, the team likely removed the account from the help desk, the CRM and the billing tool. The CSV export taken before a help desk migration, the mailbox archive of a departed account manager and an old data warehouse snapshot were rarely part of that work.

Licensing gives those forgotten copies a new audience. If a licensed package carries the support history of someone who asked to be deleted, the company has put back into circulation exactly what the person asked it to remove. Depending on the laws and privacy promises that apply, that may be a compliance problem as well as a trust problem, and even where counsel concludes the law does not reach a given copy, few general counsels want to defend that outcome to a customer or a regulator.

The fix is a suppression step that runs before preparation: a defined process that applies every past deletion request to the specific archive being licensed, then leaves a written record that it was done.

Where past deletion requests are recorded#

Past deletion requests are recorded in more places than the privacy inbox, and a complete log means searching all of them. Companies that handled requests informally before adopting a privacy request tool often find them scattered across support, sales and finance systems.

Treat the list below as a search plan, not a form to sign off. Note which sources you searched and which you could not reach, because that gap belongs in the privacy record.

• 1Privacy inbox and web request forms, including messages forwarded from a general contact address.
• 2Privacy request management tools, with ticket status and the systems marked as completed.
• 3Support tickets tagged or worded as account deletion, close my account or remove my information.
• 4CRM fields such as erased, anonymized or do not contact, and records an admin merged or purged.
• 5Billing and subscription records that show an account closure with a data removal note.
• 6Letters and emails sent to legal or to individual account managers before a formal process existed.
• 7Requests passed on by business customers for their own staff or end users, often sitting in an account manager's inbox or a customer success tool.
• 8Request logs inherited from acquired companies whose archives now sit inside yours.

Step 1: build one deletion request log#

The deletion request log is a single table of every request found, with enough detail to match it against the archive and to show later what was done. Rebuilding it is usually the slowest part of the process, and it is worth doing properly once, because every future delivery will rely on it.

Store the log with access limited to the privacy team. It holds the very identifiers the requesters asked you to remove, so it should contain only what is needed to match and nothing more.

Step 2: match identifiers against the archive#

Identifier matching finds every record in the archive that belongs to or names a requester, and it works best from the strongest identifier to the weakest. Account and customer IDs give the cleanest matches. Email addresses come next, with care for aliases, plus-addressing and addresses that changed over the years.

Free text is where matches get missed. A requester may appear in another customer's ticket, in an email signature, in a call note or as a CC on a thread they did not start. Search those fields by name and email, and route name-only hits to a reviewer rather than removing or keeping them automatically.

Step 3: remove the records from the licensed package#

Removal for licensing means taking every matched record out of the package being prepared, which is a separate decision from deleting it out of the archive itself. The archive may sit under a retention policy or a legal hold; the licensed package should simply never contain the requester.

Use a clear rule for partial matches. When the requester is the main party to a ticket, order or thread, drop the whole record. When the requester is mentioned in passing inside someone else's record, redact the mention and keep the record, as long as the remaining text still makes sense.

Records kept under a deletion exception stay out as well. If the company declined part of a request because it needed the records for tax, warranty or a pending claim, those records were kept for that purpose, and licensing them would be a new use the requester was never told about. The log's exceptions field is what lets the team apply this rule.

Do not lean on later de-identification to cover a requester. De-identification lowers risk for everyone in the package, but a person who asked to be deleted expects not to be there at all, and a removal step is easier to explain than a debate about whether residual details could point back to them.

Keep the suppression list itself small: only the identifiers needed to stop the person's records returning in the next package, ideally stored as hashes. Ask counsel how long to keep it, since it exists only to honor the request.

Step 4: record the run in the privacy record#

The privacy record is the written account of what the company did to protect people in the package, and the suppression run belongs in it. A buyer, an auditor or your own successor should be able to read it and see that past deletion requests were applied before anything left the company.

Re-running matters because requests keep arriving. A request received between the first and second delivery of a package must be applied to the second, and the record should show that it was.

• 1Date range of the request log and the sources searched.
• 2Sources that could not be searched, and the reason.
• 3Matching rules used, including how name-only hits were reviewed.
• 4The removal rule for primary records versus incidental mentions.
• 5Who ran the step, who reviewed it and on what date.
• 6A commitment to re-run the step before each delivery.

Illustrative: a software company retiring its old help desk#

Illustrative: a fictional vertical software company is retiring a help desk it used for many years and plans to license the exported ticket history alongside linked engineering issues. Its privacy request tool was adopted only recently, so the general counsel suspects older requests were handled by support agents directly.

The team searches the ticket export for deletion language and finds requests that never reached the privacy log, plus a folder of emails sent to a former head of customer success. It merges these with the formal log, matches on account IDs and email addresses, and sends name-only hits to a paralegal for review.

Tickets where a requester was the customer contact are dropped; tickets where a requester appears only as a CC are redacted. The privacy record lists every source searched, notes that an old sales mailbox could not be restored, and commits to running the step again before each delivery.

How SourceX handles past deletion requests#

SourceX treats past deletion requests as part of Preparation in the SourceX five-step transaction, after Rights and before Approval. Nothing is shared during the initial assessment, and the suppression step runs under the supplier's control before any record is released.

The result is written into the privacy record of the SourceX Evidence Packet, alongside provenance, licensing rights, permitted use and release authorization. This is general information rather than legal advice; which deletion laws reach a given archive is assessed deal by deal with counsel.