Data Protection and Privacy
Data Protection and Privacy in Salesforce is the umbrella Setup area and configuration toolkit for managing how the org handles personal data subject to privacy regulation (GDPR, CCPA, HIPAA, regional privacy laws).
Definition
Data Protection and Privacy in Salesforce is the umbrella Setup area and configuration toolkit for managing how the org handles personal data subject to privacy regulation (GDPR, CCPA, HIPAA, regional privacy laws). It includes the Data Protection and Privacy settings page, the Individual object (where consent and contactability preferences are stored), the Privacy Center managed app (for handling data subject requests), and the integration with Data Classification and Shield Platform Encryption that together form the org's privacy posture.
Data Protection and Privacy exists because privacy regulation is no longer optional in most jurisdictions. Customers, employees, and partners have legally-defined rights to know what data the org holds about them, to correct it, to delete it, to receive a copy, to revoke consent. Salesforce's Data Protection and Privacy features give admins the platform-level tools to honor those rights without building everything custom. Most regulated and consumer-facing orgs configure these features at go-live or during their next privacy program review; orgs that wait until a regulator asks usually find the gap costly to close.
Why Data Protection and Privacy is the umbrella that regulated orgs configure deliberately
Where Data Protection and Privacy lives in setup
Setup, Data Protection and Privacy. The settings page enables platform-wide privacy features: Make Data Protection Details Available in Records (exposes the Individual object lookup on Lead and Contact), Track Individuals on Opt-In and Opt-Out (writes Individual records when consent changes). Adjacent surfaces include the Individual object configuration in Object Manager, Privacy Center for DSR (Data Subject Request) workflows, and the broader integration with Shield, Data Classification, and Compliance BCC Email.
The Individual object and the consent record
The Individual object is Salesforce's privacy-data-store. Each Individual record holds the personal data the org has decided needs separate privacy management: consent flags (HasOptedOutOfEmail, HasOptedOutOfTracking), regulatory preferences (CanStoreSensitivePersonalData, ShouldForgetData), contactability windows, and links to Lead, Contact, and User records that reference the Individual. The Individual is the durable identity for privacy purposes; Lead and Contact reference it through a lookup. Most regulated orgs enable the Individual object early so the consent and preference data is captured per record.
Data Subject Requests and the right-to-be-forgotten workflow
Privacy regulations grant individuals rights to access, correct, port, and delete their data. The Privacy Center managed app (or custom-built workflows) implements the request intake, validation, processing, and response cycle. For right-to-be-forgotten requests, the platform supports deleting or anonymizing the requesting individual's records across multiple objects through scripted workflows. The full DSR cycle is operationally heavy; orgs subject to GDPR or CCPA typically formalize it as a privacy operations program rather than ad-hoc handling.
Integration with Data Classification and Shield
Privacy posture is layered. Data Classification tags fields with sensitivity and compliance categorization (PII, PHI, GDPR). Shield Platform Encryption encrypts the sensitive fields with customer-managed keys. Compliance BCC Email archives outbound emails for retention. Data Protection and Privacy adds the consent management and DSR workflows on top. The layers stack: classify first, encrypt the sensitive fields, archive outbound communications, manage consent and DSRs. Most orgs configure these as a coordinated program rather than feature by feature.
Consent and the marketing send eligibility
Marketing send eligibility depends on consent. A contact who opted out of email cannot legally receive marketing email in most jurisdictions; sending anyway is a regulatory violation. The HasOptedOutOfEmail flag on Contact, Lead, and Individual records is the platform's consent record; marketing tools (Marketing Cloud, Pardot, third-party) respect the flag for send eligibility decisions. Misconfigured consent management produces sends to opted-out recipients and regulatory exposure; the audit pattern is to sample sent campaigns and verify every recipient was eligible at send time.
Retention and the data-lifecycle question
Privacy regulations often impose retention limits (data should not be held longer than necessary for the original purpose). Salesforce does not enforce retention automatically; admins build retention through scheduled deletion (Apex, Flow, or scheduled data jobs that remove records past the retention window). The Retention Policy configuration in Privacy Center provides a structured framework for declaring policies; the execution still requires automation. Most regulated orgs document retention policies and build the automation; orgs without explicit retention violate principles even when no specific request comes in.
Audit, evidence, and the regulator question
Regulators ask: what personal data does the org hold, who can see it, how is it protected, how is consent managed, how are DSRs handled, what is the retention. The Data Protection and Privacy configuration produces the evidence for each question when implemented well: Data Classification answers what data exists, Shield answers how it's protected, Individual records and DSR workflows answer consent and request handling, retention policies answer the data-lifecycle question. The configuration is the compliance program; the documentation is the evidence trail.
How to roll out Data Protection and Privacy as a coordinated program
The pattern: assess regulatory scope, classify data, configure platform features (Individual, Privacy Center, Shield, Compliance BCC), build DSR workflows, document retention, audit. The program is heavy; rolling out feature by feature without coordination produces gaps regulators find.
- Assess regulatory scope
GDPR, CCPA, HIPAA, regional. Each has different requirements; the assessment defines what the program must produce.
- Classify personal data through Data Classification
Tag fields with sensitivity and compliance categorization. The inventory drives every subsequent decision.
- Enable Data Protection and Privacy settings
Setup, Data Protection and Privacy. Turn on Make Data Protection Details Available and Track Individuals on Opt-In/Opt-Out. The settings expose Individual on Lead and Contact and capture consent changes.
- Configure the Individual object and link from Lead/Contact
Object Manager, Individual. Set up record types, page layouts, and the lookup from Lead and Contact. The Individual becomes the durable privacy identity.
- Install Privacy Center or build custom DSR workflows
Privacy Center is the managed app for DSR intake and processing. Alternative: custom Flow or Apex workflows for the same purpose.
- Configure Shield Platform Encryption for high-sensitivity fields
Sensitive PII, PHI, financial data classified as Confidential or Restricted. Shield is the encryption layer for the data Privacy needs to protect.
- Configure Compliance BCC Email for outbound archive
Regulated outbound communications need archival for retention and supervisory review.
- Document the program and audit quarterly
Policies, configurations, evidence trail. The documentation is what regulators ask for; the quarterly audit catches drift.
GDPR, CCPA, HIPAA, regional. Drives requirements.
How the durable privacy identity is structured and linked from Lead/Contact.
Privacy Center managed app or custom-built. Drives operational handling of requests.
Which sensitive fields are Shield-encrypted. Aligned with Data Classification.
Scheduled deletion logic for data past the retention window. Required for regulatory compliance.
- Data Protection and Privacy is a program, not a feature. Rolling out feature-by-feature without coordination produces gaps regulators find.
- Consent flags do not automatically gate marketing sends. Marketing tool integration with consent is the enforcement; misconfiguration produces sends to opted-out recipients.
- Retention is not automatic. Admins must build the automation; the platform provides the policy framework but not the execution.
- DSR handling is operationally heavy. Privacy Center or custom workflows are needed; ad-hoc handling does not scale past a few requests per quarter.
- Regulators ask for evidence, not just configuration. Document the program as you build it; building documentation after the fact is much harder.
Trust & references
Cross-checked against the following references.
- Privacy referenceSalesforce
- Salesforce ShieldSalesforce
Straight from the source - Salesforce's reference material on Data Protection and Privacy.
- Data Protection and PrivacySalesforce Help
- Individual ObjectSalesforce Help
- Privacy CenterSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Data Protection and Privacy important for Salesforce admins?
Q2. Can a Salesforce admin configure Data Protection and Privacy without writing code?
Q3. In which area of Salesforce would you typically find Data Protection and Privacy?
Discussion
Loading discussion…