Data Retention Policies and DSARs: How Long You Keep Data Affects How You Respond

The Data You Keep Is the Data You Must Disclose

Every piece of personal data your organization holds is a piece of data that could appear in a DSAR response. Every piece you have properly deleted is one fewer item to locate, review, redact, and disclose. Your data retention policy is not just a storage management decision — it directly determines the scope, complexity, and cost of every data subject access request you receive.

Many businesses treat data retention and DSAR response as separate compliance topics. They are not. They are deeply intertwined. A well-implemented retention policy makes DSARs faster and cheaper to handle. A non-existent or poorly enforced retention policy turns every DSAR into an expensive trawl through years of accumulated data that should have been deleted long ago.

This guide covers the storage limitation principle, how retention intersects with DSAR obligations, what happens when conflicts arise, and how to build a retention schedule that supports compliance across the GDPR, CCPA, PIPEDA, and UK GDPR.

The Storage Limitation Principle

GDPR Article 5(1)(e) establishes the storage limitation principle: 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 plain terms: do not keep personal data longer than you need it. When the purpose is fulfilled, delete it or anonymize it.

This is not a suggestion. It is one of the six core principles of the GDPR, and controllers must be able to demonstrate compliance with it (the accountability principle under Article 5(2)). The UK GDPR contains an identical requirement.

The storage limitation principle requires you to:

1. Define retention periods for each category of personal data you process
2. Justify those periods based on the purposes for processing
3. Enforce deletion or anonymization when retention periods expire
4. Document your approach so you can demonstrate compliance

How Retention Directly Affects DSARs

The relationship between retention and DSARs is straightforward but frequently misunderstood.

If You Have Properly Deleted Data

When a DSAR arrives and the requested data has already been deleted under your retention policy, you do not need to provide it. You cannot provide what you no longer hold. Your response should:

• Acknowledge the request
• Confirm that the data was held previously
• Explain that it was deleted in accordance with your retention policy
• Provide the approximate date of deletion if available
• Disclose any data you still hold (even if some categories have been deleted, others may remain)

This is a compliant response. Proper retention is not a DSAR defense — it is a separate obligation that, when fulfilled, legitimately reduces the scope of your DSAR response.

If You Have Kept Data Longer Than Your Policy Says

Here is where businesses get into trouble. If your retention policy says customer data is deleted after three years, but you have not actually deleted it and five years of data still sits in your CRM, you must disclose all of it in a DSAR response.

You cannot hide behind your own non-compliance. The DSAR obligation requires you to disclose all personal data you hold about the individual at the time of the request. If you hold data that should have been deleted but was not, you must:

1. Disclose it in the DSAR response — you have a legal obligation to provide all personal data you hold
2. Recognize the retention breach — you are separately in violation of the storage limitation principle
3. Take corrective action — delete the overdue data (after fulfilling the DSAR) and fix the process that allowed retention to lapse

This creates a particularly uncomfortable situation: the DSAR exposes your retention non-compliance. The individual now knows you held their data longer than you should have. Supervisory authorities take note of these situations.

If Data Was Deleted After the DSAR Was Received

Once you receive a DSAR, you must not delete any of the requested data until the request has been fulfilled. Deleting data after receiving a DSAR — even if the deletion was already scheduled under your retention policy — could constitute obstruction of the individual's rights.

Best practice: when a DSAR arrives, immediately place a hold on any scheduled deletions for that individual's data until the request is complete.

Retention vs DSAR Conflicts

Several scenarios create tension between retention obligations and DSAR rights. Understanding these conflicts is essential for getting the response right.

Legal Holds and Litigation

When litigation is pending, threatened, or reasonably anticipated, a legal hold overrides your normal retention policy. Data relevant to the litigation must be preserved regardless of whether its retention period has expired.

If a DSAR arrives during a legal hold, you must still disclose the data to the requester (assuming no exemption applies), but you must not delete it even if the individual also requests erasure. The legal hold takes precedence over deletion requests.

Regulatory Retention Requirements

Certain categories of data must be retained for specific periods by law, regardless of your own retention policy:

| Data Category | UK Retention Requirement | US Retention Requirement | |---|---|---| | Tax records / financial accounts | 6 years (HMRC) | 7 years (IRS) | | Employee payroll records | 6 years after employment ends | 4 years (IRS) / varies by state | | Health and safety records | 40 years for certain exposure records (COSHH) | 30 years (OSHA for exposure records) | | Company formation documents | Permanent (Companies Act 2006) | Permanent | | VAT records | 6 years | N/A (sales tax varies by state) | | Insurance records | 6 years after policy expiry | Varies by state (typically 5-7 years) | | Pension records | 6 years after benefit ceases | 6 years after plan termination (ERISA) |

When regulatory requirements mandate retention, you must retain the data but still disclose it in response to a DSAR. Regulatory retention is not an exemption from access rights — it is an exemption from deletion requests.

The "Access Plus Erasure" Scenario

An individual submits a DSAR requesting access to their data and also asking you to delete it. Here is the correct sequence:

1. Process the access request first — compile and provide all personal data
2. Then process the erasure request — delete data where no retention obligation applies
3. Retain data where a legal or regulatory obligation requires it, and explain to the individual what you retained and why

Do not delete first and then tell the individual you have nothing to disclose. For more on handling erasure requests, see our right to erasure guide.

Building a Retention Schedule That Works

A retention schedule is a documented table mapping each category of personal data to a defined retention period and the justification for that period. It is the operational tool that makes the storage limitation principle enforceable.

Step 1: Map Your Data Categories to Purposes

Before setting retention periods, you need to know what data you hold and why. This exercise overlaps with data mapping for DSAR readiness. For each category, document:

• What the data is (e.g., customer contact details, purchase history, employee records)
• The purpose for processing (e.g., contract performance, marketing, legal obligation)
• The legal basis (e.g., consent, legitimate interests, legal obligation)

Step 2: Set Retention Periods

For each data category, determine how long you need to keep it. Base your decisions on three factors:

Legal requirements: Start with any statutory retention periods that apply. Tax records, employment records, financial records, and regulated industry data all have legally mandated minimums. These are non-negotiable.

Business need: For data not subject to statutory requirements, determine how long you genuinely need it for the stated purpose. Customer contact details for ongoing service delivery are needed as long as the customer relationship exists. Marketing consent records should be kept for the duration of the marketing activity plus a reasonable period to evidence past consent. Support ticket data may be needed for a defined period to track patterns and quality.

Industry practice: Where law does not dictate a specific period and business need does not provide a clear answer, look to industry norms. These are not binding, but they provide defensible benchmarks if a supervisory authority questions your choices.

Step 3: Define Common Retention Periods

Here is a starting framework. Adjust based on your jurisdiction, industry, and specific business requirements:

| Data Category | Suggested Retention Period | Justification | |---|---|---| | Customer account data | Duration of relationship + 6 years | Contractual claims limitation period (UK) | | Transaction/purchase records | 7 years from transaction | Tax and accounting requirements | | Employee records | 6 years after employment ends | Employment claims limitation period (UK) | | Recruitment data (unsuccessful candidates) | 6-12 months | Reasonable period for discrimination claims | | Marketing consent records | Until consent withdrawn + 2 years | Evidence of lawful basis for marketing | | Website analytics (with personal data) | 26 months | Google Analytics default; review necessity | | CCTV footage | 30 days (typical) | Security purpose fulfilled quickly | | Support tickets | 2-3 years | Quality monitoring and pattern identification | | Contractual documents | Duration of contract + 6 years | Limitation period for contractual claims | | Health and safety incident records | 3 years minimum (40 years for certain exposures) | Limitation Act 1980 / specific regulations |

These periods are illustrative. Your retention schedule should reflect your specific legal obligations, business needs, and risk profile.

Step 4: Assign Ownership and Enforcement

A retention schedule is only useful if it is enforced. For each data category:

• Assign an owner — someone responsible for ensuring data is deleted when the retention period expires
• Set review dates — calendar reminders to check whether scheduled deletions have been carried out
• Automate where possible — configure systems to automatically delete or flag data when retention periods expire
• Log deletions — record what was deleted and when, so you can evidence compliance in future DSARs or audits

Step 5: Document Exceptions

Your retention schedule should include a section on exceptions — circumstances where normal retention periods may be extended:

• Legal holds: Data subject to actual or anticipated litigation
• Regulatory investigations: Data requested or likely to be requested by a regulatory body
• DSAR in progress: Data that must be preserved until a pending DSAR is fulfilled
• Ongoing disputes: Data relevant to an unresolved complaint or claim

Each exception should have a defined process for activation, review, and release.

CCPA Retention Obligations

The CCPA, as amended by the CPRA, introduced explicit retention disclosure requirements. Under Section 1798.100(a)(3), businesses must disclose in their privacy policy:

• The retention period for each category of personal information collected, or
• The criteria used to determine the retention period if a specific period is not practical

This means California businesses (or businesses serving California consumers) must either set specific retention periods or articulate a clear methodology for determining them. "We keep data for as long as we need it" is not sufficient — you must explain what "need" means in concrete terms.

The CCPA also provides that businesses must not retain personal information for longer than is reasonably necessary for the disclosed purpose. While this mirrors the GDPR's storage limitation principle, the CCPA enforcement framework is newer, and regulatory guidance on specific retention periods is less developed.

CCPA and DSARs

When a California consumer submits an access request, the business must disclose personal information collected over the preceding 12 months (or longer if the business chooses). If data was collected more than 12 months ago and has been retained, the business is not required to provide it in the standard access response but must still comply with any applicable deletion request.

This creates an interesting dynamic: the GDPR requires disclosure of all data held at the time of the request, regardless of when it was collected. The CCPA default is a 12-month lookback. Businesses operating under both regimes should consider applying the broader GDPR standard to all requests for simplicity.

PIPEDA Retention Principles

PIPEDA Principle 5 (Limiting Use, Disclosure, and Retention) states: "Personal information shall not be retained beyond the period required for the fulfilment of those purposes."

PIPEDA goes further than the GDPR in some respects. It requires organizations to:

• Develop guidelines and procedures for retention and destruction of personal information
• Establish minimum and maximum retention periods
• Destroy, erase, or anonymize personal information that is no longer needed

The Office of the Privacy Commissioner of Canada (OPC) has emphasized that organizations should not retain personal information indefinitely "just in case" it might be useful. Retention periods must be linked to specific, identified purposes.

When an individual makes an access request under PIPEDA, the organization must provide all personal information it holds. As with the GDPR, properly deleted data does not need to be provided, but data retained beyond its justifiable purpose must still be disclosed.

How Good Retention Makes DSARs Easier

Organizations with well-enforced retention policies consistently handle DSARs faster, cheaper, and with fewer compliance risks. Here is why:

Less Data to Search

If you delete customer marketing data after consent is withdrawn and a two-year evidential period, you are not searching through a decade of marketing history when a DSAR arrives. The less data you hold, the less you need to find.

Clearer Scope

A retention schedule tells your DSAR team exactly what data categories exist for each type of individual (customer, employee, prospect). When a request arrives, the team knows what to look for and where, rather than guessing.

Faster Responses

Searching through three years of data is faster than searching through ten. Organizations with strict retention practices routinely complete DSARs within two weeks, while those with poor retention habits regularly need the full one-month window and sometimes request extensions.

Reduced Redaction Burden

More data means more potential third-party information that needs redacting before disclosure. Less data means less redaction work.

Lower Risk

If you only hold data you can justify, every piece of data in a DSAR response is defensible. If you hold data you should have deleted, the DSAR response itself becomes evidence of a retention violation.

Practical Tips for Aligning Retention and DSAR Readiness

Review Your Retention Schedule Annually

Business needs change. New systems are adopted. New legal obligations arise. An annual review ensures your retention schedule reflects current reality. Assign this to a specific person with a calendar reminder.

Automate Deletion Where Possible

Manual deletion relies on people remembering to do it. That fails at scale. Most modern CRM, HR, and marketing platforms support automated retention rules. Set them up:

• Configure auto-deletion or auto-archival based on retention periods
• Set up automated notifications when data approaches its retention deadline
• Use system-level policies rather than relying on individual users

Log Deletions

When data is deleted under your retention policy, record:

• What was deleted (data categories, not individual records)
• When it was deleted
• Under which retention policy provision
• Which system it was deleted from

This log serves two purposes: it evidences compliance with the storage limitation principle, and it provides documentation when a DSAR arrives for data that has already been deleted. You can point to the deletion log rather than simply saying "we don't have it."

Do Not Keep Data "Just in Case"

This is the most common retention mistake. Data is kept because someone thinks it might be useful someday, because nobody has bothered to delete it, or because "we might need it if we get sued." None of these are valid retention justifications.

Keeping data "just in case" creates DSAR liability. Every extra record you hold:

• Must be searched in every DSAR
• Must be reviewed for relevance
• Must be redacted if it contains third-party information
• Must be securely compiled and transmitted
• Could expose you to claims if it should have been deleted

The correct approach is to define retention periods based on purpose and legal obligation, enforce them, and delete data when the period expires.

Align Retention and Data Mapping

Your retention schedule and your data map should be companion documents. The data map tells you where personal data lives; the retention schedule tells you how long it should live there. Together, they give your DSAR team everything they need to respond efficiently.

Handle the Backup Problem

Backups create a retention complication. Data may be deleted from live systems but persist in backup archives. The ICO has acknowledged that deleting specific records from backups may not always be technically feasible and has indicated that businesses should:

• Delete data from live systems first
• Note that data may persist in backups
• Ensure that if a backup is restored, previously deleted data is re-deleted promptly
• Not rely on backups as a reason to delay deletion from live systems

Document your backup retention periods separately. A common approach is to retain backups for 30-90 days and then overwrite. Any longer, and you risk retaining personal data beyond its live retention period.

Prepare for the "Why Did You Keep This?" Question

When you disclose data in a DSAR response, the individual may ask why you still hold it — especially if the data relates to a service they stopped using years ago. If you have a clear retention schedule with documented justifications, you can explain: "We retain transaction records for seven years to comply with tax requirements." Without a schedule, you have no good answer, and the individual may escalate to the supervisory authority.

Common Mistakes

No retention schedule at all. Many small businesses have never created a formal retention schedule. They keep data indefinitely by default. This maximizes DSAR scope and creates storage limitation violations.

Retention schedule exists but is not enforced. A document that says "delete after three years" means nothing if nobody checks whether deletion actually happens. Enforcement is the hard part.

Different retention periods in different systems. Customer data deleted from the CRM after two years but retained in the email marketing platform for five years creates inconsistency. Your retention schedule must cover all systems.

Deleting data after receiving a DSAR. Once a DSAR is received, place a hold on deletions for that individual. Deleting data during a pending request can constitute an obstruction of rights.

Confusing retention with archiving. Moving data to an archive does not count as deletion. Archived data is still held and must be disclosed in a DSAR response. Unless the data is truly anonymized (not pseudonymized — genuinely irreversibly anonymized), it counts.

Ignoring paper records. Paper files have retention periods too. If you have filing cabinets of old customer records, they are in scope for both retention and DSAR obligations.

References

• GDPR Article 5(1)(e): Storage limitation principle. GDPR Article 5
• GDPR Article 17: Right to erasure (and its interaction with retention). GDPR Article 17
• ICO: Storage limitation guidance. ICO guidance
• CCPA Section 1798.100(a)(3): Retention period disclosure requirement.
• PIPEDA Principle 5: Limiting use, disclosure, and retention.
• HMRC: Record-keeping guidance for tax purposes. HMRC guidance