Data Retention Policy: How to Build Retention Schedules That Satisfy GDPR, SOC 2, HIPAA, and PCI DSS Auditors
Every compliance framework requires a data retention policy. Not one of them agrees on exactly what it should say.
GDPR demands that personal data be kept "no longer than is necessary." SOC 2 auditors want to see documented retention periods enforced with technical controls. HIPAA requires a minimum six-year retention floor for certain records. PCI DSS mandates that cardholder data be disposed of when it exceeds the defined retention period. A company pursuing multiple certifications simultaneously -- which describes most growing SaaS companies -- must reconcile these overlapping and sometimes conflicting requirements into a single operational policy.
Most companies fail their first audit attempt on data retention -- not because they lack a policy, but because the policy exists only on paper. Auditors test retention policies by checking whether data older than the defined period has actually been deleted, including in backup systems.
This guide covers retention requirements across major frameworks, how to build a schedule that satisfies multiple auditors, and how to implement automated deletion and legal hold capabilities.
Retention Requirements by Framework
GDPR (General Data Protection Regulation)
GDPR does not specify fixed retention periods. Instead, Article 5(1)(e) establishes the "storage limitation" principle: 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.
In practice, this means:
- You must define and document a retention period for each category of personal data
- The retention period must be justified by the processing purpose
- When the purpose expires, the data must be erased or anonymized
- You must be able to demonstrate your retention rationale to a supervisory authority
GDPR also grants data subjects the right to erasure (Article 17), which can override your retention schedule in certain circumstances. Your retention policy must account for erasure requests and define how they interact with retention obligations under other laws.
SOC 2 (Trust Services Criteria)
SOC 2 does not prescribe specific retention periods, but the Common Criteria related to information and communication (CC2.1) and risk assessment (CC3.1) require organizations to define, document, and enforce data retention and disposal policies.
Auditors evaluate whether a formal policy exists, whether retention periods are defined and justified, whether technical controls enforce disposal, and whether disposal methods match data sensitivity. SOC 2 auditors frequently cite retention as a finding when the policy says "delete after 12 months" but the database contains records from 36 months ago.
HIPAA (Health Insurance Portability and Accountability Act)
HIPAA's retention requirements are more specific than GDPR or SOC 2, but they apply to a narrower set of data:
HIPAA Administrative Simplification rules require covered entities and business associates to retain documentation related to their HIPAA compliance for six years from the date of creation or the date when the document was last in effect, whichever is later. This includes:
- Policies and procedures
- Risk assessments
- Business associate agreements
- Training records
- Incident documentation
- Audit logs
Protected Health Information (PHI) retention is governed by state law and the clinical or business purpose for which the PHI was collected, not by HIPAA directly. However, HIPAA's Security Rule requires that PHI be protected for as long as it is retained, and the Privacy Rule requires that PHI be disposed of properly when retention is no longer required.
State medical record retention laws typically require retention periods of six to ten years for adult patient records and longer for minors (often until the minor reaches the age of majority plus a specified number of years). These state requirements effectively set the floor for PHI retention.
PCI DSS (Payment Card Industry Data Security Standard)
PCI DSS takes the most prescriptive approach to retention:
Requirement 3.1 (PCI DSS v4.0, Requirement 3.2.1): Cardholder data storage must be limited to the amount and retention time required for business, legal, or regulatory purposes. Data that exceeds the defined retention period must be disposed of securely.
Requirement 3.1.1: A formal data retention and disposal policy must cover all storage locations, including databases, flat files, backup media, and log files.
Requirement 3.1.2: Quarterly processes must verify that stored cardholder data does not exceed defined retention periods. This is not annual -- PCI DSS requires quarterly validation.
Sensitive authentication data (full track data, CVV/CVC, PIN blocks) must never be stored after authorization, even in encrypted form.
PCI DSS is the most enforcement-oriented framework on retention. Assessors actively scan databases, file systems, and backup media for cardholder data that exceeds retention periods. Finding a credit card number in a log file from 18 months ago, even if the retention policy says 12 months, is a finding.
Building a Retention Schedule
A retention schedule is the operational document that translates your retention policy into enforceable rules. It defines what data you hold, why you hold it, how long you keep it, and how you dispose of it.
Step 1: Inventory Data Categories
Map every category of data your organization processes. Common categories for SaaS companies include:
| Data Category | Examples |
|---|---|
| Customer account data | Names, emails, company information, billing addresses |
| Transaction records | Invoices, payment records, subscription history |
| Product usage data | Feature usage logs, session data, API call logs |
| Support records | Tickets, chat transcripts, email correspondence |
| Employee data | HR records, payroll, benefits, performance reviews |
| Application logs | System logs, error logs, audit trails |
| Security data | Access logs, authentication records, vulnerability scan results |
| Marketing data | Lead records, email campaign data, consent records |
| Cardholder data | (if applicable) Card numbers, expiration dates |
| Protected health information | (if applicable) Patient data, clinical records |
Step 2: Map Legal and Regulatory Requirements
For each data category, identify all applicable retention requirements:
| Data Category | GDPR | SOC 2 | HIPAA | PCI DSS | Other |
|---|---|---|---|---|---|
| Customer account data | Duration of purpose + erasure | Defined period | N/A (unless PHI) | N/A (unless CHD) | State contract laws |
| Audit logs | No specific period | Defined period | 6 years | 1 year minimum | SOX: 7 years |
| Cardholder data | N/A | Defined period | N/A | Business need only | State payment laws |
| PHI | N/A | Defined period | 6 years (compliance docs); state law (records) | N/A | State medical records laws |
Step 3: Define Retention Periods and Disposal Methods
For each data category, set a retention period that satisfies the most restrictive applicable requirement. Use the longest required minimum as your floor and GDPR's necessity principle as your ceiling. Where no specific legal period applies, define a business-justified retention period (typically 1-3 years for operational data). Document the rationale for every retention period -- auditors across all frameworks ask why you chose the period you chose.
Disposal methods must match data sensitivity: standard deletion for non-sensitive data, secure deletion with verification for internal data, and cryptographic erasure or certified media destruction for regulated data (PII, PHI, cardholder data).
Automated Deletion
A retention policy without automated enforcement is a policy that will fail audit. Manual deletion processes are inconsistent, unverifiable, and do not scale.
Database-level retention. Implement time-based partitioning or scheduled jobs that identify and delete records exceeding their retention period. PostgreSQL's table partitioning by date range, combined with scheduled partition drops, is a common pattern. Document the automation and log every execution.
Object storage retention. Cloud storage services (S3, GCS, Azure Blob) support lifecycle policies that automatically transition or delete objects after defined periods. Configure lifecycle rules for each bucket based on the data category it contains.
Log retention. Centralized logging platforms (Elasticsearch, Datadog, Splunk) support index lifecycle management with automatic deletion after defined retention periods. Configure these at the index level and verify that deleted indices are not recoverable from snapshots.
Backup data. This is where most retention programs fail. Production data may be correctly deleted after 12 months, but backup snapshots from 24 months ago still contain that data. Your retention schedule must cover backup media. Options include: rotating backup retention (delete backups older than the longest retention period), or cryptographic erasure (encrypt backups with keys that are destroyed when the retention period expires).
Legal Holds
A legal hold suspends normal retention and deletion processes for data that is relevant to pending or reasonably anticipated litigation, regulatory investigation, or audit.
Your retention system must support legal holds without breaking automated deletion. This requires: a process for legal counsel to identify data subject to hold; a technical mechanism to flag held data as exempt from automated deletion (metadata tags, separate hold databases, or object lock features); a documented process for releasing holds when the legal matter concludes; and an audit trail logging every hold placement, modification, and release with timestamps and scope.
Common Audit Findings
Based on patterns across SOC 2, HIPAA, PCI DSS, and GDPR audits, the most frequent data retention findings are:
- No documented retention schedule. A high-level policy exists, but no schedule maps specific data categories to specific retention periods.
- Retention periods not enforced. The schedule says 12 months, but the database contains data from 36 months ago.
- Backup data excluded. Production data is deleted on schedule, but backup data is retained indefinitely.
- No disposal verification. Data is "deleted" but no verification confirms that deletion was complete and the data is unrecoverable.
- Log retention undefined. Application and security logs have no defined retention period and grow indefinitely.
- Legal holds undocumented. Data is preserved for legal reasons, but no formal hold process or documentation exists.
- Inconsistent retention across environments. Production data follows the schedule, but staging, development, and analytics environments contain copies with no retention controls.
- Cardholder data in unexpected locations. PCI DSS assessors find card numbers in log files, support tickets, or email archives outside the defined cardholder data environment.
Where QuickTrust Fits
QuickTrust helps SaaS companies build data retention programs that satisfy multiple compliance frameworks simultaneously. The platform maps retention requirements across GDPR, SOC 2, HIPAA, and PCI DSS to your specific data categories, generates retention schedules with documented rationale, and identifies gaps in your current retention practices.
Our engineering team implements the technical controls: automated deletion pipelines, backup lifecycle management, legal hold systems, and audit logging for disposal verification. The result is a retention program that passes audits across frameworks -- not a policy document that sits in a shared drive.
With a 100% audit pass rate across 100+ engagements and audit readiness in as few as 8 weeks, QuickTrust turns data retention from a recurring audit finding into a resolved control. Schedule a 20-minute readiness call to assess your retention posture and identify the gaps auditors will find before they do.