Salesforce can support CCPA, CPRA, other US state privacy laws and GDPR, but no setting makes an org compliant by itself. The work is design. Map which fields hold personal data, record consent in the platform’s consent objects, and build repeatable request workflows. Then close the gaps in backups, integrations and AI features. It is not legal advice, so confirm every obligation with your privacy counsel.
What do privacy laws actually ask of a Salesforce org?
They ask you to know what personal data you hold, use it only as people agreed, and act on their requests on time. Salesforce supplies the tools, while your team owns the decisions.
The state laws differ in detail, yet most share a core set of consumer rights. California’s law, as amended by the CPRA, covers the right to know, delete, correct and opt out of sale or sharing. GDPR adds a lawful basis for every processing activity and a right to data portability. For a CRM, those rights become five practical questions:
- Where does personal data about one person live across objects, files and connected systems?
- What did that person agree to, through which channel, and for which purpose?
- Can we find, export, fix or erase their data on request, and prove we did?
- How long do we keep each category of record, and what removes it afterwards?
- Who inside and outside the company can read it, including vendors and AI features?
Deadlines are short: generally 45 days under the CCPA and one month under GDPR, with limited extensions. Counsel should confirm what applies.
How do you find and classify personal data in Salesforce?
Start with a field inventory, then tag each field using the classification metadata Salesforce already provides. Without that map, every later step is guesswork.
Every field can carry four classification attributes: Data Owner, Field Usage, Data Sensitivity Level and Compliance Categorization. Default compliance values include CCPA, GDPR, HIPAA, PCI and PII. These labels are metadata only and never inspect the values stored in records.
Personal data also hides in case descriptions, call notes, email bodies and attachments, so sample real records rather than reading field names alone. Shield’s Data Detect scans field contents for sensitive patterns; our Shield buyer’s guide explains when that paid scanning is worth adding.
Where should consent and preferences live?
Use Salesforce’s consent data model instead of a scatter of checkboxes. It records consent at several levels, so one person’s choices follow them across Leads, Contacts and Person Accounts.
The model has four layers. The Individual object holds global, person-level preferences and links to each Lead, Contact or Person Account representing that person. Contact Point Type Consent records consent by channel, such as email or phone. Contact Point Consent records it for one specific address or number. Data Use Purpose names the reason for contact, such as marketing or service notices. The Individual object only appears on records after an admin turns on the data protection setting in Setup.
Record every consent change with its source, date and capture method. Make marketing automation read these objects, not a separate opt-out field that drifts out of sync. If Marketing Cloud or another email tool sends the messages, decide which system owns each channel’s opt-outs before launch.
How should access, deletion and correction requests run?
Treat each request as a tracked case with identity checks, a search across every system, an action and a closed record of what you did. Ad hoc handling is where deadlines slip.
A workable pattern is a dedicated case record type or custom object for privacy requests. It captures requester, request type, verification status, due date, systems searched and outcome. Routing sends it to a trained queue, and milestones warn when the statutory clock is running low.
- Access: export the person’s records across standard objects, custom objects, files and activities, in a format they can read.
- Correction: fix the field in Salesforce, then push the change to every integrated system that copied it.
- Deletion: decide record by record whether to delete, anonymize or keep under a legal exception, such as tax or contract records.
- Opt-out of sale or sharing: update consent records and stop the integrations or audiences that pass data to third parties.
What happens to related records when you delete a person?
Less than most teams expect, so the deletion workflow must name each object explicitly.
Master-detail children are deleted with their parent. Standard lookups usually keep the child record and simply clear the reference, unless the relationship is configured otherwise. Activities, emails, files, case comments, field history, campaign membership and custom objects related through lookups each need a deliberate rule. Deleted records then sit in the Recycle Bin for 15 days before they are purged, unless you empty it sooner.
For transactional history, anonymizing is often better: overwriting names and contact details keeps revenue reporting intact. Test it in a sandbox on a record with deep history first.
Do backups and integrations count?
Yes. A deleted person restored from an old backup, or still sitting in a data warehouse, is still a privacy failure.
Salesforce sells Backup & Recover, and several third-party backup products exist. Whichever you use, check how it handles erasure requests. Some tools can purge or anonymize a person inside existing backups; others need a suppression list so that restores skip deleted individuals.
Integrations copy personal data constantly into marketing platforms, ERPs, enrichment services and warehouses. Each belongs in your inventory, and each deletion request should trigger work or a ticket in every one.
How should retention rules be set?
Define a retention period per record category, tie it to a business or legal reason, and automate removal. Keeping everything forever is the most common privacy exposure in mature orgs.
Typical categories include unconverted leads, closed cases and former customers. For each, record the trigger event, the period counsel approves and the action at expiry: delete, anonymize or archive. Scheduled Flows or batch Apex can enforce simple rules. Larger volumes may need an archiving tool or Privacy Center, described below.
Which security controls protect personal data in Salesforce?
Access controls do most of the work. Get field-level security and sharing right first, then decide whether encryption is required.
Data minimization starts with visibility. Restrict sensitive fields with field-level security through permission sets, and set organization-wide defaults to Private where people should only see their own records. For a multi-agent insurance agency, we set org-wide defaults to Private on Sales Cloud so agents could not view each other’s clients. Our security review checklist covers the full access audit, so we will not repeat it here.
For encryption, Classic Encryption is included and protects short custom text fields. Shield Platform Encryption is a paid add-on that encrypts many standard and custom fields, files and attachments at rest. Licensing and packaging change, so confirm current terms with your Salesforce account team. Remember that encryption does not hide data from users who already have field access.
Can Salesforce keep data in a specific region?
Often, through Hyperforce, but availability depends on the product and region. Confirm residency commitments in writing before relying on them.
Hyperforce runs Salesforce on public cloud regions, so many customers can choose where their org is hosted. For EU data, Salesforce offers the Hyperforce EU Operating Zone. It keeps customer data and processing within the EU and uses EU-based support staff, but only for a defined set of products and features. Ask your account team which licensed products, add-ons and AI services fall inside the boundary you need.
What changes when you turn on AI features?
AI features read the same personal data your users can, so privacy design must cover prompts, outputs and logs. The Einstein Trust Layer helps, but it does not replace your own controls.
Salesforce says the Trust Layer limits grounding to data the user can see. It also masks some data, and outside model vendors may not keep prompts. Add each AI use case to your processing inventory. Check whether generated content stores personal data, and update privacy notices if AI changes how you use it. Our AI security guide covers agent permissions and prompt injection in depth.
Is Salesforce Privacy Center worth evaluating?
If you handle frequent requests or large retention volumes, yes. It automates work that otherwise needs custom Flows and manual exports.
Privacy Center is a paid add-on. Salesforce lists access requests, Right to Be Forgotten, retention policies, de-identification and consent management, with ties to Data 360. Right to Be Forgotten requests run in a daily queue and are reprocessed at 30, 60 and 90 days to confirm deletion. An older, Heroku-based version is now called Legacy Privacy Center, and Salesforce encourages customers on it to move to the platform-native version. Confirm current features, pricing and fit with your account team.
What should you ask Salesforce and other vendors?
Ask for the data processing terms, the sub-processor list and the hosting locations for each product you license. Then repeat the exercise for every AgentExchange (formerly AppExchange) package and integration vendor.
Salesforce publishes its Data Processing Addendum and its infrastructure and sub-processor documentation on its trust and compliance site. Under the DPA, customers can object to a new sub-processor within a set notice period. Managed packages are separate vendors, so check whether each stores data off-platform and how it honors deletion.
| Requirement | Salesforce feature or approach | Watch for |
|---|---|---|
| Know what personal data you hold | Data classification metadata on fields; Shield Data Detect for content scanning | Labels describe intent, not the values actually stored |
| Record consent and opt-outs | Individual, Contact Point Type Consent, Contact Point Consent, Data Use Purpose | Old checkbox fields that disagree with consent records |
| Answer access requests | Privacy request case or object; Privacy Center DSAR policies | Files, activities and integrated systems left out of exports |
| Erase or anonymize data | Deletion or anonymization routine; Privacy Center Right to Be Forgotten | Lookup children, backups and copies in other systems |
| Correct inaccurate data | Tracked request with sync to connected systems | Integrations that overwrite the fix overnight |
| Limit retention | Scheduled Flows, batch jobs, archiving or Privacy Center retention policies | No agreed period, so nothing ever expires |
| Restrict access | Field-level security, permission sets, Private org-wide defaults | Broad admin-style permissions granted years ago |
| Protect data at rest | Classic Encryption; Shield Platform Encryption as an add-on | Encryption mistaken for a visibility control |
| Keep data in region | Hyperforce region choice; EU Operating Zone for eligible products | Add-ons and AI services outside the boundary |
| Oversee vendors | Salesforce DPA and sub-processor list; package vendor reviews | AgentExchange apps storing data off-platform |
Which privacy design mistakes show up most?
The same gaps recur, and each is fixable once someone owns it.
- Treating a privacy request as a single Contact deletion, while activities, files and custom records survive.
- Restoring a backup without re-applying earlier erasure requests.
- Storing consent in a marketing tool only, so Salesforce users call people who opted out.
- Relying on field labels for classification while sensitive details sit in notes and descriptions.
- Launching AI features before updating the processing inventory and privacy notices.
- Buying encryption to solve an access problem that sharing rules should fix.
