Not the system going down. Not a slow performance issue. The data itself: contacts, opportunities, activity history, custom object records, all gone. The silence that follows usually isn’t confidence. It’s the pause of someone who has never had to answer that question for real.
Here’s what most Salesforce customers don’t fully appreciate: the platform’s legendary reliability does not extend to your data. And the reason why goes back to a foundational principle of cloud computing that too few organizations have taken on board.
The shared responsibility gap: how it came about
The shared responsibility model didn’t originate with Salesforce. It’s a principle that emerged with cloud computing in general and was formalized by hyperscalers like AWS, Azure, and Google Cloud as a way of delineating the boundary between what a provider is accountable for and what falls to the customer.
The logic is sound.
Cloud providers own:
- The infrastructure
- The physical hardware
- Network
- Uptime
- And the security of the platform itself
Customers own what they put inside it:
- The data they create, import, and manage.
It’s a reasonable division of labor, and it’s spelled out in the terms of service
The gap emerged not from bad faith, but from a mismatch in perception. Salesforce’s reputation for enterprise-grade reliability – 99.9% uptime SLAs, world-class infrastructure, SOC II compliance – led organizations to assume the safety net was broader than it actually is. If the platform is this robust, surely the data is protected too? It isn’t. The platform runs flawlessly while your data disappears, and Salesforce has no obligation to recover it for you.
“What surprises people most isn’t that the gap exists — it’s how long it’s been sitting there unnoticed. Most Salesforce orgs have been running for years without anyone testing what recovery would actually look like. The shared responsibility model was there in terms of service the whole time. Nobody read it as a warning,” says Markku Teerikangas, Head of IT at Cloud Protection for Salesforce.
The issues raised
Salesforce does offer some native tools – a 15-day recycle bin, a scheduled Data Export Service, and an enterprise Data Recovery Service (though its discontinuation in 2020, before being reinstated under pressure, speaks to how central it is to Salesforce’s priorities). But these aren’t a backup strategy for an enterprise company. Weekly CSV exports don’t provide point-in-time recovery, don’t restore record relationships, and don’t capture metadata or workflow history. If corrupted data goes unnoticed for a week, your last clean export may already be overwritten.
The consequences show up in recognizable ways: a developer overwrites 40,000 records in production instead of sandbox; a sales rep bulk-deletes their pipeline before walking out the door; a third-party integration silently corrupts data across the org. In each case, the impact reaches well beyond IT – sales loses deal visibility, customer service loses account history, and leadership is left working from data it can no longer trust.
Closing the gap: what organizations should do
Recognizing the gap is the starting point. Closing it requires treating Salesforce data with the same rigor applied to any other critical business system. This means going beyond what the platform provides natively.
The foundation is automated, continuous backup: not a scheduled export, but a solution that captures changes in real-time and maintains a complete, restorable history of your org’s data. This should include records, relationships, metadata, and configuration – not just a flat export of current values.
Equally important is the ability to restore granularly. Recovering from a data loss event shouldn’t mean importing a month-old CSV and manually reconciling thousands of records. It should mean selecting a point in time, identifying the affected data, and restoring it cleanly. In minutes, not days.
The best solutions in this space are built natively for Salesforce, integrating directly with the platform without requiring complex middleware or technical overhead to maintain. Crucially, they make backup and recovery accessible to the people who need it – not just IT, but Salesforce admins, RevOps teams, and business users – so that when something goes wrong, the right person can act without waiting for a ticket to be resolved.
Visibility matters, too. Knowing what data exists in your org, who has access to it, and what’s changed over time is foundational to both recovery and broader security hygiene. The right tooling surfaces that information as a matter of course, rather than requiring a forensic effort after the fact.
“The organizations that get this right stop asking ‘how do we back up Salesforce data’ and start asking ‘how do we restore Salesforce operations?’ That reframing is everything. A native approach understands the platform’s structure well enough to put things back exactly as they were – not just the values, but the relationships and configuration around them. That’s the difference between a restore that takes minutes and one that takes weeks of manual reconciliation,” Teerikangas concludes.
Take the next step
The shared responsibility model puts the obligation on you. Understanding exactly where your current setup meets that obligation – and where it doesn’t – is the first step toward closing the gap.