Glossary
Salesforce data privacy glossary
12 terms, each defined in a sentence here and in depth on its own page. Written for the people who have to make them true inside a Salesforce org.
- Data AnonymizationData Masking
- Anonymization is the only technique that takes data out of GDPR scope entirely. It is also the hardest to achieve, because relational data re-identifies itself through quasi-identifiers. Most teams who believe they anonymized their data actually pseudonymized it. Read the guide →
- Data Masking in SalesforceSandbox Security
- Data masking replaces real Salesforce PII with realistic substitutes. Learn why Salesforce’s native Data Mask isn’t enough, what field-level masking does, and how to implement it across sandbox environments. Read the guide →
- Data MinimizationData Retention
- Data minimization is a GDPR principle, not a storage optimisation. It requires personal data to be adequate, relevant and limited to what is necessary for the purpose it was collected for. In a CRM that has been running for a decade, almost nothing satisfies that test by default. Read the guide →
- Data Processing Agreement (DPA)Compliance
- A Data Processing Agreement is not optional paperwork. GDPR Article 28(3) requires a written contract whenever a processor handles personal data on your behalf, and it specifies eight things that contract must cover. Most DPA reviews check that one exists and skip what it says. Read the guide →
- DPIA (Data Protection Impact Assessment)Compliance
- A Data Protection Impact Assessment is a documented risk assessment carried out before high-risk processing begins. GDPR Article 35 makes it mandatory in defined cases, and several of those cases are triggered by things Salesforce teams do routinely, including deploying AI features over customer data. Read the guide →
- DSAR (Data Subject Access Request)Privacy Rights
- What DSARs are, which regulations require them, response timelines, what they require in Salesforce, and how to automate end-to-end DSAR handling. Read the guide →
- Lawful Basis for ProcessingConsent
- Every act of processing personal data needs one of the six lawful bases in GDPR Article 6. Consent is the best known and frequently the weakest choice, because it can be withdrawn at any time and the processing must then stop. Choosing the basis is a decision you make once, document, and cannot quietly change later. Read the guide →
- PseudonymizationData Masking
- Pseudonymization replaces identifying values with substitutes while keeping re-identification possible using information held separately. That last part is why pseudonymized data stays in scope for GDPR, and why teams who think they have anonymized their sandbox usually have not. Read the guide →
- Record of Processing Activities (RoPA)Compliance
- The Record of Processing Activities is the document a regulator asks for first. Article 30 sets out exactly what it must contain. The under-250-employee exemption sounds broad and turns out to cover almost nobody, because it excludes any processing that is regular rather than occasional. Read the guide →
- Right to Erasure in SalesforceGDPR
- How GDPR Article 17 right to erasure applies to Salesforce records, related objects, field history, and sandbox copies. When it applies, what it requires, and how to automate it. Read the guide →
- Sub-ProcessorCompliance
- Controller, processor, sub-processor is a chain of responsibility, and GDPR Article 28 governs how each link is authorised and contracted. Every vendor that touches personal data on your behalf becomes a link, which is why adding tools has a compliance cost that is separate from their licence fee. Read the guide →
- Universal Opt-Out MechanismConsent
- A universal opt-out mechanism lets someone signal their opt-out from sale and targeted advertising once, in their browser, rather than site by site. Several US states require businesses to honour it. The hard part is not detecting the signal, it is carrying it from the browser to the CRM record and making every downstream process respect it. Read the guide →
Beyond definitions
Guides that compare, evaluate, or set out requirements
- How to Evaluate Salesforce Data Masking Tools: 12 Criteria That Matter
- Salesforce Data Retention Requirements: What the Platform Keeps, and For How Long
Salesforce's native retention windows were designed for operational troubleshooting, not for regulatory evidence. Setup Audit Trail purges after 180 days; Field History Tracking holds 18 months. Regulatory retention mandates routinely run five to seven years. This guide maps the gap precisely and covers the four ways to close it.
- Salesforce Privacy Center Alternatives: A Buyer's Comparison
Privacy Center is priced as a percentage of your Salesforce net spend, which means its cost scales with your contract rather than with your privacy workload. This guide compares it against the four real alternatives: build, AppExchange, external platform, or do nothing, and says which one fits which org.
- Salesforce Shield vs. Data Masking: What’s the Difference?
Salesforce Shield encrypts data at rest. Data masking replaces data with realistic substitutes. They solve completely different problems. Here’s when you need each.and why Shield doesn’t protect sandbox environments.
Definitions are the easy part
Making them true inside a Salesforce org — masking, retention, DSARs, consent — is what Cloud Compliance does.