Data Retention Policy

What is a Data Retention Policy?

A data retention policy is a documented set of rules defining how long different categories of data should be kept, under what conditions they must be deleted or anonymised, and what processes apply at the end of each retention period. It translates legal obligations, regulatory requirements, and business needs into operational rules that govern data throughout its lifecycle, from collection to secure deletion.

Retention policies serve two competing pressures simultaneously. Some data must be retained: financial records for tax compliance, employee records for employment law, audit logs for regulatory requirements. Other data must not be retained: personal data beyond the purpose it was collected for, sensitive data that creates liability if breached. A retention policy draws the line between the two.

How a data retention policy works

A retention policy assigns a retention period to each data category. The period specifies how long data in that category should be kept after a defined trigger event: the end of a customer relationship, the date a contract was signed, the date a transaction occurred, or the date a log entry was created.

Three components define each retention rule.

Data category. What type of data the rule applies to: customer personal data, employee records, financial transaction records, audit logs, security event logs, contracts, health records. Categories should map to the organisation's data classification scheme so that classified assets automatically inherit the correct retention rule.

Retention period. How long the data must be kept after the trigger event. This must be justified: either by a legal or regulatory minimum retention requirement, or by a documented business purpose that requires the data for that period.

End-of-life action. What happens when the retention period expires: secure deletion, anonymisation, or archiving. Deletion is the default for personal data where no ongoing purpose justifies retention. Anonymisation removes personal identifiers while preserving aggregate value for analytics. Archiving moves data to lower-cost, restricted-access storage where it remains available for legal hold but is no longer actively processed.

Data retention vs data minimisation

Both are GDPR requirements under Article 5. They operate at different points in the data lifecycle. Data minimisation limits what is collected. Data retention limits how long what was collected is kept. A comprehensive privacy programme addresses both: collect only what's needed, keep it only as long as it's needed.

Regulatory retention requirements by data type

Retention requirements vary significantly by data category and jurisdiction. Most organisations operating across multiple frameworks face a matrix of overlapping requirements.

Financial and transactional records. Most jurisdictions require retention of 6-7 years for financial records to support tax audits and legal disputes. Specific requirements vary: Companies Act requirements in the UK, IRS record retention in the US, similar requirements under Indian income tax law.

Employee records. Payroll records, employment contracts, and performance records typically require retention for the duration of employment plus 6-7 years to cover potential employment law claims and tax obligations.

Customer personal data under GDPR. No fixed period. The principle is "no longer than necessary for the purpose." An e-commerce company retaining customer purchase history should determine the minimum period needed for returns handling, regulatory compliance, and fraud detection, document that justification, and delete beyond it.

Audit logs under PCI DSS. Requirement 10 mandates 12 months retention with the most recent 3 months immediately available. Logs covering cardholder data access cannot be purged within that window.

Medical records under HIPAA. Six years from the date of creation or date last in effect for HIPAA-related documentation. Individual states may require longer for medical records generally.

The practical challenge is that most organisations have dozens of data categories with different requirements, and many categories overlap: a patient billing record is both a financial record and a health record, attracting requirements from multiple frameworks simultaneously.

The enforcement gap: policy exists, data doesn't get deleted

Writing a data retention policy is the easy part. Enforcing it is where most programmes fail.

The failure pattern is predictable. The policy specifies that customer personal data is retained for the duration of the relationship plus two years. The primary CRM system has automated deletion configured to run on schedule. That system's data gets deleted correctly.

But the same customer data exists in six other places: an analytics database populated by a nightly ETL job, a marketing platform synced via API, a data scientist's test database from last year, a weekly backup that runs regardless of deletion status in the source system, a customer support platform, and a data warehouse used for annual reporting. None of those have deletion automation configured. None of them receive the deletion signals from the CRM.

The policy says the data should be gone. The data isn't gone.

That gap exists because retention policy enforcement depends on knowing where data exists. A policy applied only to known primary systems leaves shadow data, analytics copies, and backup archives untouched. The obligation doesn't change because the organisation wasn't aware of the copies. Under GDPR's storage limitation principle, personal data retained beyond its necessary period is a violation regardless of how many systems it's distributed across.

Effective retention enforcement requires a data inventory that reflects the full estate, including the copies the policy was never designed to reach. Classification that identifies which assets fall under which retention rules. And deletion processes that reach all identified locations, not just the systems the IT team actively manages.