# Data Retention Policies: A Practical Guide for 2026

_2026-08-08_

You're probably already living with the messy version of this problem. A customer asks to be deleted, a colleague pings support, CRM exports turn up in one tool, event logs in another, and someone on the growth team realises the experiment platform still holds variant assignments long after the test ended. In that moment, **data retention policies** stop being a policy document and become the thing that decides whether your team can respond calmly or spend the afternoon untangling copies of the same record.

The useful way to think about retention is simple. It's the control that tells each system what to keep, what to archive, what to delete, and when to do it, so you're not relying on memory or spreadsheet folklore. That matters just as much in experimentation and analytics as it does in finance or HR, because raw event data, user mappings, and reports all age differently.

If you already care about lifecycle discipline in customer operations, the same logic applies to data governance. Good recurring retention habits in operations are not far from the logic behind [recurring revenue retention strategies](https://recurx.app/blog/customer-retention-strategies-ecommerce), except here the asset is evidence, not revenue.

For teams using tools like Otter A/B, this becomes practical very quickly. Their own privacy approach, like many SaaS products, has to answer how long account and test data should live, and that same question sits underneath every strong retention framework. If you're reviewing your public-facing notices too, the privacy page at [Otter A/B's privacy information](https://www.otterab.com/privacy) is a useful reference point for seeing how these ideas show up in a real product environment.

## When a Deletion Request Hits Your Growth Team

A deletion request rarely lands in one tidy place. It arrives through support, gets forwarded to marketing, then lands on the desk of whoever owns the A/B testing dashboard, because everyone knows the person's name but nobody knows which system is authoritative. The pain isn't just compliance anxiety, it's operational uncertainty.

That's the test of a retention framework. Without one, teams start asking the wrong questions, like whether deleting from the CRM is enough, or whether a warehouse copy is just “analytics noise”. It isn't noise if it still links behaviour back to a person, and it isn't safe to assume any one system has the full picture.

> **Practical rule:** if your team can't point to the retention trigger for each copy of the data, you don't have a retention policy, you have a hope.

This is why growth work and retention work collide so often. A campaign may have been set up to answer one business question, but the supporting data can end up scattered across email logs, product events, variant assignments, support records, and exports. If each system keeps its own version of the truth for an undefined period, your deletion workflow becomes a scavenger hunt.

The clearest way to escape that is to treat retention as part of the control stack, not as a legal afterthought. Once you do that, a deletion request becomes a predictable sequence. You identify the data class, check the justified retention period, see whether a hold applies, then delete, anonymise, archive, or retain for a defined reason. That same discipline is what keeps analytics tools from becoming permanent shadow archives.

If you're used to thinking about customer lifetime value or repeat purchases, the analogy is straightforward. You don't keep every abandoned cart forever just because it might be useful one day. You define the useful window, then stop collecting shelf dust. Data needs the same discipline.

## What a Data Retention Policy Actually Is

A household analogy makes this easier. You keep utility bills for a while because tax and proof-of-address questions can come back later, but you throw away food packaging once it's no longer useful. **Data retention policies** do the same thing for organisations, they separate data that still has a lawful or operational purpose from data that should be removed or stripped of identifiers.

### The building blocks that matter

A working policy usually needs six pieces.

- **Scope.** Which systems, teams, and data classes are covered.
- **Retention trigger.** What starts the clock, such as end of employment, end of the financial year, or date of capture.
- **Retention period.** How long the data stays in place for that purpose.
- **Disposal action.** Whether the end state is deletion, anonymisation, archival, or redaction.
- **Ownership.** Who is responsible when a rule needs to be applied or challenged.
- **Review cadence.** When the schedule gets checked against legal, operational, and system changes.

That list sounds formal, but each item stops a real failure. Scope prevents the policy from being too vague to enforce. Triggers stop teams from guessing when the clock starts. Disposal actions matter because “delete” and “archive” are not the same thing, and in some cases redaction is what you need for a subject access response rather than full destruction.

![An infographic showing recommended retention periods for utility bills, medical records, tax returns, and bank statements.](https://cdnimg.co/3716ee4f-bd1a-44a8-ac85-c2df5af21725/da62010f-97b3-49ff-907e-9f0f5bad1371/data-retention-policies-retention-periods.jpg)

The biggest confusion is usually between a retention policy and a privacy notice. A privacy notice tells people what you collect and why. A retention policy tells your organisation how long each category lives and what happens at the end. One is public-facing communication, the other is an operational control.

> A strong policy is just a written decision tree. If the record is X, the purpose is Y, and the clock started on Z, the system should know what to do next.

That distinction matters because retention is not abstract paperwork. If a vendor cannot apply the rule inside the system, the policy never leaves the document stage. A useful definition is this, **a data retention policy is a documented, enforceable lifecycle rule for each data class, from collection to justified disposal**.

## The Legal and Regulatory Drivers Behind Retention

UK retention logic starts with a simple principle, keep personal data only as long as you need it for the stated purpose. The ICO makes that point clearly in its storage limitation guidance, and it also says organisations need to justify their retention periods rather than defaulting to indefinite storage. You can't defend a period if you can't explain the purpose behind it. The ICO's [storage limitation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/) is the cleanest anchor for that rule.

The reason this gets messy in practice is that UK retention is built from overlapping legal regimes. HMRC expectations commonly drive six-year tax and financial record retention, while limitation rules push many firms to keep employment and contract records for six years after the relevant event or employment ends, as summarised in the linked UK retention guidance above. That's why there isn't one universal answer, there's a stack of obligations that often point in the same direction but for different reasons.

### Why a single calendar rule fails

If you keep one blanket period for everything, you either over-retain low-risk data or under-retain regulated records. Marketing event logs, payroll evidence, and safety records don't belong in the same bucket, because their legal and evidential needs differ. The post-GDPR shift pushed organisations away from “keep it all” habits and towards **purpose-based retention**, which means the same record can have a different lifecycle depending on whether it supports tax, legal defence, contract performance, or anonymised analytics.

That's also why a generic “delete after X months” rule often falls apart. A retention window has to be defensible, not convenient. In many organisations, that means mapping the record type to the purpose first, then deciding whether the data should be retained, archived, anonymised, or removed once the purpose ends.

For a broader implementation perspective, a practical [guide to data retention for Washington startups](https://www.bydesignlaw.com/data-retention-policy-template) can be useful as a contrast, even though the legal context differs. The useful lesson is the same, retention works when it's tied to data class and trigger, not when it's treated as a single blanket rule.

![A diagram outlining the UK regulatory framework for data retention including GDPR, storage limitation, and compliance bodies.](https://cdnimg.co/3716ee4f-bd1a-44a8-ac85-c2df5af21725/3885bf76-ed7b-4aa8-b20a-8aafb3515169/data-retention-policies-regulatory-framework.jpg)

The practical outcome is a mindset shift. You are not asking, “How long do we keep this department's files?” You're asking, “What purpose justifies keeping this exact class of data, and how do we prove the answer later?” That's the question the policy has to solve.

## Retention Windows by Data Category

A usable schedule starts with categories, not with departments. Finance might own invoices, HR might own employment files, and security might own CCTV, but the legal trigger is attached to the record type, not the team name. Once you see that, the policy stops looking like a filing exercise and starts looking like a control map.

### Sample UK Retention Windows by Data Category

| Data Category | Typical Retention | Trigger | Disposal Action |
|---|---:|---|---|
| Financial and tax records | **6 years plus the current financial year** | End of the relevant financial year | Secure deletion or archival if a hold applies |
| Employment records | **6 years after employment ends** | Employment termination date | Delete, archive, or redact as required |
| CCTV imagery | **31 days** | Date of capture | Secure deletion unless needed for an incident |
| Marketing and CRM data | Typically **12 to 24 months** | Last meaningful interaction or campaign purpose end | Delete or anonymise |
| Server and application logs | Typically **30 to 90 days** | Date of log creation | Automated deletion or short-term archival |
| Medical or hazardous-exposure safety records | **10 to 40 years** | Exposure event or relevant medical trigger | Secure archival, then deletion when the schedule ends |

These are starting points, not a universal template. The point is to match each category with a trigger that makes sense, then define a disposal action that your tools can perform. A category with long-tail liability, like hazardous-exposure records, needs a very different handling model from short-lived operational logs.

> The mistake to avoid is a single global default. It sounds tidy, but it either hoards low-value data or deletes evidence too early.

The category view also helps with ownership. Security can own CCTV rules, finance can own invoice retention, and HR can own employment files, but the policy still needs one overall review path so the whole schedule stays consistent. That consistency matters because the same customer may appear in several systems, yet each system can have a different legal trigger.

Use the trigger column carefully. “End of financial year” is not the same as “date of invoice creation”, and “end of employment” is not the same as “date of application submission”. Those differences sound small until someone tries to delete records manually and realises the clock was started on the wrong date.

## Retention for A/B Testing and Analytics Platforms

Experimentation data is where many teams get careless. They assume the test platform is just marketing tooling, but it usually stores a mix of raw events, variant assignments, and references that can re-link behaviour to a person if you aren't careful. That makes retention a design problem, not just a legal one.

### Treat the experiment as its own data lifecycle

Raw event streams are usually the most disposable layer. They're high volume, they're useful for a short analysis window, and once the test question is answered they often stop carrying operational value. Variant assignment and user-to-variant mapping are more sensitive, because they connect a person to a specific experiment path.

Aggregate reports sit in a different category again. Once the underlying event data is removed or anonymised, the report should usually lose personal risk, but the file still needs version control so the business knows which decision was made and when. That's where many analytics programmes get confused, because they keep the summary forever but forget to define what should happen to the source data.

For teams running experiments, [product A/B testing strategies](https://refact.co/insights/digital-product/ab-testing-founders-guide) are useful context because they show how clean experiment design depends on clear goals. The same logic applies to retention, if the test exists to answer one business question, the data should not live as though the question is still open after closure.

### What to ask your platform about

- **Can the SDK avoid storing direct identifiers?** If it can, you reduce the amount of re-linkable data at collection time.
- **Can event retention be configured by data class?** A single global setting is usually too blunt.
- **Does the platform support automatic deletion after test completion?** That matters when the outcome is already known.
- **Can reports be preserved without keeping raw user-level histories?** That separates decision evidence from personal data.
- **Is the audit trail visible?** If deletion happened, you need a record that it happened.

The retention rule for experimentation should follow purpose limitation. If the experiment is closed and the business question has been answered, raw events should not sit around just because they might be interesting later. The safer path is to delete them or anonymise them on a defensible schedule, while keeping only the summary evidence needed for governance.

Otter A/B's own [data cleaning best practices](https://www.otterab.com/blog/data-cleaning-best-practices) sit naturally beside this idea, because clean inputs make retention easier to enforce. If you keep only the identifiers and events you need, the disposal decision becomes far less painful.

In practice, experimentation maturity shows. Teams that define their raw event window up front spend less time untangling deletion requests, and they also make their reporting easier to trust. The system doesn't become compliant by accident, it becomes compliant because retention was designed into the experiment lifecycle from the start.

## From Policy Document to Operational Control

A policy that lives only in a PDF won't survive contact with real systems. Deletion has to be executable, and that means wiring retention into the places where data lives, such as identity systems, warehouses, SaaS tools, and experiment platforms. Once the controls are embedded, the policy stops depending on memory.

### The disposal methods that matter

- **Secure deletion.** Use cryptographic erasure or certified overwrite where the storage layer supports it.
- **Archival.** Move long-tail statutory records into immutable storage when the law or business needs continued access.
- **Anonymisation.** Strip identifiers when the dataset still has analytical value but no longer needs to identify people.
- **Redaction.** Remove unnecessary fields when responding to access requests or sharing records internally.

Those four options solve different problems. Deletion reduces risk by removing the data entirely. Archival preserves evidence while limiting routine access. Anonymisation keeps the analytical value while breaking the link to a person. Redaction gives you a narrower disclosure than a full export.

A retention rule also needs proof. Audit logs are what turn a rule into a control, because they show when deletion ran, what changed, and whether an exception was applied. Without that trail, you can't tell the difference between a policy that exists and a policy that worked.

> **Implementation rule:** if the system can't show the action, it hasn't really enforced the policy.

Legal holds are the one place where automated deletion has to pause. The cleanest model is layered, the retention label or object-scoped rule handles the normal lifecycle, and the hold overrides deletion while a dispute or investigation is active. Microsoft's [retention model](https://learn.microsoft.com/en-us/purview/retention) is a good example of how retain-only, delete-only, and retain-then-delete actions can be applied at different scopes.

If you're building reporting around this, your governance dashboard should show retention events, exceptions, and holds side by side. The [reporting best practices](https://www.otterab.com/blog/reporting-best-practices) mindset applies here too, because the report is only useful if it gives managers a clean view of what happened.

A practical sequence helps teams stay out of chaos. **Map** the data, **classify** it, **schedule** the retention period, **automate** the action, **audit** the result, then **review** the policy on a fixed cadence. That order matters because automation without classification just speeds up confusion.

## A Starter Template and Common Pitfalls

A starter policy doesn't need to be ornate. It needs to be clear enough that an ops manager, a product lead, and a privacy reviewer can all read it and understand who does what. The best templates are short on jargon and long on ownership.

### Starter policy skeleton

- **Purpose and scope.** State which teams, systems, and data classes are covered.
- **Named owner.** Identify the role responsible for keeping the schedule current.
- **Retention table.** List each category, trigger, period, and disposal action.
- **Exception handling.** Describe how legal holds, investigations, and disputes pause deletion.
- **Audit logging.** Record when actions run and who approved exceptions.
- **Review cadence.** Set a recurring review cycle so the policy stays aligned with law and systems.
- **Training note.** Make sure the people who operate the systems know what the policy says.

The most common mistake is treating retention as an admin task that can be copied from another company. That usually fails because the other company's data classes, legal triggers, and tools are different. Another frequent problem is forgetting backups and replicas, so teams delete production records and leave copies sitting in secondary systems.

> Backups are not outside the policy. If they can restore personal data, they're inside the lifecycle whether the team likes it or not.

A second confusion point is anonymisation versus deletion. Deletion removes the personal data from the system. Anonymisation changes the dataset so the person can no longer be identified, which can preserve analytical value while reducing privacy risk. That distinction matters especially for experimentation and product analytics.

The final gap is review discipline. Retention schedules age quickly when systems change, vendors change, or a new data class appears. A policy that isn't revisited becomes a snapshot of old operations, not a live control.

---

If you're ready to make retention part of your experimentation workflow, [Otter A/B](https://www.otterab.com) gives you a lightweight way to run tests while keeping retention and reporting discipline in view. Use it to structure experiments, then map the data lifecycle so raw events, assignments, and reports don't outlive their purpose.

---

Canonical page: https://www.otterab.com/blog/data-retention-policies