Why data retention matters
GDPR Article 5(1)(e) — the storage limitation principle — 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." Translation: you can't keep user data forever just because you might find it useful someday.
This is one of the most commonly violated GDPR principles. Most SaaS companies never delete anything. That's a problem — not just legally, but operationally. Data you don't need is data you have to protect, breach-disclose, and explain to auditors.
What is a data retention policy?
A data retention policy is an internal document (and external disclosure) that specifies:
- What categories of personal data you collect
- How long you retain each category
- The legal basis and business justification for that retention period
- What happens when the period ends (deletion, anonymization, archival)
- Who is responsible for enforcing retention and deletion
Your privacy policy must mention retention periods (even at a high level) to comply with GDPR Articles 13 and 14. Your data retention policy is the internal document that backs up those statements.
GDPR retention rules: what the law actually says
GDPR does not set fixed retention periods for most data types. Instead, it requires that retention periods be justified by one of these factors:
- Contractual necessity: you need the data while a contract is active + a reasonable period to handle disputes.
- Legal obligation: EU or member state law requires you to keep certain records (e.g., tax records for 7 years in most EU jurisdictions).
- Legitimate interest: fraud prevention, security incident investigation — must be proportionate.
- Consent: where consent is the lawful basis, you retain data until consent is withdrawn.
The key question: what is the minimum period necessary, and can you justify it?
Recommended retention periods by data type (SaaS)
| Data Type | Recommended Period | Justification |
|---|---|---|
| Active user account data | Duration of account + 30 days post-deletion request | Contract; user may ask for export during this window |
| Billing and payment records | 7 years | Tax and accounting obligations (EU/EEA) |
| Invoices and receipts | 7 years | VAT and accounting obligations |
| Support tickets / correspondence | 2–3 years after account closure | Legitimate interest (dispute resolution) |
| Security / audit logs | 12 months (minimum for SOC 2); 90 days for most | Legitimate interest (security monitoring) |
| Marketing consent records | 3 years after last interaction | Proof of consent (GDPR Art. 7(1)) |
| Email marketing unsubscribes | Indefinitely (suppression list) | Legal obligation: must not re-contact after opt-out |
| Analytics data (aggregated) | Indefinitely | Anonymized data is not personal data under GDPR |
| Analytics data (user-level) | 26 months (Google's default) | Legitimate interest; must be disclosed |
| Deleted user data | 30–90 days in backups | Technical necessity; must be wiped from backups after this window |
| Job application data | 6 months after rejection | Legitimate interest (re-application); get consent to retain longer |
| KYC/identity verification | 5–10 years | AML/KYC legal obligations (varies by jurisdiction) |
| Health data (HIPAA) | 6 years from creation or last use (medical records: longer by state law) | HIPAA retention requirements |
Note: These are general guidelines. Your specific periods should be reviewed by a lawyer for your jurisdiction and sector.
The backup problem
This catches almost every SaaS company off guard: database backups must also respect retention periods. If a user requests erasure (Article 17) and you delete their record from production, but your daily backups run for 30 days, their data still exists in backups for another 30 days. That is technically permissible if you document it — but you must:
- State in your privacy policy that backups are retained for [X] days after deletion.
- Ensure backup data is not restored to production unless genuinely necessary.
- Purge backups after your stated retention window.
Most SaaS companies handle this by adding a "backup retention" row to their data retention schedule with a 30–90 day period.
How to build your data retention schedule
Your data retention schedule is a table (spreadsheet or internal doc) that maps data categories to periods and deletion methods. Build it in five steps:
- Data inventory. List every category of personal data you process. Use your GDPR Article 30 Records of Processing Activities (RoPA) as the input. If you don't have a RoPA, make one now.
- Assign retention periods. For each category, set a period with a written justification (legal basis, business necessity, or statutory requirement).
- Define the deletion trigger. Retention periods need a start date: account closure, last login, consent withdrawal, end of contract, etc.
- Define the deletion method. Secure deletion (overwrite), anonymization, or archival with access controls. Hard delete is safest from a GDPR perspective.
- Assign an owner. Someone is responsible for reviewing and enforcing the schedule. Build automated deletion jobs where possible; manual processes fail.
Technical implementation for SaaS
Retention policies are meaningless without enforcement. Options:
- Database TTL (Time-to-Live): Native in MongoDB, DynamoDB, Redis. Set an expiry on rows or documents. Best for session data, temporary records.
- Scheduled deletion jobs: A cron job that runs nightly/weekly, selects records past their retention date, and deletes or anonymizes them. Log every deletion run.
- Anonymization instead of deletion: Replace identifying fields with nulls or hashes. The resulting record is no longer personal data. Useful when you want to retain analytics/aggregate data.
- Soft-delete with hard-delete lag: Mark records as deleted immediately (for user-facing purposes), then actually wipe them after a 30-day grace period. Gives you a recovery window while respecting erasure requests.
- Audit log: Log every deletion event (record type, timestamp, count) to a retention-compliant audit trail.
What goes in your privacy policy vs. your internal retention policy
Under GDPR Articles 13 and 14, your privacy policy must disclose retention periods (or the criteria used to determine them) to data subjects. You don't need to publish your full internal retention schedule publicly — but you must give users enough information to understand how long their data is kept.
Typical privacy policy language: "We retain your account data for the duration of your account and for 30 days following account deletion. Billing records are retained for 7 years as required by Estonian and EU tax law. You can request erasure at any time at privacy@yourcompany.com."
👉 Generate your Privacy Policy free — includes data retention disclosures, erasure rights, and jurisdiction-specific clauses for GDPR, CCPA, and more.
Data retention checklist
- ✅ Data inventory / RoPA completed listing all personal data categories
- ✅ Retention periods defined for each category with written justification
- ✅ Retention periods disclosed in privacy policy
- ✅ Automated deletion jobs or TTL configured for each data store
- ✅ Backup retention window documented and enforced
- ✅ Subject Access Request (SAR) process includes checking all data stores
- ✅ Erasure requests result in deletion from production AND backups (within stated window)
- ✅ Deletion audit log maintained
- ✅ Retention schedule reviewed annually