GDPR Data Retention: Policies, Schedules, and Best Practices

GDPR’s storage limitation principle is deceptively simple: don’t keep personal data longer than you need it. Article 5(1)(e) states that personal data must 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.”

In practice, implementing this principle is one of the most operationally challenging aspects of GDPR compliance. It requires you to define specific retention periods for every category of personal data, justify each period, implement mechanisms to enforce those periods, and document everything. “We keep it until someone tells us to delete it” is not a retention policy.

For SaaS companies, data retention intersects with product design, engineering workflows, legal requirements, and customer expectations. This guide covers how to define retention periods, build a retention schedule, and implement deletion mechanisms that actually work.

Why Data Retention Matters

The Legal Requirement

The storage limitation principle isn’t a suggestion — it’s one of GDPR’s core data processing principles (Article 5). Keeping personal data beyond its justified retention period is unlawful processing, and it can result in enforcement action.

Supervisory authorities have issued fines specifically for excessive data retention. Keeping customer data indefinitely “for potential future use” or retaining employee records long after employment ends without a legal justification are exactly the patterns regulators look for.

The Practical Benefits

Beyond compliance, sound retention practices reduce your risk surface. Data you’ve deleted can’t be breached, can’t be subject to a DSAR, and can’t become a liability. Less data means lower storage costs, faster database queries, and simpler data mapping. Retention discipline is good data hygiene, not just good compliance.

Setting Retention Periods

Step 1: Inventory Your Data Categories

Before setting retention periods, you need to know what data you hold. Work from your ROPA — each processing activity involves specific categories of data that need individual retention periods.

Common data categories for SaaS companies:

• User account data (names, emails, credentials)
• Usage and behavioral data (feature interactions, session logs)
• Customer relationship data (CRM records, communication history)
• Financial data (invoices, payment records, billing history)
• Support data (tickets, chat transcripts, feedback)
• Marketing data (email subscriptions, campaign engagement)
• Employee data (HR records, payroll, performance reviews)
• Website visitor data (analytics, cookie data, form submissions)
• Application logs (server logs, error logs, audit trails)

Step 2: Determine the Justification for Each Period

Every retention period needs a rationale. There are four main sources of justification:

Contractual necessity. Data needed to perform a contract should be retained for the duration of the contract, plus a reasonable wind-down period. Example: user account data retained while the subscription is active, plus 30 days for reactivation or data export.

Legal obligation. Some data must be retained for specific periods by law. These requirements vary by jurisdiction:

• Financial and tax records: typically 6–10 years depending on the country
• Employment records: varies significantly by jurisdiction (2–10 years)
• Anti-money laundering records: 5 years after the end of the business relationship
• VAT records: typically 7–10 years

Legitimate interest. Some data serves a legitimate business purpose beyond the original collection purpose. Example: retaining aggregated usage analytics for product improvement. But the legitimate interest must be balanced against the data subject’s rights, and the retention period must be defined and justified.

Consent. Data processed based on consent should be retained until consent is withdrawn — plus whatever processing is necessary to fulfill the withdrawal (e.g., adding an email to a suppression list to prevent re-enrollment).

Step 3: Apply the Minimization Test

For each data category and retention period, ask: could we achieve the same purpose with less data retained for a shorter time?

• Can usage data be aggregated or anonymized after a shorter period while still serving its purpose?
• Do support ticket attachments need to be retained as long as the ticket metadata?
• Does full log data need to be kept, or would summarized data suffice after an initial period?

The retention period should be the minimum necessary for the stated purpose — not the maximum you can justify.

Retention Schedule Template for SaaS Companies

Here’s a practical template with common retention periods. Adjust based on your specific legal requirements, contracts, and business needs:

User Account Data

• Active accounts: Duration of account plus 30 days after account deletion
• Trial accounts (not converted): 90 days after trial expiration
• Inactive accounts (no login): 24 months of inactivity triggers notification; deletion 30 days after notification if no reactivation

Usage and Behavioral Data

• Detailed event data: 12 months, then aggregated/anonymized
• Session recordings (if used): 90 days
• Feature usage analytics: 24 months, then aggregated

Customer Relationship Data

• Active customer records: Duration of relationship
• Post-termination customer records: 12 months for reference, then anonymized
• Sales prospect data (no contract): 12 months after last meaningful interaction
• Business cards / event contacts: 6 months if no follow-up or consent obtained

Financial Data

• Invoices and billing records: 10 years (tax obligation — check local requirements)
• Payment method details: Handled by payment processor; local references deleted with account
• Refund records: 7 years (financial record-keeping)

Support Data

• Resolved ticket metadata: Duration of customer relationship plus 12 months
• Ticket content and attachments: 24 months after resolution, then anonymized
• Chat transcripts: 12 months, then deleted
• Phone call recordings: 6 months (if used for training/quality), then deleted

Marketing Data

• Email subscribers (active): Until unsubscribe or consent withdrawal
• Email suppression list: Indefinitely (needed to prevent re-enrollment — but only the email address, no other data)
• Campaign performance data: 24 months, then aggregated
• Cookie consent records: 12 months (to demonstrate consent)

Employee Data

• Current employee records: Duration of employment
• Former employee records: 2–7 years after employment ends (varies by jurisdiction and record type)
• Unsuccessful applicant data: 6 months after rejection (or with consent, up to 12 months)
• Payroll and tax records: 7–10 years (legal obligation)

Technical Logs

• Application logs (with personal data): 90 days, then anonymized or deleted
• Security and audit logs: 12 months
• Error logs with stack traces: 30 days
• Access logs: 6 months

Implementing Retention in Practice

Automated Deletion

Manual deletion doesn’t scale. Build automated processes that:

• Flag records approaching their retention deadline
• Execute deletion on schedule (or after a review period)
• Handle cascade deletion (when a user account is deleted, all associated data across systems should follow)
• Log deletion events for accountability

Dealing with Backups

Backups are the awkward exception to clean deletion. When you delete a record from your production database, it still exists in last week’s backup. GDPR acknowledges that immediately purging data from all backups may be technically impractical.

The pragmatic approach:

• Set a backup retention period (e.g., 30–90 days)
• Document the backup retention period in your ROPA and privacy notice
• When data is deleted from production, it will naturally roll out of backups as older backups are replaced
• If someone exercises their right to erasure, document that the data has been deleted from production and will be overwritten in backups within the backup retention cycle
• Ensure backups are not restored in a way that resurrects deleted data

Anonymization as an Alternative to Deletion

GDPR’s retention limits apply to personal data — data that identifies or can identify an individual. If you genuinely anonymize data (not just pseudonymize it), the anonymized data is no longer subject to GDPR, and you can retain it indefinitely for analytics, research, or product improvement.

The key word is “genuinely.” Anonymization must be irreversible — you should not be able to re-identify individuals from the anonymized dataset, even by combining it with other data you hold. Pseudonymization (replacing identifiers with tokens while keeping the mapping) is not anonymization and remains subject to GDPR.

Effective anonymization techniques:

• Aggregation: Combine individual records into statistical summaries
• Generalization: Replace specific values with ranges (age 32 → age group 30–40)
• Suppression: Remove identifying fields entirely
• Noise addition: Add random variations to individual values

Data Subject Requests and Retention

When someone exercises their right to erasure (Article 17), you must generally delete their data regardless of your retention schedule — unless an exception applies (legal obligation, legal claims, public interest, or exercise of freedom of expression).

When someone exercises their right to restriction of processing (Article 18), you must stop processing their data but don’t necessarily need to delete it. The data is “frozen” until the restriction is lifted.

Your retention schedule should document how data subject rights interact with retention periods.

Common Retention Mistakes

No defined periods. “We’ll keep it as long as we need it” is not a policy. Supervisory authorities expect specific periods (or specific criteria) documented for each data category.

Uniform retention periods for everything. Applying the same retention period to all data (e.g., “we delete everything after 5 years”) ignores the principle that different data serves different purposes with different justifications. Financial records may need 10 years; marketing preferences may need 12 months.

Not accounting for all copies. Data doesn’t just live in your primary database. It’s in your CRM, your analytics platform, your email marketing tool, your support system, your backups, and possibly in shared documents or email threads. Retention policies must cover all locations.

No enforcement mechanism. A retention schedule without automated deletion or regular manual review is just a document. Without enforcement, data accumulates indefinitely.

How GRCTrail Manages Retention

GRCTrail integrates retention management into your compliance program:

ROPA with retention periods. Each processing activity in your Record of Processing Activities includes documented retention periods, linked to their justifications. When you review your ROPA, retention periods are part of the assessment.

Retention monitoring. Track whether your defined retention periods are being enforced across your systems. Flag data categories where retention is approaching or exceeding the defined period.

Connected to your privacy notice. Your published privacy notice states your retention periods. GRCTrail ensures consistency between what you tell data subjects and what your systems actually do.

Take control of your data retention →

Related Guides

• GDPR Compliance Checklist — The full compliance framework
• Records of Processing Activities (ROPA) — Documenting your processing
• Privacy Notice Requirements — Communicating retention to data subjects
• The Six Lawful Bases — Legal grounds that inform retention periods

Get started with GRCTrail →