Data Retention Policy: How to Build Retention Schedules That Satisfy GDPR, SOC 2, HIPAA, and PCI DSS Auditors

Your company stores data. A lot of it. Customer records, transaction logs, access logs, support tickets, analytics events, backup snapshots, employee files, vendor contracts. Every SaaS company accumulates data faster than it deletes data -- and most never delete anything at all.

Then an auditor asks a simple question: "Show me your data retention policy."

The question sounds administrative. It is not. Behind it sits a cascade of legal, regulatory, and contractual obligations that touch every compliance framework your company operates under. GDPR requires you to delete personal data when you no longer have a lawful basis to retain it. SOC 2 auditors evaluate whether you have defined retention periods and actually enforce them. HIPAA mandates minimum retention periods for certain records while requiring you to limit PHI retention to what is necessary. PCI DSS requires you to define cardholder data retention periods and implement processes to securely delete data that exceeds them.

A data retention policy is not a document you write to satisfy one auditor. It is the foundational governance mechanism that determines how long every category of data in your organization lives, why it lives that long, and exactly what happens to it when that period expires. Companies that get this right reduce their compliance burden, limit their breach exposure surface, and pass audits without scrambling. Companies that get it wrong face regulatory fines, audit findings, and the compounding risk of storing data they have no legal basis to keep.

This guide walks through how to build a data retention policy that satisfies multiple compliance frameworks simultaneously -- with specific retention periods, destruction methods, templates, and the operational processes that turn a policy document into an enforceable program.

What Is a Data Retention Policy?

A data retention policy is a formal document that defines how long an organization retains different categories of data, the legal or business justification for each retention period, and the methods used to destroy data when that period expires.

The policy serves three distinct purposes:

1. Legal compliance. Multiple regulations impose obligations on how long data must be kept and when it must be deleted. GDPR's storage limitation principle (Article 5(1)(e)) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." HIPAA requires covered entities to retain certain documentation for six years. Tax regulations require financial records to be kept for specific periods. A data retention policy maps these overlapping obligations to specific data categories in your organization.

2. Risk reduction. Every byte of data you store is a byte of data that can be breached, subpoenaed, or misused. Data you have deleted cannot be exfiltrated in a breach, cannot be disclosed in litigation discovery, and cannot be accessed by unauthorized insiders. A well-enforced data retention policy systematically reduces your organization's attack surface over time.

3. Operational efficiency. Retaining data indefinitely has direct costs: storage infrastructure, backup management, database performance degradation, and the engineering effort required to manage growing datasets. It also has indirect costs: every data migration, schema change, and system upgrade becomes harder when you are carrying years of data that no one needs and no regulation requires.

A data retention policy is not a suggestion document. It is a governance control -- one that auditors across every major compliance framework evaluate for both existence and enforcement. Having the policy is the minimum. Demonstrating that the policy is consistently applied, with evidence that data is actually destroyed on schedule, is what separates organizations that pass audits from those that receive findings.

Why Every Compliance Framework Requires Data Retention Rules

Data retention is not a niche compliance concern. It is a cross-cutting requirement that appears in every major framework SaaS companies encounter. The specific language differs, but the underlying principle is consistent: organizations must define how long they keep data and must not keep it longer than necessary.

GDPR's fifth data protection principle states that personal data shall be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." This is not a recommendation. It is a binding legal obligation, enforceable through fines of up to 20 million euros or 4% of global annual turnover.

The storage limitation principle means that retaining personal data "just in case" or "because storage is cheap" is a GDPR violation. Every category of personal data in your systems must have a defined retention period tied to a specific processing purpose. When that purpose expires, the data must be deleted or anonymized.

European Data Protection Authorities have issued fines specifically for excessive data retention. In 2022, the French CNIL fined Clearview AI EUR 20 million, and retention practices have been cited in multiple enforcement actions since. The principle is actively enforced.

[For a complete breakdown of GDPR requirements for US SaaS companies, see our GDPR Compliance Guide.]

SOC 2 -- Common Criteria and Privacy Principles

SOC 2 addresses data retention through multiple Trust Services Criteria. The Privacy category's P6.1 criterion requires that personal information be retained only for the period necessary to fulfill the purposes stated in the entity's privacy notice. The Common Criteria CC1.1 and related controls require that the organization defines and documents its information security policies, which auditors expect to include data retention.

SOC 2 auditors do not prescribe specific retention periods. Instead, they evaluate whether your organization has defined retention periods for different data types, documented them in policy, and can demonstrate enforcement. The gap auditors most frequently identify is not the absence of a policy but the absence of evidence that the policy is followed -- no deletion logs, no automated retention enforcement, and no periodic reviews of stored data against defined retention periods.

HIPAA -- 45 CFR Section 164.530(j)

HIPAA's Privacy Rule requires covered entities and business associates to retain certain documentation for six years from the date of creation or the date when the document was last in effect, whichever is later. This applies to policies and procedures, privacy practices notices, disposition of complaints, and other documentation required by the Privacy Rule.

Critically, HIPAA does not require that Protected Health Information (PHI) itself be retained for six years. The six-year requirement applies to HIPAA compliance documentation, not to patient data. However, state medical records retention laws often require longer retention of patient records -- some states mandate 10 years, and records for minors may need to be retained until a specified period after the patient reaches the age of majority.

For SaaS companies operating as Business Associates, the intersection of HIPAA documentation retention requirements and state medical records laws creates a complex matrix. Your data retention policy must account for both.

[See our complete HIPAA Compliance Guide for details on Business Associate obligations.]

PCI DSS -- Requirement 3.1

PCI DSS Requirement 3 focuses on protecting stored cardholder data. Requirement 3.1 (now mapped to Requirement 3.2.1 in PCI DSS v4.0) mandates that organizations define a data retention and disposal policy for cardholder data. The policy must limit cardholder data storage to the minimum amount and retention time required for business, legal, and regulatory purposes.

PCI DSS is more prescriptive than most frameworks. Requirement 3.3 (v4.0) specifies that sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization, even if encrypted. Primary Account Numbers (PANs) may be stored if there is a defined business need, but must be rendered unreadable using specified methods and must be subject to defined retention periods.

Qualified Security Assessors (QSAs) conducting PCI DSS audits specifically test whether stored cardholder data exceeds defined retention periods. They examine databases, file systems, and backup media for data that should have been deleted. This is one of the most common PCI DSS audit findings.

SOX -- Sarbanes-Oxley

While SOX primarily applies to publicly traded companies, its record retention requirements affect many SaaS companies that serve public companies or are preparing for IPO. SOX Section 802 requires retention of audit work papers and related documents for seven years. Financial records, accounting data, and supporting documentation must be retained for periods sufficient to support financial reporting and audit requirements.

Data Retention Requirements by Framework: Comparison Table

The following table consolidates the specific data retention requirements across major compliance frameworks. Use it as a reference when building your retention schedule.

Data Category	GDPR	SOC 2	HIPAA	PCI DSS	SOX
Personal data (general)	Only as long as necessary for stated purpose; no fixed period	Defined by entity's policy; must match privacy notice	N/A (unless PHI)	N/A (unless cardholder data)	N/A
Employee records	Duration of employment + statutory period (varies by EU member state; typically 2-10 years)	Per entity policy	N/A	N/A	7 years (if related to financial reporting)
HIPAA compliance documentation	N/A	N/A	6 years from creation or last effective date	N/A	N/A
Protected Health Information (PHI)	N/A (unless data subjects are EU residents)	Per entity policy	Per state law (typically 6-10 years; minors: until age of majority + state period)	N/A	N/A
Cardholder data (PAN)	Per stated purpose	Per entity policy	N/A	Minimum necessary; per entity's defined retention period	N/A
Sensitive authentication data	N/A	N/A	N/A	Must not be stored after authorization	N/A
Security logs / audit trails	Per stated purpose (typically 1-2 years)	Per entity policy (auditors expect 90 days - 1 year minimum)	N/A (recommended: 6 years to match documentation requirement)	12 months minimum; 3 months immediately available (Req 10.7)	7 years
Financial / accounting records	Per stated purpose and local tax law	Per entity policy	N/A	N/A	7 years
Contracts and legal agreements	Duration of contract + statute of limitations (typically 6-10 years)	Per entity policy	6 years (if related to HIPAA compliance)	Per entity policy	7 years
Backup media	Must not exceed primary data retention periods (requires backup rotation)	Per entity policy	Per PHI retention requirements	Per cardholder data retention policy	Per financial records retention
Incident response records	Per stated purpose	Per entity policy	6 years	Per entity policy	7 years

Key observation: GDPR is the only framework that imposes a maximum retention obligation (you must delete data when the purpose expires). Most other frameworks impose minimum retention obligations (you must keep data for at least X period). Your retention policy must satisfy both directions simultaneously -- retaining data long enough to meet minimums while deleting it promptly enough to meet maximums.

Building a Data Retention Schedule: Step-by-Step

A data retention schedule is the operational document that translates your retention policy into specific, actionable rules for every data category in your organization. Building one requires four phases.

Step 1: Conduct a Data Inventory

You cannot define retention periods for data you have not cataloged. A data inventory (sometimes called a data map or record of processing activities under GDPR Article 30) identifies every category of data your organization collects, stores, and processes.

For each data category, document:

Data type and description: What the data contains (e.g., "customer billing records," "application access logs," "employee onboarding documents")
Data classification: Sensitivity level (public, internal, confidential, restricted)
Storage locations: Every system, database, file share, SaaS tool, and backup medium where this data resides
Data subjects: Whose data this is (customers, employees, prospects, patients, cardholders)
Processing purpose: Why you collect and store this data
Legal basis (GDPR): Which of the six lawful bases applies (consent, contract, legal obligation, vital interests, public task, legitimate interests)
Data controller/processor role: Whether you are the controller or processor for this data
Cross-border transfers: Whether this data is transferred outside its originating jurisdiction

This inventory is the foundation of your retention schedule. It is also a GDPR requirement (Article 30 ROPA) and a common SOC 2 auditor request.

Step 2: Classify Data by Regulatory Regime

Once your inventory is complete, map each data category to every applicable regulatory framework. A single data element may be subject to multiple overlapping requirements:

A European patient's health record stored in your SaaS application is simultaneously subject to GDPR (personal data of an EU data subject), HIPAA (PHI processed by a Business Associate), and potentially state medical records retention laws.
A European customer's credit card number used for subscription billing is subject to GDPR (personal data), PCI DSS (cardholder data), and potentially SOX (financial record supporting revenue recognition).

For each data category, list every applicable framework and the specific requirement. This mapping reveals where conflicts exist -- where one framework requires deletion while another requires retention.

Step 3: Assign Retention Periods

For each data category, define a retention period that satisfies all applicable requirements. The general principle is:

Retain data for the longest applicable minimum retention period, then delete it as soon as that period expires (to satisfy maximum retention obligations).

When assigning periods, use these guidelines:

Start with the legal minimum. If HIPAA requires six years and GDPR requires deletion when the purpose expires, the retention period must be at least six years (to satisfy HIPAA) and should not exceed it without additional justification (to satisfy GDPR's storage limitation).
Add a reasonable buffer for litigation holds. Many organizations add the relevant statute of limitations period to their retention calculation. For contract disputes, this is typically 4-6 years in the US and varies by EU member state.
Define the retention trigger. Retention periods must start from a defined event: date of creation, date of last activity, date of account closure, end of contract term, or date of employee termination. "From creation" and "from last activity" produce very different results.
Document the justification. For every retention period, record why that specific duration was chosen and which regulatory requirements it satisfies. Auditors ask for this rationale.

Step 4: Define Destruction Methods

Every retention period must have a corresponding destruction method defined. "Delete the data" is not sufficient -- auditors need to know how data is destroyed, whether the destruction is verifiable, and whether it applies to all copies including backups.

We cover destruction methods in detail in a dedicated section below.

Data Retention Schedule Template

The following template provides a starting point for SaaS companies building a multi-framework retention schedule. Adjust the specific periods and methods to match your organization's regulatory obligations, business requirements, and risk tolerance.

Data Category	Data Classification	Retention Period	Retention Trigger	Legal Basis / Justification	Applicable Frameworks	Destruction Method	Responsible Team
Customer account data (name, email, company)	Confidential	Duration of service + 3 years	Account closure or contract termination	Contract performance (GDPR Art. 6(1)(b)); statute of limitations for contract claims	GDPR, SOC 2	Logical deletion from production databases; anonymization in analytics systems; backup rotation (90-day cycle)	Engineering / Data team
Customer billing records	Confidential	7 years from transaction date	Transaction date	Legal obligation (GDPR Art. 6(1)(c)) -- tax and accounting requirements; SOX record retention	GDPR, SOC 2, SOX	Logical deletion from production; archived records destroyed via secure deletion after 7-year period	Finance / Engineering
Protected Health Information (PHI)	Restricted	10 years from last date of service (or per applicable state law, whichever is longer)	Last date of service or last activity	Legal obligation (HIPAA, state medical records laws)	HIPAA, GDPR (if EU data subjects), SOC 2	Crypto-shredding for encrypted stores; logical deletion with verification; certified destruction of physical media	Compliance / Engineering
Cardholder data (PAN, expiration date)	Restricted	Duration of active subscription + 90 days	Subscription cancellation or card replacement	Contract performance; PCI DSS business need documentation	PCI DSS, GDPR, SOC 2	Secure deletion from all storage (production, logs, backups); tokenized data: token deactivation	Engineering / Payment operations
Sensitive authentication data (CVV, full track data)	Restricted	Not stored	N/A -- must not be retained after authorization	PCI DSS Requirement 3.3	PCI DSS	Ensure payment processor handles; verify non-storage via quarterly scans	Engineering / Payment operations
Application access logs	Internal	1 year	Log creation date	Legitimate interest (GDPR Art. 6(1)(f)) -- security monitoring; PCI DSS Req 10.7	GDPR, SOC 2, PCI DSS, HIPAA	Automated purge from log management system; backup rotation	Security / Engineering
Security incident records	Confidential	6 years from incident closure	Incident closure date	Legal obligation (HIPAA documentation retention); legitimate interest (GDPR)	HIPAA, GDPR, SOC 2	Secure deletion from incident management system; archived records destroyed per schedule	Security / Compliance
Employee HR records	Confidential	Duration of employment + 7 years	Employment termination date	Legal obligation (tax, labor law); legitimate interest (GDPR)	GDPR, SOX	Logical deletion from HRIS; physical records: certified shredding	HR / Legal
Marketing consent records	Internal	Duration of consent + 3 years	Consent withdrawal or last marketing communication	Consent (GDPR Art. 6(1)(a)); accountability obligation (GDPR Art. 5(2)) -- must demonstrate valid consent was obtained	GDPR	Logical deletion; consent proof retained in anonymized form for accountability	Marketing / Legal
Vendor contracts and DPAs	Confidential	Duration of contract + 6 years	Contract termination	Legal obligation (HIPAA); statute of limitations for contract claims	HIPAA, GDPR, SOC 2	Secure deletion from contract management system; physical copies: certified shredding	Legal / Procurement
Backup media (all categories)	Per source data classification	Must not exceed primary data retention + backup rotation cycle (e.g., 90-day rotation)	Per source data retention trigger	Per source data legal basis	All applicable frameworks	Backup rotation with verified overwrite; crypto-shredding for encrypted backups; physical destruction for decommissioned media	Engineering / IT operations

Important notes on this template:

Retention periods shown are examples based on common regulatory interpretations. Your organization's legal counsel should validate specific periods against your jurisdiction, customer contracts, and applicable regulations.
State-specific laws (particularly for medical records and employee records) may impose longer retention periods than shown here.
The "Retention Trigger" column is critical. An auditor will ask not just "how long do you keep this data?" but "how long from when?" Define triggers precisely.

[For guidance on structuring Data Processing Agreements that align with your retention schedule, see our Data Processing Agreement Guide.]

Data Destruction: Methods and Compliance Requirements

Defining retention periods is half the problem. The other half is proving that data is actually destroyed when those periods expire. Auditors across all frameworks evaluate not just your retention policy but your destruction processes and evidence.

Logical Deletion

Logical deletion marks data as deleted in the application layer -- removing it from user interfaces, API responses, and query results -- without immediately removing it from the underlying storage medium.

When it is appropriate: For data in production databases where immediate physical deletion would create referential integrity issues or performance problems.

Compliance considerations: Logical deletion alone is not sufficient for most regulatory purposes unless the data is made genuinely inaccessible. GDPR requires that data be put "beyond use" -- meaning it cannot be accessed, used, or recovered through normal business processes. A soft-delete flag that any engineer can reverse by running a database query does not satisfy this standard.

Best practice: Implement logical deletion as the first step, followed by a hard deletion process that permanently removes the data after a short grace period (7-30 days) to allow for accidental deletion recovery. Document both steps.

Crypto-Shredding

Crypto-shredding (also called cryptographic erasure) destroys data by destroying the encryption keys used to encrypt it. If data is encrypted with a unique key and that key is permanently deleted, the encrypted data becomes permanently unrecoverable -- even though the ciphertext remains on the storage medium.

When it is appropriate: For data stored in encrypted formats where deleting individual records from the underlying storage is impractical (e.g., encrypted backup archives, encrypted database tablespaces, cloud storage with customer-managed encryption keys).

Compliance considerations: Crypto-shredding is recognized as a valid destruction method by multiple frameworks and regulatory bodies. NIST SP 800-88 acknowledges cryptographic erasure as a media sanitization technique. The UK ICO has accepted it as a valid means of rendering personal data irrecoverable.

Requirements for compliance:

The encryption must use a strong algorithm with adequate key length (AES-256 or equivalent)
Keys must be managed through a formal key management system with documented key destruction procedures
Key destruction must be logged and auditable
There must be no copies of the key in any system, backup, or escrow

Best practice: Crypto-shredding is particularly effective for backup data. Rather than attempting to selectively delete records from backup archives (which is technically challenging and often impossible), encrypt backups with unique keys and destroy those keys when the retention period expires.

Physical Destruction

Physical destruction permanently renders storage media unusable. Methods include degaussing (for magnetic media), shredding, disintegration, and incineration.

When it is appropriate: For decommissioned hard drives, SSDs, tapes, and other physical media that contained sensitive data. Also required when returning leased equipment or disposing of end-of-life hardware.

Compliance considerations: PCI DSS Requirement 9.4.6 (v4.0) specifically addresses destruction of media containing cardholder data. NIST SP 800-88 provides detailed guidance on media sanitization methods appropriate for different media types and data sensitivity levels.

For SaaS companies using cloud infrastructure: Physical destruction of cloud storage media is the cloud provider's responsibility. Verify that your cloud provider's data destruction practices meet your compliance requirements. AWS, GCP, and Azure all publish documentation on their media destruction procedures. Your responsibility is to ensure logical deletion and crypto-shredding of your data within the cloud environment.

Certificates of Destruction

A certificate of destruction is a formal document attesting that specified data or media has been destroyed according to defined procedures. Certificates should include:

Description of data or media destroyed
Destruction method used
Date and time of destruction
Name and signature of the individual who performed or witnessed the destruction
Reference to the applicable retention policy and schedule

Auditor expectations: SOC 2 auditors request certificates of destruction as evidence that your retention policy is enforced. PCI DSS QSAs specifically check for documented destruction processes. HIPAA requires documentation of PHI disposal. Maintain certificates of destruction for the same period as your compliance documentation retention period (typically 6-7 years).

Data Retention for SaaS Companies: Special Considerations

SaaS companies face data retention challenges that traditional enterprises do not. Multi-tenant architectures, continuous deployment cycles, and cloud-native infrastructure create specific complications for retention policy implementation.

Multi-Tenant Databases

Most SaaS applications store data from multiple customers in shared database infrastructure. When one customer's data reaches the end of its retention period -- or when a customer exercises their right to erasure -- you must delete that customer's data without affecting other customers' data in the same tables, indexes, and storage systems.

Implementation approach:

Design database schemas with tenant isolation that supports per-tenant data deletion
Implement cascade deletion logic that identifies and removes all data associated with a specific tenant across all tables and services
Test deletion completeness regularly -- run queries to verify that no orphaned data remains after tenant deletion
Document the deletion scope for auditors: which tables, services, caches, and derived datasets are included in the deletion process

Backup Retention

Backups are the most common failure point in data retention compliance. Your production systems may enforce retention periods perfectly, but if your backups contain data that should have been deleted, you are not compliant.

The problem: Point-in-time backups contain a complete snapshot of your data at the time of backup creation. Deleting a record from production does not remove it from existing backups. If your backup retention period exceeds your data retention period, you are storing data longer than your policy permits.

Solutions:

Align backup rotation with retention policy. If your shortest data retention period is 1 year, your backup retention should not exceed 1 year.
Use crypto-shredding for backup archives. Encrypt backups with rotating keys. When data reaches its retention period, destroy the encryption key for the backup set containing that data.
Document the backup exception. If immediate deletion from backups is technically infeasible, document this in your retention policy, define the maximum period before backup rotation eliminates the data, and implement controls to prevent restoration of deleted data from backups. GDPR supervisory authorities have generally accepted reasonable backup rotation periods as part of deletion compliance, provided the organization has documented the limitation and taken steps to minimize the delay.

Application Logs

Logs present a unique retention challenge because they often contain personal data embedded within operational data. A web server access log contains IP addresses (personal data under GDPR). An application error log may contain user IDs, email addresses, or other identifiers. An audit trail log records which user performed which action.

Approach:

Classify logs by the personal data they contain, not by their operational purpose
Implement log rotation periods that align with your retention schedule
Where possible, pseudonymize or anonymize personal data in logs at the point of creation (e.g., truncate IP addresses, hash user IDs)
Ensure your log management platform (Splunk, Datadog, ELK, etc.) supports automated retention policies and can certify deletion

Analytics and Derived Data

Analytics data, machine learning training data, and derived datasets (aggregations, statistical models, reporting cubes) may be created from personal data. Under GDPR, if the derived data can be linked back to an individual -- directly or indirectly -- it is still personal data and subject to retention and deletion requirements.

Approach:

Ensure analytics data is truly anonymized (not merely pseudonymized) if you intend to retain it beyond the source data's retention period
Document the anonymization methodology and verify that re-identification is not reasonably possible
When deleting source data, audit derived datasets to ensure they do not contain identifiable information from the deleted records

GDPR Article 17 grants data subjects the right to erasure ("right to be forgotten"). When a data subject exercises this right, your organization must delete their personal data -- unless a legal exception applies.

The tension between the right to erasure and data retention requirements is one of the most operationally complex areas of data governance. A data subject requests deletion of their data, but your retention schedule says you must keep certain categories of that data for regulatory or legal reasons.

When You Must Delete

You must comply with an erasure request when:

The personal data is no longer necessary for the purpose it was collected
The data subject withdraws consent and there is no other legal basis for processing
The data subject objects to processing and there are no overriding legitimate grounds
The data was processed unlawfully
Deletion is required to comply with a legal obligation

When You Can Refuse

You may refuse an erasure request when retention is necessary for:

Compliance with a legal obligation (e.g., tax records, HIPAA documentation, anti-money laundering records)
Establishment, exercise, or defense of legal claims
Public health purposes
Archiving in the public interest, scientific or historical research, or statistical purposes (with appropriate safeguards)

Operational Implementation

Build an erasure request workflow that:

Receives and logs the request. Record the data subject's identity, the date of the request, and the specific data they want deleted.
Verifies the data subject's identity. You must confirm the requester is who they claim to be before deleting data. Deleting someone else's data based on an unverified request is itself a data protection failure.
Maps the request to your data inventory. Identify every system, database, log, backup, and third-party service that contains the data subject's personal data.
Evaluates retention exceptions. For each data category, determine whether a legal basis for continued retention exists. Document the evaluation.
Executes partial or full deletion. Delete all data for which no retention exception applies. For data you must retain, inform the data subject of the specific legal basis for continued retention.
Confirms completion. Respond to the data subject within the GDPR-mandated timeline (one month, extendable by two months for complex requests) with confirmation of what was deleted, what was retained, and why.
Documents the entire process. Maintain an auditable record of the request, evaluation, deletion actions, and response.

Common mistake: Refusing the entire erasure request because some data must be retained. GDPR requires you to delete the data you can delete and retain only the data you have a legal basis to retain. A blanket refusal when partial deletion is possible is itself a violation.

Data Retention Automation: Tools and Approaches

Manual data retention enforcement does not scale. A SaaS company with dozens of data categories stored across multiple databases, SaaS tools, log management systems, and backup repositories cannot rely on calendar reminders and manual deletion processes.

Automated Retention Enforcement

Implement automated processes that:

Tag data with retention metadata at creation. When a record is created, assign it a retention category, retention period, and calculated expiration date. Store this metadata alongside the data.
Run scheduled retention jobs. Automated processes (cron jobs, scheduled Lambda functions, or database maintenance procedures) that query for expired data and execute deletion. Run these at least monthly; weekly is better.
Generate deletion logs. Every automated deletion must produce an auditable log entry recording what was deleted, when, by what process, and under what retention rule.
Alert on failures. Retention jobs that fail to execute should trigger alerts. A missed retention cycle means data is stored beyond its authorized period.

Retention Policy as Code

For engineering-driven organizations, define retention policies in code rather than documents:

# Example: retention-policy.yaml
retention_rules:
  - data_category: customer_account_data
    retention_period_days: 1095  # 3 years post-closure
    retention_trigger: account_closure_date
    destruction_method: logical_delete_then_hard_delete
    hard_delete_grace_period_days: 30
    applicable_frameworks: [GDPR, SOC2]

  - data_category: application_access_logs
    retention_period_days: 365
    retention_trigger: log_creation_date
    destruction_method: automated_purge
    applicable_frameworks: [GDPR, SOC2, PCI_DSS]

  - data_category: cardholder_data
    retention_period_days: 90  # 90 days post-subscription-end
    retention_trigger: subscription_cancellation_date
    destruction_method: secure_delete_all_copies
    applicable_frameworks: [PCI_DSS, GDPR]

This approach enables version control of retention policies, automated testing of retention logic, and CI/CD integration that validates data handling against defined retention rules.

Third-Party Data Processor Retention

Your data retention policy must extend to your third-party processors. Under GDPR Article 28, your Data Processing Agreements must include data deletion or return obligations. Under PCI DSS, third-party service providers that store cardholder data must comply with your retention requirements.

Maintain an inventory of third-party processors that store your data, the retention obligations in each DPA or service agreement, and evidence that those obligations are fulfilled. Auditors frequently ask for evidence that third-party data deletion is verified, not merely contractually required.

[For guidance on structuring DPAs with retention and deletion clauses, see our Data Processing Agreement Guide.]

Common Data Retention Audit Findings

After working with hundreds of SaaS companies through compliance audits, certain data retention findings appear repeatedly. Knowing what auditors look for -- and what they commonly find -- lets you address gaps before your audit.

Finding 1: No Formal Data Retention Policy

What auditors say: "The organization has not defined a formal data retention policy that specifies retention periods for different data categories."

Why it matters: This is a fundamental control gap. Without a defined policy, there is no basis for evaluating whether data is retained appropriately. Every framework requires a documented retention policy.

How to fix it: Write the policy. Use the template and framework in this guide. Have it reviewed by legal counsel, approved by management, and published to your policy management system.

Finding 2: Policy Exists but Is Not Enforced

What auditors say: "The organization has a data retention policy, but there is no evidence that retention periods are enforced. Data in [system] exceeds the defined retention period."

Why it matters: This is the most common data retention finding. Organizations write policies but do not implement the automated processes or manual procedures to enforce them. The policy becomes shelfware.

How to fix it: Implement automated retention enforcement. Run a baseline assessment of all data stores to identify data exceeding retention periods. Remediate the backlog and establish ongoing automated deletion processes.

Finding 3: Backup Retention Exceeds Data Retention

What auditors say: "Backup media is retained for [X months/years], which exceeds the defined retention period for data categories stored in those backups."

Why it matters: Backups that contain data past its retention period mean your organization is not compliant with its own policy, regardless of whether production systems are clean.

How to fix it: Align backup rotation with your shortest applicable retention period, implement crypto-shredding for backup archives, or document and mitigate the gap with compensating controls.

Finding 4: No Certificates of Destruction

What auditors say: "The organization cannot provide certificates of destruction or equivalent documentation for data that has been deleted or media that has been decommissioned."

Why it matters: Without destruction evidence, auditors cannot verify that your retention policy is enforced. The policy may be followed perfectly, but without documentation, it cannot be demonstrated.

How to fix it: Implement automated deletion logging. For physical media destruction, use a certified destruction vendor that provides certificates. Maintain destruction records for your compliance documentation retention period.

Finding 5: Inconsistent Retention Across Data Stores

What auditors say: "Data retention periods are enforced in the primary database but not in [log management system / analytics platform / data warehouse / CRM]."

Why it matters: Personal data often replicates across multiple systems through integrations, ETL pipelines, and manual exports. Deleting data from one system while it persists in others means the retention period is not truly enforced.

How to fix it: Your data inventory must identify every system where each data category resides. Retention enforcement must cover all systems, not just the primary data store. This is where automation is essential -- manual processes cannot reliably track data across a dozen interconnected systems.

Finding 6: No Data Subject Erasure Process

What auditors say: "The organization does not have a documented process for handling data subject erasure requests under GDPR Article 17."

Why it matters: The right to erasure is a core GDPR requirement. Without a documented and tested process, your organization cannot fulfill its legal obligations within the mandated timeline.

How to fix it: Build the erasure request workflow described in the Right to Erasure section above. Test it with simulated requests before you receive a real one. Document the process and train the team members responsible for handling requests.

Frequently Asked Questions

How often should a data retention policy be reviewed?

Review your data retention policy at least annually, and additionally whenever your organization enters a new regulatory regime (e.g., starting to process health data, entering the EU market), adopts a new compliance framework, or makes significant changes to data processing activities. SOC 2 auditors specifically check that policies are reviewed and updated on a defined schedule. Document every review, including reviews that result in no changes.

What is the difference between a data retention policy and a data retention schedule?

The data retention policy is the governance document that defines your organization's principles, roles and responsibilities, and high-level approach to data retention. The data retention schedule is the detailed operational document that lists specific data categories, retention periods, legal bases, destruction methods, and responsible teams. Most organizations need both: the policy provides the framework, and the schedule provides the actionable details. Auditors typically request the schedule first because it contains the specific, testable controls.

Can we retain data longer than our policy states if a customer requests it?

Possibly, but with significant caveats. Under GDPR, you need a valid legal basis for any processing, including storage. A customer's contractual request to retain data beyond your standard period can constitute a legal basis (contract performance under Article 6(1)(b)), but only if the retention serves a legitimate purpose under the contract. You should define this scenario in your data retention policy, specify the maximum extension permitted, require written customer authorization, and ensure the extended period does not conflict with other regulatory obligations. Document the exception and review it periodically.

How do we handle data retention for former employees?

Former employee data retention is governed by employment law (which varies by jurisdiction), tax law, and your applicable compliance frameworks. In most US jurisdictions, retain payroll and tax records for at least 7 years (IRS requirement). EEOC regulations require retention of employment records for 1 year after termination, and ADEA records for 3 years. Under GDPR, retain only what is legally required and delete everything else. Build a specific off-boarding data retention checklist that identifies every system containing employee data and applies the appropriate retention period to each.

Is anonymized data subject to retention periods?

Truly anonymized data is not personal data under GDPR and therefore is not subject to GDPR retention requirements. However, the threshold for "true" anonymization is high. Pseudonymized data (data where identifiers have been replaced with tokens or codes, but re-identification is possible with additional information) is still personal data and remains subject to retention obligations. The Article 29 Working Party's Opinion 05/2014 on anonymization techniques provides guidance on what constitutes adequate anonymization. If your anonymization can be reversed, it is pseudonymization, and your retention policy applies.

What happens if we receive a litigation hold during a retention period?

A litigation hold (also called a legal hold) overrides your standard retention schedule. When your organization reasonably anticipates litigation, it has a legal obligation to preserve all data potentially relevant to the matter -- even if that data would otherwise be scheduled for deletion. Implement a legal hold process that suspends automated retention enforcement for specified data categories, notifies relevant data custodians, and documents the scope and duration of the hold. Failing to preserve data subject to a litigation hold can result in sanctions, adverse inference instructions, and other legal consequences that far exceed the cost of temporary over-retention.

Do data retention requirements apply to test and development environments?

Yes. If test or development environments contain real personal data (which is common when production data is used for testing), those environments are subject to the same retention and protection requirements as production. The better practice is to use synthetic or anonymized data in non-production environments, which eliminates the retention compliance obligation and reduces your overall data protection risk. SOC 2 auditors increasingly ask about data in non-production environments, and using production data in test environments is a common finding.

How do we handle data retention across multiple jurisdictions?

When your data is subject to retention requirements from multiple jurisdictions, apply the most restrictive combination of requirements. For minimum retention periods, use the longest applicable minimum. For maximum retention periods, use the shortest applicable maximum. When a direct conflict exists (one jurisdiction requires retention while another requires deletion during the same period), consult legal counsel -- this is a legal question, not a technical one. Document your rationale for the retention period chosen and the regulatory analysis supporting it. Multi-jurisdictional data retention is one of the strongest arguments for implementing retention automation, because manual processes cannot reliably track dozens of overlapping jurisdictional requirements.

Build a Data Retention Program That Passes Every Audit

A data retention policy is one of those compliance requirements that sounds simple and turns out to be operationally demanding. The policy document itself can be written in a day. Building the data inventory, implementing automated retention enforcement, aligning backup processes, extending retention controls to third-party processors, and maintaining destruction evidence across every data store in your organization -- that is the real work.

QuickTrust helps SaaS companies build data retention programs that satisfy multiple compliance frameworks simultaneously:

Data inventory and classification: Automated discovery and mapping of data across your infrastructure, classified by sensitivity, regulatory regime, and retention requirements
Retention policy development: Attorney-reviewed data retention policies and schedules tailored to your specific frameworks -- GDPR, SOC 2, HIPAA, PCI DSS, and SOX -- with documented legal justification for every retention period
Automated retention enforcement: Integration with your databases, log management systems, and cloud infrastructure to enforce retention periods automatically, with auditable deletion logs and certificates of destruction
Erasure request management: Workflows for receiving, evaluating, executing, and documenting GDPR Article 17 erasure requests within mandated timelines
Multi-framework compliance mapping: Data retention controls implemented once and mapped to every applicable framework, eliminating duplicate effort and ensuring consistency across audits
Continuous monitoring: Ongoing validation that retention policies are enforced across all systems, with automated alerts for exceptions, failures, and policy drift

The companies that pass data retention audits without findings are not the ones with the longest policies. They are the ones with the shortest gap between what the policy says and what the systems do. That gap is what QuickTrust closes.

Start your compliance assessment at trust.quickintell.com

Related reading:

Open-source platform: github.com/rahuliitk/quicktrust