Setting a data retention policy for outbound and CRM records
An outbound data retention policy sets how long to keep contact and deal data under GDPR and CCPA, with a schedule by record type and what never expires.
ON THIS PAGE · 10 SECTIONS
- What do GDPR and CCPA actually require for retention?
- What is a defensible retention period for outbound contacts?
- A retention schedule, by record type
- Why suppression and opt-out records never expire
- How to build the schedule without a legal team
- A worked example: cleaning up a 40,000 contact database
- What changes during a CRM migration or tool switch
- A decision rule: when to shorten or extend the default
- What happens without a written policy
- Questions about outbound data retention policy
THE SHORT VERSION
- An outbound data retention policy is a written rule that says how long you keep contact data, deal records and activity history before you delete or archive them and what event triggers that deletion.
- Neither GDPR nor the UK ICO sets a fixed number of months. The storage limitation principle just says you cannot keep personal data longer than the purpose justifies and you have to be able to explain the number you picked.
- The defensible default most B2B teams land on is 24 months of inactivity for a marketing or outbound contact before deletion or re-permission, longer for an active deal or a signed customer.
- Suppression and opt-out records are the one category that never expires. Delete the contact and keep the opt-out flag or a new list load re-emails someone who already said no.
- Apollo's 2026 analysis of B2B contact data puts decay at roughly 2.1% a month, so a retention policy without a deletion trigger just accumulates dead records at a predictable rate.
An outbound data retention policy is a written rule that sets how long contact data, deal records and activity history stay in your CRM and outbound tools before they get deleted or archived, tied to a specific trigger like inactivity, deal closure or an opt-out request rather than a vague sense that old data is fine to keep. Most outbound teams do not have one until a prospect asks where their data came from, a new data protection officer asks for the schedule or a CRM migration forces someone to decide what to carry forward. Writing the policy before that point is cheaper than writing it under pressure.
What do GDPR and CCPA actually require for retention?
Less than most teams assume. That is the hard part. GDPR's storage limitation principle says personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed," according to the UK Information Commissioner's Office. There is no number in the regulation itself. You pick the period, document why it matches your purpose and review it. The CCPA in the US follows the same shape: no fixed retention clock, but a requirement to disclose how long you keep data and to delete it on a verified consumer request. Neither law tells you the number. Both laws expect you to have one written down and be able to defend it if asked.
EU / UK (GDPR)
- No fixed retention period in the law itself, only the storage limitation principle.
- You must document the retention period and the purpose it serves, reviewed at least annually.
- A data subject can request erasure at any time, which your policy has to be able to execute, not just promise.
US (CAN-SPAM, CCPA, state laws)
- CAN-SPAM requires honoring an opt-out within 10 business days and forbids re-selling or re-using an opted-out address, per the FTC's compliance guide.
- CCPA and similar state laws require disclosure of retention practices and a deletion path on request, state by state.
- No single federal retention number, so the written policy still has to come from you, not the statute.
The practical takeaway is the same on both sides of the Atlantic: the law will not tell you to delete a contact at month 18 or month 30. It will ask you to justify whatever number you chose and prove you actually enforce it.
What is a defensible retention period for outbound contacts?
For a B2B contact who has never engaged, 24 months from the last touch is the period most privacy teams treat as defensible under a legitimate interest basis, long enough to cover a slow buying cycle and short enough that you are not sitting on data you have no active reason to hold. That is a working default, not a legal minimum or maximum. A contact who opens emails, replies, books a call or becomes a customer resets the clock, because the purpose for holding their data is still active. A contact who never responds across two years of attempts has no purpose left to justify the record and keeping it only adds risk with no pipeline to show for it.
This is where a retention policy earns its keep against a CRM full of dead contacts. Catch-all email verification already covers how much bad data sits in a list before anyone sends to it. Retention is the other half of the same problem: the data that was once good and quietly went stale.
Sources: Apollo, 2026, Validity, 2024.
A retention schedule, by record type
A policy that says "delete old data" is not a policy. It has to name the record type, the period and the trigger or nobody can enforce it consistently. This is the schedule we start new outbound systems from, adjusted for each client's legal basis and market.
| Record type | Default retention | Trigger for deletion or review |
|---|---|---|
| Prospect contact, never engaged | 24 months from first add | No open, click, reply or call in that window |
| Prospect contact, engaged but no deal | 24 months from last engagement | No activity since the last touch, clock resets on any engagement |
| Active deal and its activity history | Life of the deal, plus 12 months after close | Deal closed won or lost, then a fixed retention window for dispute and reference |
| Closed customer contact | Length of the customer relationship, plus the period set by your contract or finance records policy | Contract ends, account churns |
| Opt-out or unsubscribe flag | Indefinite | Never, unless the person explicitly re-opts in |
| Enrichment and verification logs | 12 months | Age of the log, kept only for troubleshooting a bad send |
Six record types, a default period and the event that should trigger review or deletion for each.
Why suppression and opt-out records never expire
This is the one place a retention policy runs backward. Every other record type has a deletion date. A suppression record does not, because deleting it is what causes the actual compliance failure a retention policy is supposed to prevent.
- When a contact opts out, strip their personal details but keep a hashed identifier or the raw email address on a suppression list, forever.
- Check every new list load, every enrichment refresh and every re-import against the suppression list before a single send goes out.
- Never treat "we deleted their record" as compliance. If the suppression flag goes with it, the next data pull re-adds a person who already said no and you are back to square one with a complaint on file.
- Document the legal basis for keeping the suppression record itself: it is a legitimate interest in honoring the person's own request, which most privacy frameworks treat as self-evidently justified.
The FTC's CAN-SPAM guide puts the consequence in concrete terms: once someone opts out, you cannot sell, transfer or reuse their address, which only works in practice if the suppression record outlives the contact record it was attached to.
How to build the schedule without a legal team
- List every place contact data lives. CRM, outbound sequencer, enrichment tool, email verification logs, spreadsheets someone built during a campaign. A policy that only covers the CRM misses most of the actual exposure.
- Group records by purpose, not by tool. Prospecting data, active deal data, customer data and compliance records each have a different reason to exist, so each gets its own retention period rather than one blanket rule for everything in the CRM.
- Pick a period per group and write down why. "24 months, matches our average 9 to 12 month enterprise cycle with a buffer" is a defensible sentence. "We have always kept everything" is not.
- Set the trigger, not just the clock. Inactivity, deal closure, contract end and opt-out are triggers. A calendar date alone misses a contact who re-engages on day 730 and should reset their own clock.
- Automate the deletion, do not rely on someone remembering. A scheduled report or workflow that flags records past their window beats a quarterly reminder on someone's calendar, because the reminder is the first thing that gets skipped during a busy month.
- Review the schedule once a year. Buying cycles change, tools change and a schedule nobody revisits for three years stops matching the business it was written for.
FROM THE YARD
The retention conversation almost never starts because someone cares about compliance on a Tuesday. It starts because a CRM migration, a new data protection hire or a prospect's security questionnaire forces the question and the team discovers nobody can say how old the oldest record in the system is. We build the schedule into the CRM setup from day one on every system we run, specifically because writing it after three years of data has piled up means someone has to sort thousands of contacts by hand into keep or delete, instead of a rule that has been running quietly since week one.
A worked example: cleaning up a 40,000 contact database
Say a company moving outbound in-house inherits a CRM with 40,000 contacts built up over three years of an agency engagement. Applying the schedule above: roughly 60% (24,000) have had no engagement in over 24 months and move to deletion or a re-permission email. Another 15% (6,000) engaged at some point but the deal never closed and sits past the 24 month window, same treatment. 20% (8,000) are active prospects or customers and stay untouched. The remaining 5% (2,000) are opt-outs, which stay on the suppression list regardless of what happens to everything else. The company ends with roughly 10,000 active records instead of 40,000, a smaller number that is actually usable instead of a large one nobody trusts. This is a labelled example, not a client result, but the proportions match what we typically see when a list has run three or more years without a cleanup rule attached.
What changes during a CRM migration or tool switch
A retention policy gets tested hardest exactly when it is least convenient to enforce: during a system change. What happens to outbound pipeline during a CRM migration covers the operational side of a move. The retention side is simpler to state and easy to skip under deadline pressure: do not carry forward every record from the old system by default. Apply the retention schedule before migration, not after, so the new system starts with the same 10,000 active records instead of inheriting 40,000 and starting the cleanup problem over again in a new tool. Teams running their outbound through our outbound system treat a tool switch as the cheapest possible moment to apply a retention policy, because the data has to move anyway and moving only what still earns its place costs nothing extra.
A decision rule: when to shorten or extend the default
24 months is a starting point, not a rule for every business. Three thresholds tell you whether to move off it.
- Shorten to 12 to 18 months if your sales cycle runs under 3 months and a contact silent for a year has almost never reopened in your actual deal history. Check your own closed-won data for the longest gap between first touch and close before picking the number.
- Extend to 30 to 36 months if you sell into a market with cycles over 12 months or multi-year renewal gaps, where a contact silent for two years can still be in a budget cycle that has not come back around yet.
- Keep it at 24 months as the default for most mid-market B2B outbound, which is where the bulk of the industry guidance and our own account data lands.
What happens without a written policy
Nothing dramatic, most weeks. That is the actual risk. A CRM without a retention policy does not fail loudly, it accumulates quietly: stale contacts dilute enrichment match rates, old opt-outs get re-imported from a fresh list purchase because nobody checked and a security questionnaire or a data subject access request lands on a desk with no answer ready. Validity's 2024 survey of CRM admins found 31% already say poor data quality costs at least 20% of annual revenue, a cost that compounds every month a retention schedule does not exist to stop it. The fix is not a one time cleanup. It is the schedule in the table above, with a trigger and an owner, running every month instead of every few years when someone finally notices.
Questions about outbound data retention policy
How long can I legally keep a prospect's contact data?
Neither GDPR nor the CCPA sets a fixed number. Both require you to keep personal data only as long as your stated purpose justifies and to document that period. Most B2B teams use 24 months of inactivity as a defensible default, shorter for fast sales cycles and longer for long enterprise cycles, as long as the number is written down and reviewed.
Do I have to delete a contact who unsubscribed?
Delete their personal details if asked, but keep a suppression flag or hashed identifier indefinitely. Deleting the suppression record along with the contact is what causes a re-send to someone who already opted out, which is the exact failure a retention policy is meant to prevent.
What should a data retention policy cover besides the CRM?
Every tool that holds contact data: the outbound sequencer, enrichment and verification logs and any spreadsheet built during a campaign. A policy that only names the CRM misses most of the actual exposure, since prospecting data often lives in two or three tools before it ever reaches the CRM.
Should retention periods be the same for prospects and customers?
No. A never-engaged prospect has a short, inactivity-based window. An active deal keeps its data through close plus a reference period. A closed customer's retention period usually follows the contract and finance records policy, which runs longer than any outbound prospecting window.
Who should own the data retention policy for outbound?
Whoever already owns CRM administration or outbound reporting, working with legal or a data protection lead to set the legal basis. The policy fails when it sits only with legal and never gets built into the CRM as an actual automated rule, because a document nobody enforces is not a policy.
Sources: UK ICO, FTC CAN-SPAM Compliance Guide, Apollo, 2026, Validity, 2024.