That invisibility is part of why the risk doesn’t get taken seriously. It’s also why the real cost is consistently underestimated. The absence of a visible incident isn’t evidence that the risk is low. It’s evidence that when incidents happen, the costs get distributed across the business in ways that never appear on a single line in a post-incident report.
How does data loss happen in practice?
The scenarios are mundane, and that’s the point:
- A developer runs a data loader operation against the wrong environment and bulk-overwrites account records
- A mass deletion triggered by a workflow rule cascades further than intended
- A departing employee removes records before their access is revoked
- A third-party integration pushes corrupted data in bulk before anyone notices
- An integration or API user provisioned with broader permissions than its function requires is exploited – either deliberately or by accident – to view, modify, or bulk-delete records well outside its intended scope
None of these require a sophisticated attacker or an unusual failure. They are the product of normal operational complexity in a large Salesforce org. They also happen with enough regularity that most organizations with mature Salesforce environments have experienced at least one meaningful data loss event, whether they classified it as such or not.
“Over-permissioning is the structural root of most Salesforce data loss. Most access is still managed through profiles rather than permission sets, the opposite of Salesforce’s own best-practice model,” says Tapas Tripathi, Salesforce Architect at Cloud Protection by WithSecure.
This is the exact gap Cloud Protection’s Identity Protection closes: it continuously scans permission set and profile assignments, surfaces the specific risky permissions tied to data loss and exposure, and gives admins a prioritized, actionable list of over-permissioned users to fix before they become the next incident.
The direct costs
When data loss occurs and recovery is possible, it is rarely fast or cheap. Salesforce’s native recovery options – the recycle bin, data exports, and the Data Recovery Service – each have limitations that become critical under pressure. The recycle bin has a 15-day window. Data exports are point-in-time snapshots that may predate the damage. The Data Recovery Service, where available, can take weeks and has historically been limited in scope.
Manual reconstruction is the fallback for many organizations. That means IT and Salesforce administration teams working through logs, CSVs, and fragmented records to rebuild what was lost. Depending on the volume and the complexity of the data, this can represent weeks of engineering time. For a large enterprise with a complex Salesforce configuration, a significant data loss event can consume more internal resources than most security incidents.
The costs that don’t show up immediately
The direct recovery costs are the visible part. The harder-to-quantify costs accumulate in the background and tend to be felt long after an incident is formally closed.
Revenue impact is the most significant. When pipeline data is lost or corrupted, deal visibility suffers. Sales managers are working from incomplete forecasts. Account executives are missing relationship history that would inform their next conversation. Renewal managers don’t have a clear view of upcoming opportunities. The CRM is less useful as a tool, and the downstream effect on revenue performance – particularly in complex, long-cycle enterprise sales – can be substantial and persist for months.
Customer trust is another. Where data loss leads to degraded service – a support agent without account history, a renewal conversation missing key context – customers notice. They may not know the reason, but the experience erodes confidence in ways that are hard to recover.
Increasingly, there are also regulatory implications. Where lost data includes personal information, the incident may trigger notification obligations under GDPR, CCPA, or equivalent frameworks. The cost of regulatory response, legal review, and potential enforcement action can dwarf the cost of the technical recovery.
For example, in the 2025–2026 ShinyHunters/Scattered Spider voice-phishing campaign, attackers posed as IT support to get Salesforce users to authorize a fake Data Loader connected app, then used that access to exfiltrate CRM data and threaten its deletion across multiple enterprise orgs – a real-world version of the “ransomware-adjacent” scenario above.
The takeaway
The business case for Salesforce data protection isn’t complicated. It comes down to the cost of an incident versus the cost of preventing one. At enterprise scale, the math always favors prevention.
What prevention requires is continuous, automated backup with granular restore capability: the ability to recover specific records, relationships, and configurations to a known point in time, without depending on native tools whose limitations become apparent exactly when you can least afford them.
It also means closing the over-permissioning gap: knowing exactly which users and integrations hold risky permissions, and being able to correct that access before it turns into a loss event, not after it has occurred.
The organizations that treat Salesforce data protection as a cost center are the ones who discover its value after an incident. The ones who treat it as a business continuity investment don’t have that story to tell.
Read more in our series: