Data Retention Policy: A Practical How-To Guide

A data retention policy is a governing document that defines how long an organization keeps each category of personal data, the legal or business basis for that period, and the method used to delete or anonymize the data once the period ends. It turns the abstract idea of "do not keep data forever" into enforceable rules.

Why a Data Retention Policy Matters

The clearest legal driver is the GDPR storage limitation principle in Article 5(1)(e), which states that personal data must be kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which it is processed. Holding data past its legitimate need is a violation on its own, no matter how securely the data is stored. Storage limitation sits in the highest penalty tier, exposing organizations to fines of up to 20 million euros or 4 percent of total worldwide annual turnover, whichever is greater.

Beyond compliance, retention discipline lowers cost and risk. Every record you keep is a record an attacker can steal, a record you must secure, and a record you must produce in litigation. A policy also formalizes the litigation hold: a documented process to suspend automated deletion when data is needed for pending disputes, audits, or investigations. Without that process you either destroy evidence you were required to preserve or keep everything forever out of fear.

There is a storage-cost argument too. Data that outlives its purpose still consumes backups, replication, and the staff time needed to secure and govern it. Sector regulators reflect the same logic in their own rules. In the United States, for instance, the FTC generally expects customer data to be disposed of within two years of its last use, while HIPAA defers to state law. A retention policy is where all of these overlapping timelines get reconciled into one enforceable answer per data category.

How to Set Retention Periods by Category

There is no single fixed retention period. The correct length depends on the purpose of processing, the legal basis, and sector-specific obligations. Work category by category, and for each one ask a single question: what is the shortest period that still lets us achieve the purpose and meet the law? Then justify that answer in writing.

Concrete examples make this real. HR records are often kept for a few years after employment ends to cover employment-tribunal windows. Financial and transaction records commonly require seven years, and anti-money-laundering rules can push some records to ten. Routine operational email may be purged after 90 days, while signed contracts are retained for the life of the agreement plus a limitation period. Article 5(1)(e) also carves out longer retention for archiving in the public interest, scientific or historical research, and statistical purposes, provided appropriate safeguards are in place.

A useful discipline is to express every period as a number plus a trigger event rather than a calendar date. "Three years after the contract ends" is enforceable by a system; "until 2027" is not, because it ignores when the underlying relationship actually closed. Triggers such as account closure, last activity date, or end of employment let automated rules calculate deletion dates on their own, which is what makes the schedule run without constant manual intervention.

Each retention period should trace back to a lawful basis you already recorded in your Records of Processing Activities. If a processing activity has ended and no legal obligation compels you to keep the data, the default is deletion. Our guide to building a Record of Processing Activities (RoPA) explains how to capture purposes and bases in a way that feeds directly into retention decisions.

Structuring the Retention Schedule

The policy states principles; the retention schedule is the operational table that staff and systems actually follow. It lists every category of personal data alongside its period, trigger, and disposal method. Keep the schedule as a living document, reviewed at least annually and whenever a new processing activity begins.

A well-formed retention schedule entry captures these fields:

• Data category (for example, customer contact details, payroll records, CCTV footage)
• Purpose of processing and the lawful basis it relies on
• Retention period, expressed as a number plus a trigger event
• Retention trigger (end of contract, last activity date, account closure)
• Legal or business justification for the chosen period
• Storage location and the system or team that owns the data
• Disposal method (secure deletion, cryptographic erasure, or anonymization)
• Review date and the person accountable for enforcement

Secure Disposal and Deletion

A retention period only means something if deletion actually happens and cannot be reversed. The policy must specify how data is destroyed at the end of its life. Recognized practice is to align disposal controls with NIST SP 800-88 or an equivalent standard, mandating irreversible and documented destruction for both digital and paper media. For structured databases, cryptographic erasure (destroying the keys that decrypt the data) is often more reliable than trying to overwrite every copy.

Anonymization is a valid alternative to deletion. Once data can no longer be linked to an identifiable person, GDPR no longer applies to it, so anonymized records can be kept for analytics without breaching storage limitation. Be careful, though: weak anonymization that still allows re-identification is not anonymization at all, and the data remains personal.

Finally, log every disposal action. Being able to show a supervisory authority that a category was deleted on a specific date, using a specific method, is what turns a written policy into demonstrable accountability. Automated retention rules in your storage systems should produce these logs by default, with a documented override for litigation holds.

Fitting Retention Into the Wider Program

A retention policy does not live alone. It draws its categories and lawful bases from your RoPA, it feeds deletion timelines into how you answer data subject erasure requests, and it belongs inside a broader records-management and information-security program. If you are standing up privacy governance from scratch, our step-by-step GDPR implementation guide sequences retention alongside the other controls you need. Teams building a formal privacy management system under ISO 27701 will find retention scheduling maps cleanly onto its documented controls.

Start small and iterate. Draft the policy, build the schedule for your highest-risk categories first, wire up automated deletion where you can, and expand coverage each review cycle. A modest schedule that is actually enforced beats an exhaustive one that no system respects.