This is not a niche concern. Departing employees are a well-recognized insider-risk scenario, particularly where users have legitimate access to commercially sensitive data. The combination of high-value data, broad user access, and limited monitoring creates exactly the conditions that make it easy to walk out the door with more than a company laptop.
Why Salesforce is particularly exposed
Most enterprise data loss prevention tools are designed around the file system and email. They monitor what gets attached to an outbound message, what gets copied to a USB drive, and what leaves the network perimeter. Salesforce sits largely outside that coverage. A sales rep who exports their entire account list to a CSV through the Salesforce UI isn’t triggering a DLP alert – they’re doing something that looks, to most monitoring systems, like normal work.
The data at risk is also uniquely valuable. A Salesforce org built up over several years contains customer contact details, full account and opportunity history, deal values, renewal dates, pricing structures, and relationship notes that no public database can replicate. For a sales rep moving to a competitor, that data has immediate commercial value. For a disgruntled employee, it’s leverage. For someone simply being careless on their last week, it’s a liability the company may not know about for months.
“CRM data is particularly difficult to replace. There are years of relationship history, renewal dates, and pricing context that doesn’t exist in any public source. For someone moving to a competitor, it’s a head start that would otherwise take months to build. What makes CRM exfiltration especially concerning is that the value of the data is obvious, and the barrier to taking it can be low,” according to Karmina Aquino, Head of Threat Intelligence at WithSecure Cloud Protection for Salesforce.
The window of exposure
The risk doesn’t begin on the last day. It often starts weeks earlier, when a resignation is submitted, a new role accepted, or a relationship with a manager deteriorates. In the period between that moment and the point when access is formally revoked, a motivated individual has ample opportunity to act.
Even when offboarding is handled promptly, the window can be wider than it appears. Access revocation in Salesforce requires deliberate action: deactivating the user account and reassigning records, as well as reviewing sharing rules and connected app permissions. In large orgs with complex configurations, this is rarely as clean as an IT checklist implies. OAuth tokens granted to third-party apps may persist. Shared login credentials, where they exist, are harder to revoke entirely. In organizations where offboarding is handled centrally by IT rather than by Salesforce admins, the specific steps required for the platform may simply be missed.
The result is a meaningful gap between when a person stops being an employee and when they stop being able to access your data.
The detection problem
What makes this risk particularly difficult to manage is how hard it is to see in hindsight. Salesforce provides several native sources of audit and activity data – Setup Audit Trail, Field History Tracking, Event Monitoring, Login History – but the level of visibility, retention, and real-time detection available depends on the features and licensing in use. Without Transaction Security Policies from Shield, the default setup has significant gaps: event log retention is 30 days for most orgs, field-level history tracking has to be manually enabled for each object, and large-scale exports don’t generate the kind of alerts that would prompt immediate investigation.
By the time a company realizes that a former employee took their pipeline data or deleted their account records, the audit trail may already be gone. And even where logs exist, reconstructing what happened – such as which records were accessed, exported, or deleted, and when – requires a level of forensic effort that most teams aren’t equipped to undertake quickly.
“Having logs is not the same as having detection. Meaningful monitoring requires enough context to recognise when otherwise legitimate user activity becomes unusual or risky, and the ability to act before that activity results in data loss,” Aquino concludes.
How to prevent it
Protecting Salesforce data from departing employees isn’t solely an HR or IT problem. Instead, it’s a data governance problem that requires the right tooling to solve. Effective protection means three things working together.
First, continuous visibility into user activity: not just login events, but what data is being accessed, exported, or deleted, and by whom. This needs to be always-on, not reconstructed after the fact.
Second, complete and granular backup. If a departing employee deletes or corrupts records – intentionally or otherwise – the ability to restore that data to a specific point in time, without depending on a 15-day recycle bin, is the difference between a recoverable incident and a permanent loss.
Third, a clear offboarding process specific to Salesforce: one that goes beyond deactivating a user account to include reviewing connected app access, OAuth tokens, shared credentials, and data exports in the period leading up to departure.
Departures are inevitable. Data loss because of them doesn’t have to be.