---
name: design-a-data-retention-policy
category: data
description: Design a data-retention policy across purposes, systems, jurisdictions, records, legal holds, backups, deletion, and proof. Use when deciding how long information is kept and how its disposal is governed.
---

# design-a-data-retention-policy

Retention is a lifecycle control, not only a table of durations. This is not legal advice.

## When to use

- Use for personal, financial, operational, security, research, content, or regulated records.
- Obtain qualified legal, privacy, tax, records, security, and jurisdictional review.

## Procedure

1. Inventory data classes, purposes, subjects, owners, systems, replicas, exports, vendors, countries, and record obligations.
2. Identify minimum and maximum retention requirements, consent or contract limits, limitation periods, and business needs.
3. Define the event that starts each retention period, including closure, transaction, last activity, consent withdrawal, or supersession.
4. Map active, archive, backup, log, cache, analytics, derived, test, vendor, and physical copies.
5. Define legal-hold authority, scope, notice, suspension, review, release, and conflict handling.
6. Specify deletion, anonymization, archival, proof, failure, retry, and restore-from-backup behavior.
7. Set access, encryption, minimization, review cadence, exception, and change-control requirements throughout retention.
8. Test representative records from creation through expiry, hold, deletion, backup restoration, and downstream propagation.

## Done

- A retention policy document, schedule, and lifecycle map record data class, purpose, trigger, duration, jurisdiction, systems, holds, disposal, and owners
- Active, archive, backup, vendor, legal-hold, expiry, deletion, restoration, and evidence tests verify policy execution