Data retention policy: legal basis, a sample schedule and how to enforce it

Keeping data "just in case" is the default in most companies and a liability under privacy law. This guide covers the legal basis, the seven parts of a retention policy, a sample schedule that separates personal event data from long-lived aggregates, and what happened when one product cut raw event retention from 4.5 years to 13 months.

What is a data retention policy?

A data retention policy is a documented set of rules that says, for each type of data an organization holds, how long it is kept, why, where, and how it is deleted or anonymized at the end of that period. It covers customer records, analytics events, logs, backups, emails and files.

Retention policies exist for two opposite reasons: some data must be kept for a minimum time (tax records, contracts), and personal data must not be kept longer than necessary. A good policy satisfies both and is enforced automatically, not just written down.

Why it matters: the legal basis

Regulators have fined companies specifically for keeping data too long. Beyond fines, every extra month of personal data is more to secure, more to search in a data subject request, and more to lose in a breach.

What a retention policy includes

1. Scope: systems and data categories covered (production databases, analytics, logs, backups, SaaS tools, spreadsheets).
2. Retention schedule: a table of data category, retention period, legal basis or purpose, owner and end-of-life action (delete, anonymize, archive).
3. Triggers: when the clock starts: collection date, last activity, contract end, consent withdrawal.
4. Deletion method: automated job, anonymization, or manual process; how backups age out.
5. Exceptions: legal holds and how they are approved and lifted.
6. Roles: who owns each category, who approves changes, who audits.
7. Review cycle: at least yearly, and whenever a new system or purpose appears.

Example retention schedule for analytics data

A schedule for a SaaS company's analytics and related data (sample policy, adapt to your own purposes and laws):

The key design choice is separating event-level data (personal, short retention) from aggregates (not personal, kept long). You keep long-term trends without keeping people.

Not legal advice; check the laws that apply to you.

Worked example: what moving from "keep everything" to 13 months does

A product sending 120,000 events a day had kept every raw event since launch, 4.5 years (sample figures):

• Rows stored: about 197 million. After moving to 13 months: about 47 million, 76% fewer.
• Identified users with stored history: 410,000, of whom 290,000 had not been active for over two years. After the policy (profiles deleted 24 months after last activity): 120,000.
• Data subject request search: a deletion request previously had to search all 197 million rows plus four ad hoc CSV exports found on a shared drive; now it searches 47 million rows, and exports expire after 7 days.
• Reports affected: none of the regular dashboards. Long-range charts (3+ years) now read from daily aggregates, which carry no personal data.

The company also cut its warehouse storage bill, but the bigger gains were lower breach impact and simpler compliance.

How to create a data retention policy

1. Inventory data: list every system that stores personal data, including SaaS tools, logs and exports.
2. Define the purpose of each category, then the shortest period that serves it. "Might be useful" is not a purpose.
3. Check legal minimums with legal or finance for financial, employment and contract records.
4. Decide end-of-life actions: delete, anonymize, or aggregate.
5. Automate it. Scheduled jobs, product retention settings and storage lifecycle rules. A manual policy is usually not followed.
6. Handle backups: let them age out on a fixed cycle; do not restore deleted personal data into production.
7. Publish the periods in your privacy notice, as Articles 13 and 14 require.
8. Review yearly and log changes.

Common mistakes

• "Keep everything" as the default. The most common and most costly mistake.
• One period for all data. Different categories serve different purposes.
• Forgetting copies: exports, spreadsheets, BI extracts and test databases.
• Deleting aggregates you need. Aggregate first, then delete the event-level data.
• No owner. Policies without owners drift as new tools are added.

Retention settings in TapCub

In Configuration › Privacy center › Data minimisation & retention, TapCub sets four periods separately: event rows (default 365 days), autocapture (90 days), person profiles (730 days) and consent receipts (730 days). A scheduled job deletes expired rows. The actual event retention cannot exceed your plan's limit. Daily aggregates contain no personal data and are not deleted on these timers, so long-term trends survive. Tiered decay can clear high-cardinality columns such as properties, referrer URL and title from older events before the deadline while keeping trends and funnels working. IP addresses are truncated at collection and not stored on events. See IP truncation and retention, data export and deletion and handling data subject requests. For the wider approach, see privacy by design.

Sources

• European Union. GDPR Article 5: principles relating to processing of personal data (storage limitation).
• UK Information Commissioner's Office. Principle (e): storage limitation.
• California Civil Code §1798.100 (CCPA/CPRA retention disclosure).