Data Retention Policy Template

Overview

A data retention policy defines how long an organization keeps data, when it moves to lower-cost storage, and when it is permanently deleted. Use it to classify what you keep, attach periods, handle legal holds, and leave the compliance paper trail in place. A clear policy reduces storage costs, legal risk, and operational complexity.

When to Use

• Bootstrapping retention rules for a new platform or app before data piles up.
• Preparing for GDPR, CCPA, HIPAA, or SOC 2 audits — pair this policy with the Data Classification template so every category has an owner.
• Cutting storage spend by moving stale data down cheaper tiers.
• Responding to a data subject access or deletion request (see the GDPR data privacy recipe for the request-handling side).
• Defining backup and archive strategies.
• Post-breach, when the review asks why that data was still sitting there.

Prerequisites

• An inventory mapping each data type to its system and storage location.
• Legal and compliance guidance for minimum and maximum retention periods.
• Data classification scheme such as public, internal, confidential, restricted.
• Storage and backup tooling that actually understands lifecycle policies.
• A working legal-hold process — flagging, suspending deletes, releasing.
• Someone accountable for each data category or system.

Solution

Template

1. Policy Scope and Roles

Field	Description	Example
Policy name	Name of the policy	Customer Data Retention Policy
Effective date	When the policy takes effect	2026-07-01
Review cycle	How often the policy is reviewed	Annually
Policy owner	Team responsible for the policy	Data governance
Legal approver	Compliance or legal reviewer	Legal counsel
Technical owner	Team implementing controls	Platform engineering
Scope	Systems and data covered	All production databases, logs, object storage, and backups

2. Data Categories and Retention Periods

Data Category	Examples	Retention Period	Archive After	Delete After	Legal Basis
Customer account data	Profiles, preferences	Life of account + 1 year	1 year after close	2 years after close	Contract, legal obligation
Transaction records	Orders, payments	7 years	1 year	7 years after period close	Tax and financial law
Application logs	Request logs, error logs	90 days	30 days	90 days	Operational need
Security logs	Authentication, access logs	2 years	1 year	2 years after creation	Security and compliance
Backup data	Full and incremental backups	30 days	30 days	Per backup schedule	Disaster recovery
Analytics data	Aggregated events	1 year	6 months	1 year after aggregation	Legitimate interest
Marketing data	Email interactions, leads	2 years or until opt-out	1 year	On opt-out or 2 years	Consent
Temporary data	Cache, import files	7 days	3 days	7 days	Operational need

3. Retention Rules by Data Classification

Classification	Minimum Retention	Maximum Retention	Special Handling
Public	As needed by business	1 year or less	No special handling
Internal	Business need	3 years	Standard lifecycle
Confidential	Legal or contract minimum	7 years or less	Encryption, access logs
Restricted	Regulatory minimum	Regulatory maximum	Legal hold process, encryption, audit trail

4. Data Lifecycle Actions

Stage	Trigger	Action	Responsible Tool / Team
Active	Data created	Store in primary tier with access controls	Application team
Cool	30 days old	Move to lower-cost storage class	Storage lifecycle policy
Archive	1 year old	Move to archive with retrieval policy	Storage lifecycle policy
Mark for deletion	Retention period ends	Flag records and notify owners	Data governance platform
Secure deletion	Approved by legal / policy	Delete or anonymize permanently	Platform engineering
Audit log	Every lifecycle action	Log retention and deletion events	Audit logging system

5. Legal Hold and Exception Process

Scenario	Process	Owner	Documentation
Litigation hold	Suspend deletion for affected data	Legal counsel	Hold notice and scope
Regulatory investigation	Extend retention as required	Compliance officer	Regulatory request record
Data subject request	Review and delete or anonymize	Data privacy team	Request log and response
Exception request	Submit reason, risk review, approval	Data governance	Exception register
Policy override	Executive approval with legal review	C-level / legal	Signed exception record

6. Deletion and Verification Checklist

• Data owner confirms retention period has expired.
• No active legal hold covers the data.
• Data is deleted from primary storage and indexes.
• Backups containing the data are purged or scheduled for purge within policy.
• Archives are deleted or anonymized according to schedule.
• Derived datasets, caches, and replicas are refreshed or cleared.
• Deletion is logged with timestamp, owner, and scope.
• A sample spot-check confirms the deletion.
• Compliance team reviews deletion logs periodically.

Explanation

Every retention decision trades business value against legal obligation and storage cost — and getting it wrong in either direction is expensive. Putting it in writing kills the ambiguity: engineers know what to delete, auditors get evidence, and the same rules get applied every time. Classify the data, attach a period, automate the transition — that alone removes most of the manual work and stops data lingering past its useful life.

The lifecycle in section 4 follows a fixed, sequential pipeline:

Two points in that pipeline cause most real-world failures. The first is propagation: deleting from primary storage doesn’t touch backups, replicas, caches, or derived datasets — which is why the checklist in section 6 exists. The second is the legal hold gate between “mark” and “delete”: without an explicit hold check, lifecycle automation will happily purge data under litigation.

The example periods are a starting point only — legal requirements move with data type and jurisdiction, so — regulations differ by data type and jurisdiction. GDPR’s storage-limitation principle (Art. 5(1)(e)) doesn’t set fixed periods; it requires you to keep personal data “no longer than necessary” and justify each period. HIPAA requires retaining compliance documentation for six years. US tax and financial records (SOX, IRS, SEC/FINRA) commonly require seven years. In regulated environments, security and audit logs typically live anywhere from one to seven years. Anchor every row of the retention table to a named legal basis or a documented business need, and record who approved it.

The same trade-off applies to storage tiers. Hot storage (block volumes, STANDARD object class, warm log indexes) is the most expensive per GB-month and should only hold data you query often. A rough rule that consistently holds up in practice: most operational data is read in its first 30 days, rarely until day 90, and almost never afterwards — which is why the example lifecycle transitions at 30, 90, and 365 days. If your access pattern differs, measure it before setting the thresholds: query the access logs or storage analytics for a month rather than guessing. Also budget for retrieval — archive classes like Glacier and Deep Archive are cheap to store but charge per-GB retrieval fees, so data that auditors or support teams pull regularly belongs in a cool tier, not deep archive.

How to Adopt This Template

Rolling out the policy works best as five passes rather than a single big-bang rewrite:

1. Inventory — list every data store (databases, object storage, logs, caches, warehouses, backups) and the categories it holds. Retention can’t be set for data nobody inventoried.
2. Classify — apply the classification scheme from section 3 so every store maps to public, internal, confidential, or restricted.
3. Assign periods — fill the retention table row by row with a legal basis and an owner for each category. Where the law is silent, write down the business reason.
4. Automate — implement lifecycle rules (the S3 config and purge script below are starting points), and add the legal-hold gate before any deletion step.
5. Verify and review — schedule the deletion checklist quarterly, log every action, and re-run the policy after regulatory changes or new data stores.

S3 Lifecycle Policy Configuration

{
  "Rules": [
    {
      "ID": "transition-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    },
    {
      "ID": "expire-temp-data",
      "Status": "Enabled",
      "Filter": { "Prefix": "temp/" },
      "Expiration": { "Days": 7 }
    },
    {
      "ID": "retain-user-data",
      "Status": "Enabled",
      "Filter": { "Prefix": "users/" },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "Expiration": { "Days": 3650 }
    }
  ]
}

Database Retention Purge Script

-- PostgreSQL scheduled purge job
-- Run weekly via pg_cron or external scheduler

-- Purge expired sessions (retention: 30 days)
DELETE FROM sessions
WHERE created_at < NOW() - INTERVAL '30 days';

-- Purge audit logs (retention: 7 years for compliance)
-- DO NOT purge: archived separately

-- Purge deleted user data (retention: 90 days after deletion)
DELETE FROM user_data
WHERE deleted_at IS NOT NULL
  AND deleted_at < NOW() - INTERVAL '90 days';

-- Purge event logs (retention: 180 days)
DELETE FROM event_logs
WHERE created_at < NOW() - INTERVAL '180 days';

-- Vacuum and analyze after purge
VACUUM ANALYZE sessions;
VACUUM ANALYZE user_data;
VACUUM ANALYZE event_logs;

Data Classification and Retention Matrix

=== Data Classification and Retention Matrix ===

| Data Type          | Classification | Retention  | Storage         | Purge Method       |
|--------------------|----------------|------------|-----------------|--------------------|
| User PII           | Confidential   | 3 years    | Encrypted RDS   | Scheduled purge    |
| Payment records    | Restricted     | 7 years    | Encrypted RDS   | Legal hold review  |
| Audit logs         | Internal       | 7 years    | S3 Glacier      | Lifecycle policy   |
| Application logs   | Internal       | 90 days    | CloudWatch      | Auto-expire        |
| Session data       | Internal       | 30 days    | Redis           | TTL auto-expire    |
| Temporary files    | Public         | 7 days     | S3 temp/        | Lifecycle policy   |
| Analytics events   | Internal       | 2 years    | BigQuery        | Partition expire   |
| Backups            | Confidential   | 90 days    | S3 + Glacier    | Backup policy      |
| Customer exports   | Confidential   | 30 days    | S3 signed URL   | Lifecycle policy   |
| ML training data   | Internal       | 1 year     | S3 IA           | Scheduled purge    |

Variants

• Cloud object storage lifecycle policy: S3, Azure Blob, or GCP Storage rules that move or expire objects — retention enforced where storage costs least.
• Database retention policy: partition drops beat row deletes; where partitioning doesn’t fit, schedule a purge job.
• Log retention policy: app, infra, and security logs each age differently — hot retention for debugging, archive for compliance.
• Customer data retention policy: GDPR and CCPA personal data, where consent and erasure requests drive the periods.
• Healthcare data retention policy: PHI follows HIPAA’s own retention clock — plus tighter access controls on top.
• Financial data retention policy: tax and audit records belong on tamper-proof storage regulators can verify.

What Works

• Classify data before defining retention periods.
• Let the storage or database itself move data — native lifecycle features beat custom scripts.
• Apply the shortest retention that satisfies legal and business needs.
• Keep a centralized inventory of data stores and retention rules.
• Log every deletion and retention action for audit purposes.
• Train teams on legal hold and exception processes.
• Review the policy at least annually and after regulatory changes.
• Use encryption and access controls for data in retention.
• Test deletion procedures periodically to ensure data is truly removed.

Common Mistakes

• Keeping all data forever “just in case.”
• Deleting data without confirming legal hold status.
• Forgetting about backups, archives, or replicas when deleting primary data.
• Applying one flat retention period to every data type.
• Not documenting exceptions and their approvals.
• Failing to log deletion events.
• Ignoring data in third-party services or caches.
• Not reviewing retention policies after new regulations.

Troubleshooting

• Purge jobs silently don’t run: the scheduler (pg_cron, EventBridge, cron) fired but the job failed on permissions or locks. Alert on job failure and on “oldest record age” metrics, not just job success.
• Deletion doesn’t reach backups or replicas: primary data is gone but the same PII survives in a 30-day backup or a read replica. Treat backups as their own retention class with a defined propagation lag.
• Lifecycle rules delete data under legal hold: object-lock or lifecycle automation bypasses the hold flag. Add an explicit hold check to the deletion path and test it with a fixture.
• Third-party SaaS data is forgotten: analytics tools, support desks, and email providers hold copies outside your stores. Add each vendor’s retention/deletion controls to the inventory.
• Table growth after purge: DELETE frees rows but not disk space. Follow purges with VACUUM/OPTIMIZE or partition drops (dropping a partition is faster and cheaper than row deletes).