For many enterprise organizations, that map has a gap in it. And the gap is the CRM itself.
Salesforce is one of the largest stores of personal data in most enterprise environments. Within it you have customer contact details, behavioral history, communications records, financial information. However, CRM data often receives less attention than traditional databases, email, or file repositories when organizations design privacy-governance processes.
The tooling, processes, and governance frameworks that apply to databases, cloud storage, and email infrastructure often don’t extend to the CRM with the same rigor. The result is a compliance exposure that sits in plain sight and rarely gets addressed until a regulator or an incident forces the issue.
The regulatory landscape
Privacy regulations, including GDPR and CCPA, differ in their specific requirements, but they do share several practical expectations: organizations need to both understand the personal data they hold and be able to respond appropriately when individuals exercise rights such as access, correction or deletion. GDPR also imposes requirements around purposes of processing, storage periods and accountability.
Each of these requirements has a direct application to Salesforce. A customer invoking their right to erasure under GDPR doesn’t care which system their data lives in. Where an erasure request is valid, the organization needs to be able to locate the relevant personal data and delete it, or else appropriately handle it across the systems where it resides. A data subject access request requires a complete picture of what you hold, including notes, activity history, and associated records that may be spread across multiple objects in the org. A data protection audit will ask whether your retention policies apply consistently, including to your CRM.
The challenge isn’t that these requirements are unclear. It’s that meeting them in Salesforce can require deliberate configuration, governance, and visibility across the data held in the org, and compliance teams may not always have that visibility.
“The difficult part isn’t recognizing that Salesforce contains personal data. It’s understanding where that data may exist across the Salesforce org. It can be spread across standard and custom objects, files, cases, activity records and integrations. Without that visibility, it becomes difficult to know whether retention, deletion and access policies are being applied consistently,” says Karmina Aquino, Head of Threat Intelligence at Cloud Protection by WithSecure.
Where the gaps appear in practice
There are three main areas to consider here. The first is the right to erasure. Deleting a contact record in Salesforce doesn’t necessarily delete all personal data associated with that individual. Activity history, email logs, custom object records, related cases, and notes may all hold personal data that persists independently. Complying with an erasure request requires identifying and removing all of it – a process that, in a complex org with years of accumulated data, is considerably harder than it sounds.
Data residency is another area that requires attention. Salesforce Hyperforce provides customers with control over the region in which their data resides, but residency requirements need to be evaluated across the services and features an organization uses.
Some integrated services and features can have different storage or processing locations from the core Salesforce org. For organizations operating across jurisdictions, understanding those data flows and the contractual mechanisms governing them is an important part of privacy compliance.
Retention is the third aspect here. Most organizations have defined retention policies for email and document storage. Applying equivalent policies to CRM data, such as deciding how long contact, opportunity, and activity records should be kept, and enforcing that consistently, requires deliberate configuration that many orgs haven’t done.
The audit trail problem
Beyond individual rights requests, regulators increasingly expect organizations to demonstrate compliance and not just assert it. That means being able to show what data you held, when you held it, who had access to it, and what happened to it over time.
Salesforce’s native audit capabilities have limits here. Event logs have finite retention windows. Field history tracking requires manual configuration on a per-object basis and doesn’t capture everything by default. If a regulator asks for a complete account of data processing activity in your Salesforce org over the past three years, the native tools may not give you what you need.
“The direction from regulators is clear: it is not enough to have a privacy policy on paper. Organizations need to be able to demonstrate that rights such as access and erasure can actually be carried out across the systems where personal data lives. As more customer data and business processes move into SaaS platforms, those platforms have to be part of that operational compliance picture,” Aquino states.
The takeaway
Closing the Salesforce compliance gap requires treating the CRM as the personal data store it is, with the same governance rigor applied to other high-risk systems. That means mapping the data held, configuring retention policies, enabling adequate audit logging, and building processes for fulfilling data subject rights requests that account for the full complexity of the Salesforce data model.
It also means having visibility into the data itself: the ability to search, identify, and act on personal data across all objects in the org, not just the obvious ones. The organizations that are best positioned on this are the ones that have invested in tooling that surfaces that visibility automatically, rather than relying on manual processes that can’t scale to the volume and complexity of enterprise CRM data.
Regulators are paying closer attention to SaaS platforms than they were three years ago. The compliance gap that has been quietly growing in enterprise Salesforce orgs is increasingly likely to matter.