Salesforce Data Protection: GDPR in Salesforce, Salesforce Data Retention, and Deleting Personal Data on Request
A Contact record is where a person's data starts in Salesforce, not where it ends. Activities, case threads, attachments, Chatter, custom objects and field history each hold a piece of the same person, and the Recycle Bin still holds the ones you deleted. A request gives you one month to find all of it.
found
scanned
Assembling the cover letter from the template...
Helps you comply, not legal advice
In short
Salesforce data protection is what the GDPR and the US state privacy laws require of the personal data sitting in your Salesforce org: a lawful reason to hold it, a retention limit, security around it, and the ability to find, export or delete one named person's records when they ask. In that relationship you are the controller and Salesforce is the processor, so the duty to answer a request is yours. Salesforce provides the infrastructure and, through a paid add-on, some of the automation. Deciding what is in scope and what gets disclosed stays with your team.
The practical problem is that a person is never in one place in a Salesforce org. The Contact record is the part everyone finds. What gets missed is the trail around it: logged calls and emails on Activities, the email messages hanging off a Case, comments a rep typed into a case thread, attachments and files, Chatter posts that name the person, custom objects built for a workflow three years ago, and the field history that still records what their address used to be. A search that stops at Contact, Lead and Account returns a confident and incomplete answer.
Two Salesforce behaviors surprise teams on their first erasure request. Deleting a record does not remove it. It goes to the Recycle Bin, where Salesforce holds it for 15 days by default, and Salesforce Support can enable extended retention that raises that to 30 days. Until the bin is emptied the record is restorable and still present, so a deletion is not finished at the moment somebody clicks delete. Separately, field history is retained for 18 months in the org and 24 months through the API, which means the previous value of a field can outlive the record it belonged to.
Salesforce sells Privacy Center as a paid add-on to automate part of this. It supports retention policies that archive or de-identify personal data, right to be forgotten policies that delete records on request, and portability policies that compile and deliver personal data in response to a data subject access request. It is a capable tool and it has one boundary worth naming plainly: it works on Salesforce. Marketing Cloud, Account Engagement and Data Cloud carry their own data models, and every copy of the record that already left through an integration, into a warehouse, a support desk, a billing system or a spreadsheet somebody exported, sits outside it.
Obtainer covers the part that spans systems. It intakes the request, verifies the requester, searches your connected systems for the person, reports the source system behind every record it surfaces, compiles one reviewable manifest, and tracks the GDPR one-month and CCPA 45-day clocks. Nothing is disclosed or deleted automatically. A human reviews, redacts and approves before anything leaves. Obtainer helps you comply. It is not legal advice, so scope calls, exemptions and any decision to refuse stay with your team. Self-serve from a planned $49/mo.
Last updated August 2026
Why it fits
Privacy, legal and revenue ops teams at US companies running customer data in Salesforce.
The Contact record is the easy part of the answer
Searching Contact, Lead and Account finds the person and misses most of what you hold about them. The detail tends to live in the objects that reference the record rather than in the record itself: Activities carrying logged calls and the text of sent emails, case threads with the person's own words and internal notes about them, quotes and orders, and files attached along the way. Under both the GDPR and the CCPA the scope is the personal data, not the primary record, so a discovery pass has to follow the references outward instead of stopping at the first match.
Deleted is not deleted for another 15 days
A delete in Salesforce is a soft delete. The record moves to the Recycle Bin and stays there 15 days by default, or 30 if Salesforce Support has enabled extended retention, and it can be restored the whole time. Recycle Bin capacity is tied to your org storage rather than to a fixed record count. If you are answering a right to erasure request, the work is not done until the record is hard deleted, and it is worth writing down when the bin was emptied, because that timestamp is the evidence the deletion actually completed.
Field history can outlive the field
Salesforce retains field history for 18 months in the org and 24 months through the API, and Field Audit Trail, a paid add-on, extends retention well beyond that. History rows hold prior values, so a former address, a former phone number or a corrected name can persist after the current value has been changed or removed. That is still personal data. It matters most on a rectification or erasure request, where the point of the request is that the old value should no longer be associated with the person.
Privacy Center stops at the edge of Salesforce
Privacy Center is a paid add-on that automates retention, right to be forgotten and portability policies inside Salesforce, and it does that job. What it cannot see is everything downstream. Most orgs sync contacts into a marketing tool, a support desk, a billing system and a warehouse, and each of those is a separate copy that does not update when the Salesforce row is deleted. The copies are the ordinary cause of an incomplete response, because nobody who ran the deletion was wrong, they were just working inside one system.
Redaction is required before anything ships
A case thread is rarely about one person. It names the agent who handled it, sometimes a colleague, occasionally another customer, and it carries internal commentary written on the assumption nobody outside would read it. Producing it raw is its own problem, which is why redacting third-party data before disclosure is part of the job rather than an optional polish step. Obtainer puts a human review and approval gate in front of every disclosure so that call is made deliberately.
Reference
Where a person's data actually sits in a Salesforce org
Each row is a place personal data accumulates in an ordinary Salesforce deployment. The right-hand column is what an access or deletion request requires there, which is consistently more than deleting the Contact.
| Where it sits in Salesforce | What it holds about a person | What a request requires |
|---|---|---|
| Contact, Lead, Person Account | Name, email, phone, address and every custom field the org has added to the object over the years | The obvious record, in scope for access and deletion, and usually the only place a manual search reaches |
| Activities: Tasks, Events, Activity History | Logged calls and meetings, plus the body of emails sent to or about the person | In scope. Frequently holds more narrative detail about the person than the Contact record does |
| Cases, case comments, email messages | Support history in the person's own words, and internal comments staff wrote about them | In scope for access, internal comments included, unless a specific exemption applies. Third-party names here need redaction before disclosure |
| Custom objects | Whatever this org was extended to track: subscriptions, applications, claims, eligibility, entitlements | In scope, and the most commonly missed category, because nothing about a standard search knows these objects exist |
| Files, attachments, documents | Contracts, identity documents, forms and screenshots holding personal data inside the file rather than in a field | In scope. File contents are not reachable by a field query, so these are found by association with a record instead of by searching for the person |
| Chatter posts and comments | Employees discussing the person by name in free text, often years after the fact | In scope for access. Overlooked routinely because it does not feel like a record |
| Field history and Field Audit Trail | Previous values of tracked fields, retained 18 months in the org and 24 months through the API | Still personal data, and it can outlive the value it replaced, so erasure and rectification both have to account for it |
| Recycle Bin | Records already deleted, held 15 days by default and up to 30 where Salesforce Support has enabled extended retention | Not yet erased. A deletion request is not complete while a restorable copy remains, so record when the bin was emptied |
More use cases
Related features
Questions
Common questions about this
Is Salesforce GDPR compliant?
Salesforce provides GDPR-capable infrastructure and signs a data processing agreement as your processor, but that does not make your org compliant. Compliance depends on what you collect into it, how long you keep it, who you share it with, and whether you can answer an access or deletion request on time, which is the operational half of GDPR compliance. Those are your decisions as the controller. The platform can be compliant while your configuration of it is not.
How do I delete personal data in Salesforce?
Find every record first, then delete, then hard delete. Deleting a Contact moves it to the Recycle Bin rather than erasing it, and it leaves related Activities, cases, files, Chatter posts and custom object rows behind. A complete erasure means identifying the related records, deciding which have a lawful reason to stay, deleting the rest, emptying the Recycle Bin, and accounting for field history. The scope of the underlying right to erasure is what decides which of those records can be kept. Privacy Center can automate parts of this inside Salesforce. Deletion request handling across every other system is a separate problem.
How long does Salesforce keep deleted data?
Fifteen days in the Recycle Bin by default. Salesforce Support can enable extended retention that raises the window to 30 days, and Recycle Bin capacity is tied to your org storage rather than a fixed number of records. During that window the record is restorable and still present in your org, so a deletion request is not satisfied until the bin is emptied. Field history is separate and is retained for 18 months in the org and 24 months through the API.
What is Salesforce Privacy Center?
Privacy Center is a paid Salesforce add-on for handling privacy obligations inside Salesforce. It supports retention policies that archive or de-identify personal data, right to be forgotten policies that delete records on request, and portability policies that compile and deliver a person's personal data in response to a data subject access request. It works across Salesforce clouds. It does not reach the copies of the record that have already synced into systems outside Salesforce.
How do I respond to a data subject access request in Salesforce?
Verify the requester before you gather anything, then scope the search beyond the Contact record to Activities, cases, files, Chatter, custom objects and field history, compile what you find with the source of each record noted, redact third-party and exempt material, and send inside the deadline. The GDPR gives you one month and the CCPA gives 45 days. Salesforce is usually one of several systems in scope, which is why the DSAR process is run against the org as a whole rather than per tool.
Does deleting a Contact in Salesforce delete everything about that person?
No. Deleting a Contact removes that record to the Recycle Bin and leaves the surrounding data in place: Activities logged against them, cases they opened, attachments, Chatter posts naming them, rows in custom objects, and field history. It also does nothing to copies that already synced into a marketing platform, a support desk, a warehouse or a billing system. Treating one delete as a completed erasure is the usual way an incomplete response happens.
Run a data subject access request end to end
Obtainer finds where a person's data lives across your systems, compiles it into one manifest, drafts the deadline-safe response, and tracks the GDPR and CCPA clock. You review, redact, and approve what gets disclosed. Helps you comply; not legal advice.