Outbound vendor data retention

Outbound vendor retention is a chain decision. Begin with why a vendor holds a prospect record, who chooses that purpose, which systems receive it, and how deletion moves through them. A vendor's delete control is one event in the workflow. If the vendor acts on your instructions, the route must reach the vendor and every other party holding the same record. Treat retention as a control you can test, with an owner, a trigger, and a completion record.

Start with responsibility

A retention period is hard to defend when nobody can say who chose the purpose. Build a vendor register before deciding how long each record should remain stored.

Under GDPR, the concepts of controller, joint controller, and processor determine responsibility for compliance and how people can exercise their rights.¹ These roles are functional, so interpret them from what each party actually does.² A controller decides the purposes and means of processing, meaning why and how the processing occurs.³

For each CRM, enrichment provider, sequencing platform, or other processor, record:

• the purpose the vendor supports;
• the data it receives;
• who decides why the data is used;
• where the vendor sends or exposes the data;
• the event that ends the purpose; and
• the deletion route and completion record.

Ask who decides why the record is collected and how the vendor uses it. Ask the vendor which systems and external parties receive the record. Continue only with answers about actual handling. The contract label alone is insufficient.

Set the retention period from the purpose

Choose a period you can explain for each purpose. A single period across every outbound system makes the register easy to fill in and difficult to justify.

Before setting a period, know what personal data you hold and why you need it.⁴ Decide how long to keep it based on that purpose and justify the period.⁵ Set standard retention periods wherever possible so the policy can be documented consistently.⁶

For each purpose, record the starting event, end event, period, and reason the period ends there. Include the review point that will cause someone to check whether the purpose still exists. If the purpose has ended, give the record a defined path to erasure or anonymization. Personal data should be reviewed periodically and erased or anonymized when it is no longer needed.⁷

The decision is ready when another person can read the register and answer three questions: why is this record here, what ends the need, and what action follows? If any answer is missing, keep the retention decision open.

Inspect the vendor's controls

Use a vendor setting only when it matches the retention rule you chose. Test it against the data flow, the purpose, and the deletion request you expect to send.

Ask the vendor:

• What starts the deletion process?
• Which record types does it cover?
• Does it remove the record, anonymize it, or apply some other treatment?
• Which connected systems receive the deletion instruction?
• What response proves that the requested scope was handled?
• What happens when your retention requirement changes?

Ask for the vendor's retention and deletion terms in writing, then compare them with your register. Record the vendor's wording, the data covered, the trigger, and the response you received. Keep the review focused on the actual data you send. A setting for one record type does not answer what happens to another.

When the vendor cannot describe the trigger, scope, or completion response, pause the integration review. You have a policy statement with no control you can test.

Route a deletion request through the right party

Handle a deletion request as an instruction workflow. First identify whether your organisation still needs the data, then identify the party that decides the purpose and the party that stores or processes the record.

Individuals have a right to erasure when an organisation no longer needs their data.⁸ A data processor may act only on instructions from the data controller.⁹ The data controller is usually the processor's customer.¹⁰ Unless the contract says otherwise, a person asking a processor to delete data should be redirected to the data controller.¹¹

Use this sequence:

• capture the request and the record identifiers;
• check whether the stated purpose still exists;
• send the instruction to the party that controls the purpose;
• ask each vendor what systems and downstream parties are covered;
• request confirmation of the action and its scope; and
• record the request, instruction, response, and unresolved gaps.

Close the request after the response tells you what was searched, what was deleted or anonymized, and which other parties were instructed. A vendor may send you back to the customer or controller. Follow that route unless the contract provides another one.

When a special deletion channel applies

Some vendors require a recurring external deletion workflow. Use it as an intake and matching process, then build the vendor's internal deletion work behind it.

Beginning on August 1, 2026, data brokers must access California residents' deletion requests through the California Privacy Protection Agency's Delete Request and Opt-out Platform, known as DROP.¹² Data brokers must act on downloaded requests within 45 days and repeat a similar process at least once every 45 days.¹³

The core element of DROP is a set of consumer deletion lists containing identifiers for people who requested deletion.¹⁴ The deletion scope includes personal information and inferences drawn from it.¹⁵ A broker has 45 days from receiving a deletion request to complete the deletion and must direct its service providers and contractors to do the same.¹⁶

Build the operational check around identifier matching. Ask which identifiers your systems can match, where the matched record is stored, and how the instruction reaches service providers. Keep a result for every request, including an unresolved match or a system that could not be searched. The workflow is complete only after the matched records and the required downstream actions are addressed.

What not to do

During a vendor review, check for these failures. They can leave the retention decision unsupported or the deletion incomplete.

• Do not let contract wording settle responsibility by itself. Contract terms can help identify the controller, but they are not decisive in every circumstance.¹⁷
• Do not keep personal data longer than you need it.¹⁸
• Do not dismiss a challenge to your retention decision without careful consideration.¹⁹
• Do not treat pulling a consumer deletion list as the end of the operational work.²⁰

Use the register before adding a new integration, and use the request workflow whenever a person or a retention review requires removal.