Most Salesforce orgs grow their data indefinitely. Records created ten years ago sit alongside records created yesterday, with no policy governing how long any of them should be kept or what should happen when they are no longer needed. GDPR's storage limitation principle (Article 5(1)(e)) makes this indefinite accumulation a compliance violation: personal data must not be kept for longer than necessary for its original purpose. Building a Salesforce data retention policy that satisfies GDPR while also accommodating legal hold obligations requires more than a document — it requires technical controls that actually enforce the policy without destroying records that must be kept.
The GDPR Storage Limitation Principle
GDPR Article 5(1)(e) requires personal data to 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: if you collected a customer's name and email address to send them a quote in 2019, and they never became a customer, that data cannot sit in your Salesforce org indefinitely. The purpose — quote follow-up — has been exhausted. The data must be deleted or anonymised.
The practical challenge is that "necessary" requires a documented purpose for every category of personal data, and different categories have different necessary periods. Financial transaction data may be necessary for six years under contract law. Active customer contact data may be necessary for the duration of the customer relationship plus a reasonable post-relationship period. Marketing leads who never converted may have a much shorter necessary period — often 12 to 24 months depending on your sales cycle.
The storage limitation principle sits alongside the right to erasure (Article 17) but is conceptually distinct. Erasure is reactive — triggered by an individual request. Storage limitation is proactive — you must delete data even without being asked, when its retention period expires. Most organisations are better at reactive erasure than proactive storage limitation, which is why data retention is often the more significant gap in GDPR compliance.
Building Your Data Retention Schedule
A data retention schedule documents the retention period for each category of personal data, the legal basis for that period, and the action at expiry. For Salesforce, this means mapping your retention schedule to specific Salesforce objects.
| Object | Category | Retention Period | Basis | Expiry Action |
|---|---|---|---|---|
| Contact (active customer) | Customer personal data | Duration of relationship + 2 years | Contract, legitimate interest | Anonymise |
| Lead (unconverted, no activity) | Prospect data | 12–18 months from creation | Legitimate interest (sales) | Delete |
| Case | Service record (may include PII in subject/comments) | 3 years from closure | Legitimate interest, potential legal claims | Anonymise PII fields |
| EmailMessage | Communication record | 2 years | Legitimate interest | Delete body content, retain metadata |
| Financial records (custom objects) | Financial transaction data | 6–7 years | Legal obligation (Companies Act, tax law) | Archive then delete |
The legal basis column is critical — it is what justifies each retention period under GDPR. Without a documented legal basis, a supervisory authority reviewing your retention schedule will ask why you are keeping data for that duration. The most common bases are: legal obligation (a law requires you to keep records for a minimum period), contract (you need the data to fulfil a contractual obligation), and legitimate interest (you have a business reason that outweighs the individual's privacy interest).
Legal Holds: When Retention Periods Must Be Suspended
A legal hold is a directive to preserve specific data beyond its normal retention period because it is relevant to pending or reasonably anticipated litigation, regulatory investigation, or audit. When a legal hold is placed, the automated retention deletion must not touch the affected records.
Implementing legal holds in Salesforce requires a custom field approach. Add a Legal_Hold__c checkbox field to every object covered by your retention policy. Your retention automation — whether an Apex batch job or a Flow — must query this field before processing any record for deletion or anonymisation. Records where Legal_Hold__c = true are excluded from all retention processing until the field is manually cleared by an authorised data protection or legal team member.
Maintaining a legal hold register — a custom object that tracks which records are under hold, when the hold was placed, and by whom — gives you the audit trail needed to demonstrate compliance to a court or regulatory body. Without this, you cannot prove that specific records were preserved rather than accidentally overlooked by your retention automation.
Technical Implementation: Automating Retention Enforcement
A data retention policy without technical enforcement is not a policy — it is a document that will be forgotten. The technical implementation must run automatically, be auditable, and be safe to operate in production without destroying records that should be kept.
The recommended architecture is an Apex batch job that:
- Queries records where the retention date field has passed and
Legal_Hold__c = false - Checks for any related records that might be orphaned by deletion and handles them appropriately
- Anonymises or deletes the identified records based on the policy for that object
- Logs every processed record to a custom Retention_Log__c object with the timestamp, action taken, and operator (the batch job's running user)
- Sends a notification to the data protection team with a summary of what was processed
The retention date field deserves specific attention. Rather than calculating retention expiry on the fly in the batch job (which creates a maintenance risk if the formula changes), populate a Retention_Date__c field on each relevant record at creation time. A formula field on Contact could set this to DATEVALUE(CreatedDate) + 730 for a two-year retention period. This makes the batch query simple and the retention policy transparent — any user can look at a record and see when it is scheduled for retention processing.
PII masking and retention management inside Salesforce
MaskEzee handles field-level masking, right to erasure workflows, and retention-based anonymisation directly inside your Salesforce org — with a full audit trail for GDPR and ISO 27001 compliance evidence.
See MaskEzee →Frequently Asked Questions
Does GDPR require a data retention policy for Salesforce data?
Yes. GDPR Article 5(1)(e) — the storage limitation principle — requires personal data to be kept only for as long as necessary for its original purpose. This requires a documented retention schedule specifying how long each type of Salesforce record is kept, why that period is appropriate, and what happens at the end of the retention period.
What is the difference between data retention and data archiving in Salesforce?
Data retention is the overall policy defining how long records are kept before deletion or anonymisation. Data archiving is the strategy of moving older records out of active storage into a lower-cost archive while retaining them for legal reference. Archiving is a tool within retention management — the retention policy determines when even archived records must be deleted.
What are typical data retention periods for common Salesforce record types?
Common starting points: active customer Contacts — relationship duration plus 2 years; unconverted Leads with no activity — 12–18 months; closed Cases — 3 years; financial records — 6–7 years under UK/EU financial regulations; healthcare data under HIPAA — minimum 6 years. These must be documented with the legal basis for each period.
What is a legal hold and how does it interact with a data retention policy?
A legal hold preserves specific data beyond its normal retention period due to pending litigation or regulatory investigation. It suspends the automated deletion schedule for affected records. Implement using a Legal_Hold__c checkbox field that your retention automation checks before processing any record for deletion or anonymisation.
How do you automate data deletion in Salesforce at the end of the retention period?
Via an Apex batch job that queries records past their retention date with no legal hold, anonymises or deletes them based on per-object policy, and logs every action to an audit object. The batch must handle child record relationships, respect legal holds, and be tested thoroughly in sandbox before enabling in production.