Retention rules must exist as enforceable controls across HubSpot, backups and archives, with evidence that proves enforcement, not only as a policy document. Rules that live in a PDF do not protect you when an auditor asks “how do you know?” or when a restore risks re‑introducing erased records. This guide shows how to set practical, defensible retention rules for CRM data in HubSpot, translate them into system controls, and assemble an audit‑ready evidence pack.
Retention is no longer a paperwork exercise. Privacy law, customer contracts and internal governance expect you to define timeframes by data class, enforce them in production and backups, and show evidence of erasure and legal holds. In HubSpot that means your rules must reach core objects and configuration, your backups must reflect class‑based retention with tamper‑resistant storage where needed, and your evidence must show approvals, timestamps and locations.
You need a shared language across Legal, Compliance, Security and Operations:
- CRM: Customer Relationship Management data and processes in HubSpot - Contacts, Companies, Deals, Tickets, activities and related configuration.
- GDPR and your DPA: the privacy law and your Data Processing Agreement that shape retention, erasure and portability duties.
- RoPA: Records of Processing Activities (GDPR Article 30) that describe purposes, recipients and safeguards.
- Data minimisation and purpose limitation: keep only what is necessary, for as long as needed.
- RBAC: role‑based access control for who can set, change and execute retention actions.
- WORM: write‑once, read‑many storage that resists tampering.
- Backup versus archive: backups restore service quickly; archives satisfy long‑term reference or regulatory need.
- RPO and RTO: Recovery Point Objective and Recovery Time Objective that shape backup frequency and acceptable restore time.
List what you hold and why, including core objects (Contacts, Companies, Deals, Tickets, Custom Objects), engagements (notes, tasks, meetings, emails, call recordings, marketing email events), files and attachments, and CMS assets where they contain personal data or operational content. Include configuration that influences processing such as properties, pipelines, workflows, lists, permissions and subscription status. Record a short description and purpose for each class so Legal and Compliance can validate the scope.
For each data class, map the drivers that set the rules: privacy law and sector regulation in each jurisdiction, contractual obligations with customers and partners, and internal operational needs that justify retention. Link every class to the relevant RoPA entry and reference the DPA where return or deletion on exit affects timelines.
Decide the duration to keep items in each layer:
- Production: a clear timeframe by class (for example, “for the duration of the contract plus X years, subject to local law”), including exceptions (disputes, statutory stops) with rationale.
- Backups: a window that supports recovery and verification, typically shorter than production but long enough to catch and fix issues.
- Archives: long‑term retention only where required (for example, statutory periods linked to finance or tax).
Confirm durations with Legal and Compliance for each jurisdiction and document the decisions and approvers.
Turn policy into actions across HubSpot, backups and archives:
- In HubSpot: use properties, lists and workflows to identify records reaching their deletion dates, route the items for approval via RBAC, and execute deletion with auditable logs. Where lawful basis or subscription status governs processing, ensure those fields are part of eligibility rules.
- In backups: apply class‑based retention policies; enable immutability where you need tamper resistance; document storage regions and encryption (KMS/HSM) settings; and retain configuration for pipeline/property rollback where needed.
- In archives: index content by data class and retention class to make retrieval and disposal efficient and auditable.
Keep an erasure log that records identifiers, scope, legal basis, approvals and timestamps. After any restore, compare restored data to the erasure log and run a controlled re‑deletion step so erased records cannot silently return. Store the re‑deletion approvals and results with the same rigour as the original erasure. This safeguard is essential to demonstrate that rights are honoured in practice, not just at the time of the initial request.
Write a simple process that names who can request and authorise holds, how a hold is scoped, and how it is communicated. Show how deletion and automated changes are paused in HubSpot (for example, by setting a legal hold flag) and in backups/archives for items in scope. Record the matter reference, dates, owners and release authorisation. Link holds to the relevant RoPA entries.
Choose storage regions for backups and archives that align with policy (for example, United Kingdom or European Union) and record the locations. For international transfers of personal data, record safeguards such as Standard Contractual Clauses and conduct a Transfer Impact Assessment where required. Keep encryption details, access control summaries and the storage map in the evidence pack.
Publish dashboards and alerts for items exceeding retention. Create an exception workflow that names an owner, a reason code and a due date to resolve. Reconcile production deletions against backup retention on a schedule; document any differences and corrective actions. This keeps you ahead of audits and prevents “end‑of‑quarter surprises”.
Keep a concise pack that answers who, what, when, where and why without a meeting: the written retention schedule with approvals and version history; RoPA entries that reference retention, erasure and safeguards; backup configuration with retention and immutability settings, storage regions and encryption; deletion and re‑deletion logs with approvals and timestamps; legal hold records with placement and release evidence; and quarterly restore drill packs showing RPO/RTO and that deletion rules and re‑deletion steps work in practice.
Run four tracks in one short session: business change (new products, markets, jurisdictions), data model change (objects, fields, integrations, purposes), policy alignment (Legal and Compliance review and approvals), and access review (least‑privilege checks for roles that can delete or change retention). Update the schedule and evidence pack, and post the summary in your register.
Typical issues include defining rules without system enforcement, deleting records in production without post‑restore re‑deletion, ignoring configuration and subscription status that govern lawful processing, missing evidence for approvals and timestamps, and mismatched residency between policy and where backups actually live. Avoid them by implementing class‑based controls in HubSpot and backups, running and evidencing re‑deletion after restores, cataloguing configuration, and aligning storage regions to policy.
Adopt simple templates early: a retention schedule (data class, purpose, legal basis, production/backup/archive durations, owner, approver, next review), an erasure log schema (identifiers, scope, date, basis, approver, re‑deletion status, evidence links), and an evidence checklist (policy and RoPA references, backup/archive settings, encryption/residency statements, deletion/re‑deletion logs, last drill result). Use HubSpot exports and APIs to drive lists and workflows; consider backHUB for class‑based backup scope and full‑fidelity restore with change tracking (/solutions/backhub-hubspot-backup); and maintain the register and evidence in a controlled repository.
Your retention programme is “done” when every CRM data class and relevant configuration is listed with purpose and RoPA link; production, backup and archive durations are set per class with legal or contractual basis; HubSpot workflows/lists identify items approaching and exceeding retention, and backups/archives enforce class‑based retention with documented regions; RBAC sets requester, executor, validator and approver roles for deletions and retention changes with dual control for production deletes; an erasure log exists and a post‑restore re‑deletion process is documented and tested; a legal‑hold process pauses deletion across HubSpot and backups; and an evidence pack (policy, schedule, RBAC matrix, storage regions, encryption/immutability statements, and the last successful deletion + re‑deletion test) is stored and referenced.
A representative set of records across Contacts, Companies, Deals, Tickets and selected engagements is tagged for deletion based on policy; deletion executes with approvals and timestamps; a restore runs from a point‑in‑time snapshot; controlled re‑deletion executes against the erasure log; validation confirms no erased records reappear and automations/reports behave as expected; the end‑to‑end test meets the agreed SLA and RTO; and the audit pack contains immutable logs (timestamps, actors), approvals, before/after diffs and reconciliation notes.
Use a simple data contract for retention and erasure:
- Data contract: data_class_id; data_class_name; purpose; legal_basis_ref; production_retention; backup_retention; archive_retention; residency_regions; system_of_record; enforcement_controls (HubSpot workflow/list IDs; backup policy ID; archive policy ID); erasure_log_location; approver_role; evidence_location (URL/ID).
- Erasure log schema: record_identifier (for example contact_id/email); data_class_id; scope (objects/engagements/files); deletion_requested_at; deletion_executed_at; legal_basis; approved_by; approval_id; restore_snapshot_id (if applicable); re_deletion_executed_at; status; evidence_link.
- Standard log entry: timestamp; actor_type (human/agent); actor_id; action (retention_set, retention_changed, deletion_requested, deletion_executed, restore_start, restore_complete, re_deletion_executed, legal_hold_set, legal_hold_released); parameters (data_class_id, snapshot_id, scope); before_state; after_state; approval_id; status; evidence_link.
Add or repurpose properties to support automation and evidence:
- Common properties: retention_class (enum), deletion_due_at (datetime), deletion_scheduled (boolean), deletion_executed_at (datetime), deletion_reason_code (enum), legal_hold_flag (boolean), legal_hold_matter_id (text), evidence_link (URL).
- Lawful processing: lawful_basis (enum), consent_timestamp (datetime), last_meaningful_activity_at (datetime).
- System elements: named lists and workflows for retention cohorts and erasure; a custom report that shows “items exceeding retention” by data class.
Track and review with leadership:
- Retention coverage: the percentage of data classes with production/backup/archive rules set and enforced.
- Deletion SLA: median days from deletion_due_at to deletion_executed_at.
- Re‑deletion compliance: the percentage of restores where re‑deletion completes within SLA.
- Legal holds: counts placed and released; average time to release; zero unauthorised deletions under hold.
- Residency compliance: the percentage of backups/archives with region evidence aligned to policy.
- Immutability coverage: the percentage of applicable classes under WORM or append‑only policies.
- Drill pass rate: the percentage of quarterly deletion + re‑deletion tests that meet acceptance criteria.
- Evidence completeness: the percentage of data classes with up‑to‑date policy, RoPA link, logs and approvals.
Backup retention supports rapid restoration of service and is typically shorter. Archive retention preserves records for long‑term reference or regulatory duties and is often longer, with stricter access and immutability controls.
Keep an erasure log, run a restore, and execute re‑deletion against that log. Evidence includes timestamps, approvals, snapshot IDs, re‑deletion results and a reconciliation report that shows no erased records returned.
They can coexist. Honour erasure requests promptly, record them in the erasure log, and re‑apply deletions after any restore. Use legal holds to pause deletion where law requires it.
Use RBAC and dual control. A requester cannot approve. Changes and production deletes require an approver (for example, Legal/Compliance) and a validator to review results.
- Inventory and classification: complete for CRM data and configuration; purposes set; RoPA links present.
- Legal and contractual drivers: mapped per class; DPA references captured.
- Targets: production, backup and archive durations set by class; exceptions documented and approved.
- HubSpot controls: properties, lists and workflows built to flag due records; RBAC approvals in place; deletion logs captured.
- Backup/archive policies: class‑based retention applied; storage regions and encryption documented; immutability enabled where needed.
- Erasure and re‑deletion: erasure log live; re‑deletion procedure documented and tested; last test passed within SLA.
- Legal holds: procedure tested; holds propagate to backups/archives; placement and release logged.
- Monitoring and exceptions: dashboards active; owners assigned; reconciliation with backups scheduled.
- Evidence pack: retention schedule with approvals, RoPA references, backup/archive settings, encryption/residency statements, deletion and re‑deletion logs, last restore+re‑deletion test.
- KPIs: coverage, deletion SLA, re‑deletion compliance, legal holds, residency compliance, drill pass rate and evidence completeness reviewed quarterly.