The Salesforce shared responsibility model splits duties between Salesforce and its customers. Salesforce secures and runs the platform: the infrastructure, uptime, and application-level security.
You, the customer, own everything you put into it. Your data, your metadata, and your configuration are yours to manage, and that includes backing them up and recovering them when something goes wrong.
Most teams assume that because Salesforce is a trusted, enterprise-grade cloud, their data is automatically protected end to end. It is not.
Salesforce protects the platform from platform-level failures. It does not protect your records from your own users, your own deployments, or your own integrations. That gap is where data loss happens, and closing it is your job, not Salesforce's.
What is the Salesforce shared responsibility model?
The shared responsibility model is the standard way cloud providers divide security and data duties with their customers. The provider is responsible for the security of the cloud.
The customer is responsible for security in the cloud. Salesforce applies the same split: Salesforce keeps the service available, patched, and secure at the platform layer, and you are responsible for the data and configuration you create inside it.
In practice, that means Salesforce will keep the lights on, defend the infrastructure, and maintain the platform's own resilience. It does not mean Salesforce keeps a private, restorable copy of your records that you can roll back to after a bad import or an accidental mass delete. The responsibility for having a clean, recoverable copy of your own data sits with you.
What does Salesforce protect, and what do you own?
The clearest way to see the model is side by side. Salesforce owns the platform. You own what lives on it.
Read the right-hand column again. Uptime is not the same as backup.
Salesforce can keep the service running perfectly and still have no way to give you back the 40,000 records a bad integration overwrote last night, because those records are yours to protect. Platform disaster recovery restores Salesforce; it does not restore your mistakes.
Does Salesforce back up your data for you?
Not in the way most people expect. Salesforce protects the platform and maintains its own infrastructure-level resilience, but it does not keep an on-demand, restorable backup of your individual org's data that you can call on after a data-loss event.
The clearest signal of this came from Salesforce itself. Salesforce retired its paid Data Recovery service, a last-resort option that took six to eight weeks and cost a flat $10,000, and pointed customers toward backing up their own data with a dedicated backup solution.
Salesforce does provide some native tools that people mistake for backup: the weekly data export, the Recycle Bin, and field history tracking. None of them is a true backup and recovery system:
- Weekly or manual data export produces a set of CSV files. It captures data, not the relationships and metadata needed to restore cleanly, and it runs on a limited schedule. Rebuilding an org from raw CSVs by hand is slow and error-prone.
- The Recycle Bin holds deleted records for 15 days by default, then Salesforce schedules them for permanent deletion. It is a short grace period, not a backup.
- Field history tracking logs changes to a limited number of fields (up to 20 per object) for a limited time. It is an audit trail, not a restore point.
If you need to recover a specific state of your data from before an incident, none of these gets you there on its own. A real restore has to be quick and keep relationships intact.
What can go wrong with Salesforce data?
Platform outages are rarely the thing that loses your data. The common causes are ordinary and internal, which is why the shared responsibility model puts them on you.
- Accidental deletion. A user mass-deletes the wrong list view, an admin runs a delete on the wrong filter, or a merge collapses records that should have stayed separate. Once the Recycle Bin window passes, that data is gone.
- Bad deployments. A release overwrites field values, changes a picklist, or pushes a flawed automation that corrupts records the moment it activates. The deploy succeeded; the data did not survive it.
- Integration and API errors. A misconfigured sync, a duplicate job, or an ETL tool writing to the wrong field can overwrite or wipe thousands of records in minutes, faster than anyone notices.
- Rogue or careless automation. A trigger, flow, or batch job with a logic error updates records at scale before anyone catches it.
- Departing users and insider mistakes. Someone with broad access exports, alters, or deletes data on the way out, or makes a large, well-intentioned change that turns out to be wrong.
Every one of these sits on the customer side of the line. Salesforce keeping the platform healthy does nothing to reverse them. What reverses them is your own backup, and a fast, reliable way to restore from it.
Why do you need a real backup and recovery solution?
Because "export a CSV once a week" is not a recovery plan, and the Recycle Bin is not a safety net. The shared responsibility model makes recovery your obligation, so you need a system built to meet it: automated, frequent backups of both data and metadata, and the ability to restore a known-good state quickly and with relationships intact.
This is the functional gap Flosum Backup & Archive is built to close. It provides automated backup of your Salesforce data and metadata, granular, fast recovery so you can restore what was lost without rebuilding the whole org, and long-term retention and archiving for records you need to keep but not keep live. It gives you the recoverable copy the shared responsibility model says you are responsible for having.
Recovery is also a compliance requirement, not just an operational one. Regulated teams have to prove they can restore data and demonstrate controls over it.
For how backup and recovery fit into audit and controls obligations, see SOX compliance for Salesforce. For the full picture of protecting a Salesforce org, start with our Salesforce backup and recovery guide.
Ready to cover your side of the model? See how Flosum Backup & Archive backs up and restores your own org's data and metadata. Book a demo.
FAQs
Thank you for subscribing
