Your SaaS Vendor Is Not Protecting Your Data the Way You Think

Over the last decade enterprises moved their systems of record into SaaS: customers into a CRM, employees into an HR suite, documents and email into a productivity cloud, tickets, contracts, and increasingly the general ledger into someone else's multi-tenant platform. Somewhere in that migration a belief took hold that resilience came with the subscription. The vendor runs data centres in three regions, publishes a 99.9 percent uptime commitment, and holds more security certifications than the internal team ever did. Surely the data is safe.

The service is safe. The data, in the sense that matters to the business, often is not.

The thesis is this. The SaaS shared-responsibility model is the least-read clause in enterprise software. The vendor commits to keeping its platform running. Keeping your records recoverable to a known good state, after something inside your tenant has gone wrong, is in most contracts your problem. That gap has always existed, but it was tolerable when the dominant threat was an outage. It is not tolerable now, because the dominant threat has shifted from the platform going down to the data inside it going bad: ransomware, a sync job that overwrites good records, a compromised admin account, and, newly, an AI agent with write access doing something plausible and wrong. Vendors architect brilliantly for the first kind of failure. The second kind is largely yours.

What Vendors Actually Commit To

Read a major SaaS agreement closely and the commitments sort into two categories that sound similar and are not.

Platform resilience is what the vendor sells. Replicated storage, failover between data centres, infrastructure backups the vendor can use to rebuild its own service after a disaster. The uptime SLA measures this. When a region fails, the vendor restores its platform, and your tenant comes back with it.

Point-in-time recovery of your records is a different thing. It means the ability to take your tenant, or one object within it, back to how it looked at 09:00 last Tuesday, before the bad write. Vendors mostly do not promise this, and where they offer something close, it is narrow, short, and slow.

The retention windows tell the story. In Microsoft 365, SharePoint and OneDrive keep deleted items in the recycle bin for 93 days, and Microsoft's documentation describes a further 14-day window in which support can restore a site from backup. Exchange Online keeps deleted items for 14 days by default, configurable up to 30. In Google Workspace, an administrator can restore a user's Drive or Gmail data for up to 25 days after it is removed from trash, and Google states that after that it cannot be restored even through support, unless a Vault retention policy has preserved it. Those are reasonable designs for a user who deletes a file by mistake. They are not a recovery strategy for a mass corruption discovered six weeks later.

Salesforce offers the clearest example of the vendor's own view. Its Data Recovery Service, the route for restoring data from Salesforce's own backups, was retired in 2020, then reinstated in 2021 after customer pushback. It is priced at ten thousand US dollars per recovery, takes six to eight weeks, and Salesforce itself describes it as a last resort and recommends customers maintain their own backups. Salesforce now also sells a paid backup product. None of this is a criticism of Salesforce, which is being candid. It is the shared-responsibility model stated plainly: the platform's backups exist to protect the platform.

The distinction that decides outcomes is between the vendor restoring its platform and the vendor restoring your tenant. The first happens at vendor scale with vendor priority. The second, when it happens at all, happens one customer at a time.