A data retention policy is one of the first documents SOC 2 and ISO 27001 auditors ask for — and one of the most commonly missing or half-written controls in early-stage compliance programs. This guide walks through what a data retention policy is, why frameworks require it, and how to write one your auditor will actually accept. A downloadable checklist and sample retention schedule are included at the end.
What is a data retention policy?
A data retention policy is a formal, written document that defines how long each category of data your organization holds is kept, where it is stored, and how it is securely disposed of when the retention period ends. It covers customer data, employee records, financial records, application logs, backups, and any other information asset your business processes.
At its core, a good policy answers four questions for every data category: What is it? How long do we keep it? Why that long? How do we destroy it?
Data retention vs. data destruction vs. records management
These three terms are related but distinct. Retention defines the lifespan of data, destruction defines the secure end-of-life process, and records management is the broader operational program that governs both. SOC 2 and ISO 27001 expect you to address all three, usually inside a single policy document.
Why SOC 2 and ISO 27001 require a data retention policy
Both frameworks tie data retention to core Trust Services Criteria and Annex A controls. Missing or vague retention rules will show up as a finding in almost every audit.
SOC 2 mapping
- CC6.5 — The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data has been diminished.
- CC6.7 — The entity restricts the transmission, movement, and removal of information to authorized users and processes, and protects it during transmission, movement, or removal.
- C1.2 (Confidentiality) — The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
- P4.2 / P4.3 (Privacy) — Personal information is retained consistent with the entity's objectives and is disposed of securely.
ISO 27001:2022 mapping
- A.5.33 — Protection of records
- A.5.34 — Privacy and protection of PII
- A.8.10 — Information deletion
- A.8.12 — Data leakage prevention
- A.8.13 — Information backup (retention of backups)
On top of framework requirements, most retention schedules are also driven by regulation: GDPR Article 5(1)(e) (storage limitation), HIPAA §164.316(b)(2) (six-year retention for policies and records), PCI DSS Requirement 3.2 (do not store what you do not need), and country-specific tax or employment laws.
How to write a data retention policy — step by step
Step 1: Inventory your data
You cannot set retention rules for data you have not identified. Start with a data inventory that lists every system of record — production databases, backups, data warehouses, SaaS tools, HR systems, ticketing tools, email, and file shares. For each, capture the data categories stored, the data owner, and whether the data contains PII, PHI, or cardholder data.
Step 2: Classify the data
Map each category to your existing information classification scheme (typically Public, Internal, Confidential, Restricted). Classification drives both the retention period and the disposal method. Restricted data almost always requires cryptographic erasure or physical destruction rather than a simple delete.
Step 3: Define retention periods with a legal and business justification
For every data category, document the retention period and the reason. Auditors will push back on "we keep it forever" — every period needs a defensible source: a specific law, a contractual obligation, or a documented business need. When multiple rules apply, the longest applicable period wins.
Step 4: Define the disposal method
Approved methods should map to NIST SP 800-88 media sanitization guidance: clear, purge, or destroy. Cloud databases usually rely on cryptographic erasure (deleting the KMS key), physical drives require purge or destroy, and paper records require cross-cut shredding.
Step 5: Assign ownership and review cadence
Name a single policy owner (typically the CISO, DPO, or Head of Security) and require an annual review. Log the review date and approver — auditors will ask.
Step 6: Operationalize with automation
A policy that is not enforced is a finding waiting to happen. Automate retention wherever possible: S3 lifecycle rules, database TTLs, log-aggregator retention settings, SaaS admin controls, and scheduled jobs for purging soft-deleted records. Keep evidence of the automation configuration — screenshots and IaC snippets both work.
Sample data retention schedule
Use the table below as a starting point. Adjust periods to reflect your jurisdiction and contractual commitments.
| Data category | Retention period | Justification | Disposal method |
|---|---|---|---|
| Customer account data (active) | Duration of contract | Business need, contractual | Cryptographic erasure |
| Customer account data (terminated) | 90 days after termination | Contractual grace period | Cryptographic erasure |
| Application logs | 13 months | Security investigations, SOC 2 CC7.2 | Automated purge in log platform |
| Audit logs (security-relevant) | Minimum 1 year, 90 days hot | PCI DSS 10.7, SOC 2 CC7.2 | Automated purge |
| Backups | 35 days rolling | RTO/RPO, business continuity | Cryptographic erasure |
| Financial records | 7 years | Tax and accounting law | Secure deletion |
| Employee records | 7 years after termination | Employment law | Secure deletion / shred |
| Job applicant data (not hired) | 12 months | Anti-discrimination laws, GDPR | Automated purge |
| Vendor risk assessments | Duration of relationship + 2 years | SOC 2 CC9.2 | Secure deletion |
| Policies and procedures | Current + 6 years of superseded versions | SOC 2, HIPAA §164.316(b)(2) | Archive then secure delete |
Sample data retention policy structure
- Purpose — Why the policy exists.
- Scope — Which systems, data types, and personnel are covered.
- Roles & responsibilities — Policy owner, data owners, IT operations, HR, Legal.
- Definitions — Data categories, classification levels, disposal methods.
- Retention schedule — The table above, tailored to your business.
- Disposal & sanitization requirements — Mapped to NIST 800-88.
- Legal holds & exceptions — Process to suspend deletion during litigation or investigation.
- Enforcement & monitoring — How compliance is measured and evidenced.
- Review & approval — Cadence, owner, approver, version history.
Data retention policy checklist
- Data inventory covers every production system, backup, and SaaS tool
- Each data category has a documented retention period and justification
- Disposal method is defined per category and maps to NIST 800-88
- Automated enforcement exists for logs, backups, and soft-deleted records
- Legal hold process is documented and tested
- Policy is reviewed and approved annually
- Evidence of enforcement (screenshots, IaC, tickets) is stored in your audit evidence repository
- Employees are trained on the policy at onboarding and annually
Common auditor findings to avoid
- "Indefinite" retention without a justification.
- Backups retained longer than the underlying primary data (a GDPR problem).
- No documented disposal method — only "delete".
- No legal-hold process, so deletion never pauses during investigations.
- Policy exists, but no evidence that automated retention rules actually run.
Next steps
Once your retention policy is drafted, wire it into your SOC 2 or ISO 27001 control matrix, assign evidence owners for each retention rule, and schedule the first annual review. If you use a GRC platform, load the retention schedule as a set of tracked controls so quarterly reviews surface drift automatically.