GDPR Compliance in Salesforce: A Technical Implementation Guide

Consent Management and the Individual Object

Under the General Data Protection Regulation (GDPR), organisations are strictly required to manage data subjects' consent with a high degree of granularity. In Salesforce, treating consent as a simple checkbox on the Contact or Lead record is no longer sufficient or compliant. Standardising on the standard Individual object represents the architectural gold standard for consent management. The Individual object acts as a central repository for privacy preferences, decoupled from the specific communication channels (Lead, Contact, User, or Person Account), thereby enabling a unified and compliant view of data subject desires.

The Individual object stores critical consent flags such as SendIndividualRequests, ShouldForget, HasOptedOutSolicit, and HasOptedOutTracking. To establish a robust architecture, you must establish a 1:1 lookup relationship between the Contact/Lead and the Individual record. When a new prospect or customer is created, a trigger or flow should automatically instantiate a corresponding Individual record if one does not already exist. This process ensures that privacy settings are synchronised across all touchpoints, preventing accidental communication that violates the subject's stated preferences.

Here is an Apex trigger handler pattern that illustrates how to programmatically enforce this alignment and ensure every Contact has a corresponding Individual record:

public class ContactIndividualSyncHandler {
    public static void ensureIndividualRecords(List<Contact> contacts) {
        List<Contact> contactsNeedIndividual = new List<Contact>();
        for (Contact c : contacts) {
            if (c.IndividualId == null) {
                contactsNeedIndividual.add(c);
            }
        }
        
        if (contactsNeedIndividual.isEmpty()) {
            return;
        }
        
        List<Individual> individualsToCreate = new List<Individual>();
        for (Contact c : contactsNeedIndividual) {
            individualsToCreate.add(new Individual(
                FirstName = c.FirstName,
                LastName = c.LastName,
                EmailAddress = c.Email,
                SendIndividualRequests = true
            ));
        }
        
        insert individualsToCreate;
        
        for (Integer i = 0; i < contactsNeedIndividual.size(); i++) {
            contactsNeedIndividual[i].IndividualId = individualsToCreate[i].Id;
        }
    }
}

By utilising this centralised approach, any privacy preference update made to the Individual record is immediately inherited by the associated Contact, Lead, or User. This architecture mitigates the compliance risk associated with disjointed, siloed consent checkboxes across different functional areas of the Salesforce platform.

Implementing the Right to Erasure (Anonymisation vs Hard Deletion)

GDPR Article 17 defines the "Right to Erasure" (commonly known as the Right to be Forgotten). When an individual exercises this right, organisations must delete or obfuscate their personal data without undue delay. In Salesforce, executing a hard database delete (via the hardDelete() API method or standard Apex delete) presents significant technical and analytical challenges. Hard deletion cascades to child records, orphans historic activity histories, and breaks key relational constraints. Crucially, it completely destroys historical aggregate metrics, leaving the organisation unable to perform accurate revenue attribution or trend analysis.

To resolve this, architects must design an anonymisation framework that obfuscates personally identifiable information (PII) while preserving the non-identifiable, transactional record structure for analytical purposes. For example, replacing a Contact's name with "Anonymised Subject", clearing their phone number, and resetting their email address to a dummy domain (such as forgotten@anonymised.sfvedas.com) allows the business to retain the integrity of sales pipelines and historical dashboards.

An anonymisation service must run asynchronously to avoid hitting transaction governors and limits, particularly when child records and history tables must also be cleaned. The following Queueable Apex pattern demonstrates how to safely perform mass obfuscation of data subject records:

public class GDPRAnonymisationService implements Queueable {
    private List<Id> contactIds;
    
    public GDPRAnonymisationService(List<Id> contactIds) {
        this.contactIds = contactIds;
    }
    
    public void execute(QueueableContext context) {
        List<Contact> contactsToAnonymise = [
            SELECT Id, FirstName, LastName, Email, Phone, MobilePhone, MailingStreet, MailingCity, IndividualId 
            FROM Contact 
            WHERE Id IN :contactIds
        ];
        
        List<Individual> individualsToForget = new List<Individual>();
        
        for (Contact c : contactsToAnonymise) {
            c.FirstName = 'Forgotten';
            c.LastName = 'Individual';
            c.Email = 'forgotten-' + c.Id + '@anonymised.sfvedas.com';
            c.Phone = null;
            c.MobilePhone = null;
            c.MailingStreet = null;
            c.MailingCity = null;
            
            if (c.IndividualId != null) {
                individualsToForget.add(new Individual(
                    Id = c.IndividualId,
                    ShouldForget = true,
                    LastName = 'Forgotten'
                ));
            }
        }
        
        update contactsToAnonymise;
        if (!individualsToForget.isEmpty()) {
            update individualsToForget;
        }
    }
}

This Queueable pattern represents a safe, scalable method to meet the Right to Erasure. It minimises the footprint of PII while preserving the record's underlying ID structure, ensuring that your reports, financial summaries, and security tracking remain accurate and consistent.

Restricting Data Processing and Portability Workflows

GDPR Article 18 grants data subjects the right to restrict the processing of their personal data under specific circumstances, such as during a dispute over data accuracy. When processing is restricted, the data can only be stored; it cannot be modified, shared with external integrations, or used in marketing campaigns.

Architecturally, enforcing this requires a dynamic locking mechanism. A standard practice is to deploy a custom flag on the Contact or Individual object, such as Is_Processing_Restricted__c. This flag must be evaluated by every downstream process, including Apex triggers, Flow builders, integration middleware, and marketing automation connectors (like Marketing Cloud or Pardot).

For user-facing interactions, you can enforce this restriction using declarative Salesforce validation rules that prevent any modifications to records under active restriction:

AND(
    OR(
        ISCHANGED(FirstName),
        ISCHANGED(LastName),
        ISCHANGED(Email),
        ISCHANGED(Phone)
    ),
    Individual.Is_Processing_Restricted__c = TRUE
)

Additionally, GDPR Article 20 mandates the Right to Data Portability, requiring organisations to provide data subjects with their personal data in a structured, commonly used, and machine-readable format. The architectural response to this is to construct an API-driven extraction tool that compiles a data subject's record graph into a standardized JSON payload. The following Apex method demonstrates how to query a Contact's graph and return a structured JSON response suitable for direct delivery to the data subject:

public class GDPRPortabilityExporter {
    public static String exportDataSubjectGraph(Id contactId) {
        Contact contactData = [
            SELECT Id, FirstName, LastName, Email, Phone,
                (SELECT Id, Subject, Status FROM Cases),
                (SELECT Id, ActivityDate, Subject FROM ActivityHistories)
            FROM Contact 
            WHERE Id = :contactId
        ];
        
        Map<String, Object> exportPayload = new Map<String, Object>();
        exportPayload.put('subject_id', contactData.Id);
        exportPayload.put('first_name', contactData.FirstName);
        exportPayload.put('last_name', contactData.LastName);
        exportPayload.put('email', contactData.Email);
        exportPayload.put('phone', contactData.Phone);
        
        List<Map<String, Object>> cases = new List<Map<String, Object>>();
        for (Case c : contactData.Cases) {
            cases.add(new Map<String, Object>{
                'case_id' => c.Id,
                'subject' => c.Subject,
                'status' => c.Status
            });
        }
        exportPayload.put('cases', cases);
        
        return JSON.serializePretty(exportPayload);
    }
}

By implementing this automated export capability, your organisation can fulfill portability requests rapidly and programmatically, reducing administrative overhead and eliminating manual database extraction efforts.

Automating GDPR Audits and Compliance Dashboards

Fulfilling GDPR obligations requires absolute transparency. Under Article 30, organisations must maintain a record of processing activities, and they must be prepared to prove compliance to supervisory authorities at any moment. In Salesforce, this audit capability is achieved by combining three distinct native layers: Field History Tracking, Shield Field Audit Trail, and Real-Time Event Monitoring.

Field History Tracking captures the "who, when, and what" of field-level modifications. However, standard tracking is limited to 20 fields per object and a retention period of 18 months. For high-volume enterprise architectures, this is insufficient. Implementing Salesforce Shield Field Audit Trail allows you to track up to 60 fields per object and retain that audit history in big objects for up to ten years, meeting the stringent retention requirements of national regulatory bodies.

To demonstrate compliance programmatically, you should deploy automated batch classes that sweep audit histories and flag compliance gaps—such as PII fields that are modified without an associated Consent record. The following SOQL pattern demonstrates how to programmatically query audit history tables to identify modifications to sensitive data fields:

SELECT ParentId, OldValue, NewValue, Field, CreatedById, CreatedDate 
FROM ContactHistory 
WHERE Field IN ('Email', 'Phone', 'MailingStreet') 
ORDER BY CreatedDate DESC 
LIMIT 500

These raw histories can then be aggregated into central compliance dashboards. DPOs (Data Protection Officers) can monitor key risk indicators, such as the volume of anonymisation requests processed, the percentage of restricted records, and any unauthorised changes to opt-out statuses.

Architectural Governance and Data Lifecycle Control

The final pillar of a GDPR-compliant Salesforce ecosystem is robust data lifecycle governance. Compliance is not merely a production database concern; it must extend to your entire sandbox development pipeline. When copy paste operations or refresh tasks copy production data into Dev or Full Copy sandboxes, sensitive PII is exposed to developers, QA testers, and third-party contractors. This represents a critical compliance violation.

To mitigate this risk, you must deploy Salesforce Data Mask as a standard component of your sandbox creation process. Data Mask automatically obfuscates, anonymises, or deletes PII in sandboxes, ensuring that testing and development are performed using realistic but synthetically generated data.

Furthermore, standardise your data retention policies using automated data deletion pipelines. Establish hard limits on how long inactive Leads or closed Cases are stored. By purging stale data programmatically, you minimise your data footprint and limit the impact of any potential security breach. In summary, GDPR compliance requires a proactive, secure-by-design approach. By implementing centralised consent management, scalable asynchronous anonymisation, strict record locking, automated JSON portability exports, and comprehensive sandbox masking, your organisation can confidently satisfy European regulations while maintaining high-performing CRM systems.