GDPR Considerations for Salesforce: 8 Areas Every Team Must Review

TL;DR

GDPR considerations for Salesforce cover how businesses collect, store, secure, and manage personal data inside their CRM. Salesforce provides privacy tools, but organizations remain responsible for consent, access controls, data retention, and compliance processes.

To stay prepared:

• Map personal data across Salesforce objects and apps.
• Review permissions and security controls regularly.
• Maintain consent and privacy request workflows.
• Remove unnecessary data through clear retention rules.

Introduction

A single GDPR request can give your organization just one month to provide, correct, or erase a person's personal data. In Salesforce, that often means tracing one individual across Contacts, Leads, Cases, Files, activities, custom objects, and connected apps before the deadline expires.

The core GDPR considerations for Salesforce begin with a simple question: can you identify every place where that person's data exists and prove why you are processing it?

Salesforce provides privacy and security capabilities, but it does not automatically map personal data, record your lawful basis for processing, manage retention, or fulfill data subject requests. Those responsibilities depend on how your org is designed and governed.

GDPR compliance in Salesforce is a data architecture problem before it becomes a legal one. This guide explains the practical decisions that help you build a Salesforce org that supports compliance from day one.

What Are the Core GDPR Considerations for Salesforce?

GDPR is the European Union's data protection law that sets rules for how organizations collect, use, store, share, and delete the personal data of EU residents. The core GDPR considerations for Salesforce focus on configuring your Salesforce org to handle personal data lawfully and protect it from unauthorized access.

They also include respecting individual privacy rights and meeting GDPR compliance requirements. Salesforce acts as the data processor, while your organization acts as the data controller and remains responsible for compliance.

The core GDPR considerations for Salesforce include:

1. Understand the responsibilities of Salesforce as the data processor and your organization as the data controller.
2. Establish a lawful basis for every activity that collects or processes personal data.
3. Track and manage consent by using the Salesforce Individual object.
4. Apply privacy by design and data minimization across your Salesforce data model.
5. Support data subject rights, including the right to access, correct, export, and erase personal data.
6. Protect personal data by meeting the security requirements outlined in GDPR Article 32.
7. Review Data Processing Agreements (DPAs) for every AppExchange app and external integration that processes personal data.

Each of these considerations supports a different part of GDPR compliance in Salesforce. Understanding them first makes it easier to design your org, manage personal data, and respond confidently to compliance requests.

Controller and Processor: Where Salesforce's Responsibility Ends

Salesforce's responsibility ends at running a secure platform and offering tools that support GDPR compliance. Once your Salesforce org is set up, your business becomes responsible for deciding why customer data is collected, who can access it, how long it is stored, and when it is deleted.

Under GDPR, Salesforce acts as the data processor, while your business acts as the data controller.

The table shows where Salesforce's responsibility ends. The next step is understanding what each role covers in practice.

Salesforce's Role as Data Processor

Salesforce runs the platform and supports compliance through security features and legal commitments. The Salesforce Trust site publishes the documents and reports that help customers understand these commitments.

Key resources include:

• The Data Processing Addendum (DPA) that explains how Salesforce handles customer data.
• Binding Corporate Rules (BCRs) approved by the French data protection authority (CNIL) to support global data transfers.
• The latest subprocessor list and SOC 2 reports.
• Health Check to review your security settings.
• Event Monitoring with Salesforce Shield to track activities such as user logins and API calls.

These features strengthen the platform. User permissions, sharing rules, and data retention settings remain under your control.

Your Business's Role as Data Controller

As the data controller, your business decides how customer data is collected, used, shared, stored, and deleted. It also remains responsible for proving that every processing activity meets GDPR requirements.

Review these areas regularly:

• Users with Modify All Data or View All Data permissions.
• Field-Level Security for sensitive fields.
• Organization-Wide Defaults, role hierarchy, and sharing rules for Contact, Lead, and Individual records.
• Bulk data exports and who can download customer data.
• Records of permission reviews and compliance checks for future audits.

The DPA, SCCs, and Cross-Border Data Transfers

If customer data moves outside the European Economic Area (EEA), you need a valid legal transfer mechanism. Salesforce includes the European Commission's Standard Contractual Clauses (SCCs) in its Data Processing Addendum (DPA) and also maintains Binding Corporate Rules (BCRs) for global data transfers.

Before connecting an AppExchange app or external integration, verify:

• A valid Data Processing Addendum (DPA) is in place.
• The vendor's Standard Contractual Clauses (SCCs) cover international data transfers where needed.
• The vendor appears on the latest subprocessor list, if applicable.
• Signed agreements are stored with your compliance records.

Understanding who is responsible is the first step. The next challenge is making sure every piece of personal data in Salesforce has a clear legal reason for being collected and processed.

Establishing a Lawful Basis for Processing in Salesforce

A lawful basis is the legal reason your organization has for collecting and using personal data. Under GDPR Article 6, every record in Salesforce should have a lawful basis before anyone collects, stores, or uses that information.

Without one, even well-managed customer data can become a compliance risk.

The Six Lawful Bases and Which Fit CRM Data

GDPR defines six lawful bases for processing personal data, but most Salesforce teams use only a few of them in day-to-day work. Choosing the right one depends on why you collect the information in the first place.

For most businesses, Consent, Contract, and Legitimate Interest cover the majority of CRM activities. For example, promotional emails usually require Consent, which is why Salesforce Email Consent Management helps teams track when and how permission was collected before sending campaigns.

After choosing the correct lawful basis, store it with the record so it stays connected to the data throughout its lifecycle. Add a Lawful_Basis__c picklist field to the Lead, Contact, and Individual objects with these values:

• Consent
• Contract
• Legal Obligation
• Vital Interests
• Public Task
• Legitimate Interest

If you rely on Legitimate Interest, create a Legitimate_Interest_Assessment__c long text field to record why you chose that basis and the outcome of your balancing test.

Where Lawful Basis Breaks Down in Real Salesforce Orgs

Most compliance gaps don't happen because teams choose the wrong lawful basis. They happen because the information is never recorded consistently across the org.

Check these common problem areas:

• Data imports: Data Loader and the Data Import Wizard often skip the Lawful_Basis__c field. Add a Validation Rule using ISBLANK(Lawful_Basis__c) so records cannot be imported without a value.
• Web-to-Lead forms: Map a hidden field to Lawful_Basis__c = "Consent" and store a timestamp showing when consent was given.
• Custom objects: Include a lawful basis field in your standard checklist whenever a new object is created instead of adding it later.
• Existing records: Find contacts without a lawful basis by running:
  SELECT Count() FROM Contact WHERE Lawful_Basis__c = null
  Review the results in smaller batches using CreatedDate or LastModifiedDate. Updating records a little at a time is easier to manage and less disruptive than trying to fix everything at once.

Recording the lawful basis when data first enters Salesforce saves time later. It also supports better privacy practices through tools such as a Salesforce Email Preference Center, where customers can manage their communication choices.

Individual Object Consent Tracking in Salesforce

The Salesforce Individual object stores privacy preferences for people in your org. It connects with records such as Leads, Contacts, and Person Accounts, giving teams a central place to manage consent choices and privacy settings.

What the Individual Object Does and Does Not Solve

The Individual object creates a dedicated record for privacy-related information. It connects a person's preferences with Salesforce records through the standard IndividualId lookup field.

Enable it from:

Setup → Data Protection and Privacy → Make data protection details available in records

After enabling it, Salesforce can connect Individual records with:

• Leads, Contacts, Person Accounts, and custom objects that store information about a person.
• Standard privacy fields such as HasOptedOutSolicit, HasOptedOutGeoTracking, ShouldForget, SendIndividualData, and SendOwnPurposeShareUsage to store privacy preferences.
• Existing records through Apex or Flow because Salesforce does not provide a built-in option to create Individual records for all existing Contacts.

Individual records do not count toward Salesforce data storage limits. However, enabling the Individual object does not automatically keep privacy information complete. Teams still need processes to capture preferences, update changes, and maintain accurate Salesforce Email Compliance Reporting.

Common Consent-Tracking Gaps That Create Risk

Many Salesforce orgs enable the Individual object but still have gaps because privacy preferences are stored across different fields and processes.

Common issues include:

• Contact-level HasOptedOutOfEmail does not automatically update Individual.HasOptedOutSolicit, so teams need a Record-Triggered Flow to keep both values aligned and maintain accurate Salesforce Email Opt Out records.
• Salesforce does not include a default consent timestamp, so teams should add fields such as Consent_Captured_At__c and Consent_Source__c to record when and where consent was collected.
• Consent Management features such as Consent Purpose and Contact Point Type Consent require separate enablement and field mapping before teams can use them.
• Teams should enable Field History Tracking on consent-related fields or use Salesforce Shield Field Audit Trail when they need longer audit history.
• Organizations can identify outdated consent records by reviewing Individuals where Consent_Captured_At__c is older than their defined review period.

For example:

SELECT Count() FROM Individual WHERE Consent_Captured_At__c < TODAY - 730

Review older consent records in batches instead of updating the entire database at once. This makes cleanup easier to manage and reduces disruption to daily Salesforce operations.

A well-managed Individual object gives your Salesforce org a clearer view of privacy preferences. The next step is applying privacy by design principles so your teams collect and store only the information they actually need.

Privacy by Design and Data Minimization in Salesforce

Privacy by design means building privacy protections into Salesforce changes before they go live. Data minimization means collecting, storing, and reporting only the information needed for a specific business purpose. Together, these principles help teams reduce privacy risks as their Salesforce org grows.

What Article 25 Requires at the Architecture Level

GDPR Article 25 requires organizations to consider privacy when they design systems, processes, and new features. In Salesforce, this means adding a privacy review step whenever teams create new objects, fields, integrations, or automation.

Build privacy into your Salesforce change process by:

• Reviewing new objects, fields, and integrations before release to understand what personal data they collect and why they need it.
• Setting Contact and Lead sharing defaults to Private when appropriate, then adjusting access based on business requirements through Sharing Settings.
• Checking Field Accessibility before releasing new fields to confirm that only the right users can view sensitive information.
• Involving a privacy lead or legal team before creating new data models because changing a design later usually takes more effort.
• Creating a Privacy_Review__c custom object linked to project or change records to store design decisions and approval history. Keeping these records alongside Salesforce Audit Trails helps teams understand what changed, when it changed, and who approved the decision.

A privacy review does not need to slow down Salesforce development. Adding it to existing change-management steps helps teams catch risks before they become expensive fixes.

Applying Data Minimization to Fields, Objects, and Reports

Salesforce orgs often collect more information than teams actively use. Regular reviews help remove unnecessary data and reduce the amount of personal information stored across the platform.

Apply data minimization by:

• Running Salesforce Optimizer and reviewing Field Usage reports to find unused custom fields that no longer support business processes.
• Setting clear retention rules and using tools such as scheduled Apex or Data Mask to remove personal fields after the retention period ends.
• Reviewing reports and dashboards for unnecessary Email, Phone, or Address columns that expose personal information without a clear purpose.
• Retiring unused fields safely by renaming them to ZZ_[fieldname], waiting for dependency checks, and deleting them only after confirming they are no longer needed.
• Moving historical records to options such as Big Objects or external storage instead of keeping old information in active Salesforce objects.

A clear Salesforce Data Retention strategy helps teams decide what to keep, what to remove, and how long information should remain available.

When to Run a DPIA Before Building in Salesforce

A Data Protection Impact Assessment (DPIA) helps teams identify privacy risks before launching projects that may create higher-risk processing activities.

Run a DPIA before:

• Using large-scale profiling tools such as Einstein Lead Scoring, Einstein Prediction Builder, or other models that analyze customer data.
• Processing sensitive personal data or building solutions that involve higher-risk data use.
• Enabling advanced personalization features such as Salesforce Marketing Personalization Engine or custom AI and machine learning solutions.
• Moving personal data across regions where additional privacy requirements may apply.

Store completed DPIAs with the related project or change record so teams can review decisions later. Salesforce also commits to supporting customer DPIA efforts through its Data Processing Addendum, and teams can request vendor assistance when needed.

Tracking DPIA outcomes in a dedicated DPIA__c custom object creates a clear record of privacy decisions and supports future audits.

Building privacy into Salesforce design decisions makes compliance easier to maintain as your org changes. The next step is protecting personal data through security controls, access management, and monitoring.

Data Subject Rights and Right to Erasure in Salesforce

Data subject rights give individuals control over their personal data. In Salesforce, teams need clear processes to handle requests for access, correction, portability, and deletion while keeping records accurate and meeting GDPR timelines.

The Core Rights: Access, Rectification, Erasure, and Portability

GDPR gives individuals four key rights that Salesforce teams commonly handle:

For access requests, create a Flow or Apex class that collects data from Contact, Individual, and related records, then store the export as a Content Document.

For rectification requests, standard Salesforce permissions usually cover updates. Enable Field History Tracking on important fields to review changes.

For portability requests, use SOQL queries and data export tools to prepare a machine-readable file. GDPR generally requires a response within one month.

For deletion requests, decide the approach before removing data. Teams usually choose between deletion, anonymization, or masking depending on retention needs.

Create a DSR_Request__c custom object to track requests, owners, and response deadlines.

Executing Right to Erasure Without Breaking Related Records

Erasure requires planning because Salesforce records often connect across objects. Removing one record can affect related opportunities, cases, activities, and custom objects.

Follow these steps:

• Check record dependencies before deletion using tools such as Schema Builder to identify connected records and relationships.
• Choose whether to delete, anonymize, or mask information based on business and retention requirements.
• Replace identifying details with values such as REDACTED- plus the record ID when you need to keep the record structure.
• Deactivate user records instead of deleting them because Salesforce does not allow user deletion.
• Use Salesforce Data Mask to anonymize sensitive data in sandbox environments.
• Store every erasure event in an Erasure_Audit__c object with the request date, affected records, method used, and person who completed the action.

A clear erasure process helps teams handle privacy requests without disrupting connected Salesforce data. For teams managing large-scale customer communication, keeping these privacy preferences aligned with tools such as MassMailer helps maintain accurate email workflows. The next step is protecting that data through security controls and monitoring.

Security of Processing, Shield, Article 32, and AppExchange DPAs

GDPR Article 32 requires organizations to use security measures that match the risk level of the personal data they handle. In Salesforce, this means protecting data through encryption, monitoring, audit history, and careful review of third-party apps that access customer information.

Encryption, Audit Trail, and What Shield Does Not Cover

Salesforce Shield adds security features that help teams protect and monitor sensitive data. These controls support GDPR security requirements, but they work only when the wider Salesforce setup is managed correctly.

Key Shield capabilities include:

• Shield Platform Encryption protects selected fields while data is stored. Configure it from Setup → Platform Encryption → Encryption Policy and choose which fields require encryption.
• Field Audit Trail keeps field history for up to 10 years, compared with the standard 18-month limit of Field History Tracking.
• Event Monitoring shows activities such as LoginEvent, ReportEvent, ApiEvent, and URIEvent to help teams understand who accessed data, when they accessed it, and where the activity came from.

Shield strengthens security controls, but it does not replace good Salesforce design. Teams still need accurate permissions, clear privacy processes, and reliable data-handling workflows.

Why Every Connected App Needs Its Own DPA

Every AppExchange app that processes personal data creates another point where data security needs review. This includes Salesforce email tools such as MassMailer, where teams should evaluate data handling practices, email security controls, and compliance documentation before connecting the platform to customer records.

Review connected apps by:

• Checking the vendor's DPA from the AppExchange listing or requesting it directly before installation, including free trials.
• Reviewing security certifications such as ISO 27001 or SOC 2 Type II where available.
• Tracking installed apps in a Vendor__c object with details such as DPA status, certification, and last review date.
• Reviewing installed packages quarterly through Setup → Installed Packages and confirming each app still has a valid business purpose.

Keeping vendor reviews documented helps teams understand who can access Salesforce data and why. Strong security depends on both platform controls and the applications connected to your org.

Final Thoughts: Building a GDPR-Ready Salesforce Org

GDPR considerations for Salesforce go beyond meeting a single compliance requirement. They require ongoing attention to how your org collects, stores, secures, and manages personal data as your business changes.

Start by reviewing your data flows, access settings, consent records, retention rules, and connected apps. Small improvements in these areas help your team respond faster to privacy requests and reduce compliance risks over time.

For organizations sending customer emails from Salesforce, keeping communication preferences and sending activity connected to your CRM is equally important. MassMailer helps teams manage Salesforce email workflows while maintaining better control over customer data.

Want to simplify GDPR-aligned email sending in Salesforce? Book a demo with MassMailer and see how you can manage high-volume communication from your CRM.