UK data retention policy for CRM (HubSpot, Salesforce, Pipedrive)

This guide explains UK data retention policy for CRM, who it’s for, and what to do next.

What a CRM data retention policy is (and why UK B2B teams need one)

A CRM data retention policy is a written set of rules that defines what customer and prospect data you keep in your CRM, how long you keep it, where it’s stored, and how it’s securely deleted or anonymised when it’s no longer needed. For UK B2B teams, it turns day-to-day habits (saving emails, logging calls, importing lists, syncing marketing tools) into a consistent, auditable process—so the CRM stays useful rather than becoming a “data attic”.

In practice, a good policy covers:

UK B2B teams need this because CRM data grows fast and spreads across tools. Without clear retention rules, you risk keeping outdated contacts, duplicating records, and storing unnecessary personal data in notes and attachments. A policy helps sales and marketing work from cleaner data, improves reporting accuracy, reduces storage and admin overhead, and supports consistent handling of requests like “remove my details” across the CRM and connected platforms.

What CRM data you’re holding: contacts, leads, customers, notes, emails, calls and attachments

A UK CRM typically stores a mix of personal data (and sometimes special category data) across multiple fields and files. Mapping what you hold is the first step to setting sensible retention periods and deletion rules.

For UK GDPR alignment, record the purpose and lawful basis for each category, set review dates, and ensure your CRM can delete, anonymise, export and audit changes consistently across these data types.

How to choose retention periods in the UK: practical rules of thumb (without legal jargon)

Start by listing the types of CRM data you hold (leads, customers, suppliers, support tickets, marketing preferences, notes, call recordings) and assigning each a “why we keep it” reason. A simple rule: keep data only for as long as it’s genuinely useful for that purpose, then delete or anonymise it.

Use event-based timers rather than “X years from collection”. Examples that work well in CRMs:

Minimise what you keep: store “notes” carefully (avoid sensitive details), separate attachments from contact records, and redact where possible. If you need analytics, prefer aggregated reports over identifiable records. Finally, match retention to your CRM controls: automate deletion/anonymisation, set review reminders, and document the chosen periods in plain English so staff apply them consistently.

A simple UK CRM data retention policy template (copy/paste)

Purpose: This policy sets out how [Company Name] retains and deletes personal data held in its CRM, to support customer relationships while keeping data accurate, minimal and secure.

Scope: Applies to all CRM records for leads, customers, suppliers and contacts, including notes, emails, call logs, attachments and marketing preferences.

Lawful basis & principles: We keep CRM data only where we have a valid reason (e.g., contract, legitimate interests, consent) and review it regularly to ensure it remains necessary, accurate and up to date.

Retention schedule (default):

Deletion & anonymisation: We delete records from the CRM and connected tools (email sync, marketing platform) where feasible. If full deletion is not possible, we anonymise identifiers and restrict access.

Reviews & ownership: [Role/Team] runs a monthly/quarterly inactivity report, applies the schedule, and logs actions in [Retention Log Location]. Exceptions require approval by [Role] and a documented reason.

Security: Access is role-based, exports are controlled, and backups follow a separate backup retention standard.

Build your retention schedule: map data types to purpose, owner, system and deletion trigger

Create a simple retention schedule table for your CRM that answers five questions for every data type: what it is, why you keep it, who owns it, where it lives, and what makes it safe to delete. Start by listing the data types you hold in the CRM (for example: leads, customers, contact notes, email history, call recordings, support tickets, marketing preferences, and suppression lists). For each row, write a clear purpose in plain English (e.g., “respond to enquiries,” “deliver contracted services,” “handle complaints,” “send opted-in marketing”). Avoid vague purposes like “business use.”

Next, assign an owner: a named role (Sales Ops, Marketing Manager, Customer Support Lead, DPO/Privacy Lead) responsible for accuracy and timely deletion. Then record the system of record and any copies: CRM, email platform, ticketing tool, call recording system, data warehouse, backups, and exports. This prevents “deleted in CRM, retained elsewhere” gaps.

Finally, define a deletion trigger that staff can apply consistently. Use event-based rules rather than fixed dates where possible: “X months after last meaningful contact,” “X years after contract end,” “after complaint closed + X months,” “immediately on consent withdrawal (except suppression list),” or “after unsuccessful lead + X months.” Include an exception column for legal holds (e.g., ongoing disputes) and a method column (auto-delete rule, scheduled job, manual review queue). Keep the schedule aligned to UK GDPR principles: keep only what you need, for as long as you need it, and document the reasoning.

How to implement retention in HubSpot: lifecycle rules, lists, workflows, deletion and exports

Start by translating your UK retention policy into clear, record-level rules: what you keep (contacts, companies, deals, tickets), why you keep it (e.g., customer support, marketing consent, contractual history), and how long you keep it. In HubSpot, map this to Lifecycle stage and key date properties (e.g., “Last marketing engagement date”, “Last sales activity date”, “Contract end date”). Create a custom date property like Retention review date so every record has a single field you can filter and automate against.

Next, build active lists to segment records by retention status: “Due for review in 30 days”, “Past retention review date”, “No engagement for 24 months”, and “Former customers post-contract”. Use AND/OR logic carefully so lists reflect your policy (for example, exclude contacts with open tickets or ongoing deals).

Then use workflows to operationalise the process. Typical steps: set or update the Retention review date when lifecycle stage changes; notify an owner for a manual check; create a task to confirm lawful basis and any ongoing need; and, where appropriate, trigger a suppression action (e.g., set a “Do not market” flag) before deletion. Keep an internal “Retention decision” property (retain/delete/anonymise) to create an audit trail without storing unnecessary personal data.

For deletion, prefer controlled, list-driven deletes and document who approved them. If you need a copy for internal record-keeping, use exports with least-privilege access, export only required fields, and store files in a restricted location with a defined deletion date.

How to implement retention in Salesforce: field history, reports, automation, archiving and deletion

Start by translating your UK retention policy into clear Salesforce rules: which objects (Leads, Contacts, Cases), which lawful basis/operational need, and the retention trigger (e.g., “case closed date”, “last activity”, “contract end”). Capture the trigger in a dedicated date field so it can be reported on and automated consistently.

Field History Tracking: enable it on key objects to evidence changes to retention-related fields (status, consent preference, close date). Track only what you need to avoid unnecessary personal data duplication. Where you need longer audit trails than standard history provides, consider a custom “Retention Log” object populated by automation.

Reports & dashboards: build a “Records due for review” report using your trigger date plus a calculated “review due” field. Add filters for record owner, business unit, and data category. Schedule report emails to data stewards and team leads to support periodic reviews.

Automation: use Flow to set retention dates on creation/closure, and to move records through a simple lifecycle (Active → Review → Archive → Delete). Apply guardrails: pause deletion if there’s an open Case, active Opportunity, or legal hold flag. Log actions to a custom object for accountability.

Archiving: for data you must keep but don’t need day-to-day, export to a controlled archive (encrypted storage with access logging) and delete from Salesforce, or use an archiving tool that preserves relationships and search needs.

Deletion: use scheduled jobs to soft-delete first, then purge after a short recovery window. Validate dependencies (attachments, emails, related records) and document exceptions.

How to implement retention in Pipedrive: filters, automations, GDPR tools and data cleanup

Start by mapping a simple retention schedule to Pipedrive fields (for example: “Last activity date”, “Deal won/lost date”, “Lead created”, and “Person updated”). Create a custom single-option field like Retention status (Active, Dormant, Due for review, Delete) so you can track decisions consistently.

1) Use filters to find records due for review. In People and Organizations, build filters such as: Last activity > 24 months ago; no open deals; no upcoming activities; marketing consent = no/unknown. Save these as shared filters (e.g., “Dormant – review”) so the team works from the same lists.

2) Add automations for reminders and tagging. Use Workflow Automation to set Retention status to “Due for review” when a deal is marked Lost and no activity occurs for X days, or when a person has no activity for a set period. Route a task to a data owner (e.g., “Check lawful basis / keep or delete”) rather than deleting automatically.

3) Use GDPR tools for requests and deletion. In Pipedrive’s GDPR features, record consent where relevant, and use built-in export/anonymisation/deletion tools to handle data subject requests. Keep an internal note of the action taken and date, without storing unnecessary personal data.

4) Clean up safely. Before deleting, merge duplicates, detach irrelevant links, and check email sync/attachments. Prefer anonymising where you need to retain minimal audit context. Schedule a monthly “retention review” using saved filters, and document the rules in your UK retention policy so actions are repeatable.

Compare UK CRM Data Retention Policy Options

Choosing a data retention approach for CRM data in the UK usually comes down to how much control you need, how quickly you must respond to deletion requests, and how confidently you can evidence retention decisions. Below is a practical comparison of common policy models used by UK organisations.

Approach How it works Best suited to Strengths Trade-offs / watch-outs Typical CRM requirements
Fixed retention periods (by record type) Set a defined retention period for each CRM object (e.g., leads, customers, cases), then delete/anonymise when the period ends. Organisations with stable processes and clear data categories. Simple to communicate; predictable; easier to automate. Can be too rigid if relationships change; requires careful mapping of record types and exceptions. Configurable retention rules; automated deletion/anonymisation; reporting on upcoming expiries.
Event-based retention (triggered) Retention clock starts (or resets) based on an event (e.g., last interaction, contract end, account closure). Sales and service teams where “last contact” is meaningful. More aligned to real customer lifecycle; can reduce unnecessary storage. Needs reliable event tracking; risk of “accidental resets” if events are poorly defined. Accurate timestamping; auditable triggers; controls to prevent unintended resets.
Purpose-based retention (by processing purpose) Retention is tied to why the data is held (e.g., marketing, support, billing), often with different rules per purpose. Businesses with multiple teams using CRM data for different activities. Supports clear internal governance; helps justify different retention for the same contact. More complex to implement; requires consistent tagging of purpose and access controls. Purpose tags/fields; role-based access; workflows that enforce purpose selection.
Tiered retention (active vs archive) Move older records from “active” CRM to an archive (lower access), then delete/anonymise later. Organisations needing history for operations but not day-to-day use. Improves CRM performance; reduces user exposure; keeps evidence accessible if needed. Archive still counts as retained data; must manage searchability, security, and deletion in both locations. Archiving tools; separate storage with access logging; unified retention schedules across systems.
Minimal retention (delete quickly, keep only essentials) Keep only the minimum fields needed; delete leads/contacts soon after inactivity unless a clear ongoing relationship exists. High-volume lead generation and marketing-heavy CRMs. Lower risk footprint; simpler data estate; fewer old records to manage. Less historical context for sales/service; may reduce analytics depth. Strong dedupe; field-level minimisation; clear inactivity definitions; consent/marketing preference tracking.
Manual review / case-by-case retention Records are reviewed periodically and kept or removed based on documented criteria. Smaller teams or complex, low-volume customer relationships. Flexible; can handle nuanced scenarios. Harder to scale; inconsistent outcomes; higher admin overhead; harder to evidence consistently. Review queues; approval workflows; audit logs; documented decision criteria.

Key comparison points to ask CRM vendors

Quick fit guide