Somewhere along the way, your business’s most valuable data quietly moved out of the building: the client history lives in a CRM, the books in cloud accounting, the projects in a project platform, the signatures in an e-signature service. Each vendor keeps their service running impressively well — and each carries the same fine print that surprises people about Microsoft 365: they protect the platform; protecting your data from deletion, corruption, sabotage, and your own mistakes is your job. That’s the shared-responsibility model, it’s in nearly every SaaS agreement, and most businesses have never mapped what it means across their whole app stack. Here’s the map.
What SaaS vendors actually protect (and the gaps that remain)
The vendor’s redundancy means a hardware failure on their side loses nothing — your data is replicated across their infrastructure. What that replication doesn’t defend: your side of the keyboard. The mass-delete an employee runs believing it’s a cleanup. The integration or bulk-import that overwrites good records with bad (sync replicating a disaster faithfully). The departing salesperson tidying “their” contacts on the way out. The compromised account doing quiet damage weeks before discovery. Most platforms offer some undelete — a trash can with a 30-to-90-day window — which shares the familiar limits: short against real discovery timelines, painful at scale, and living inside the very account that might be the problem. And the deepest gap: if your subscription lapses, the vendor folds or is acquired, or you’re locked out mid-dispute, the data’s availability follows the relationship, not your needs.
Step one: inventory and triage (you’ve mostly done it)
The SaaS governance list already names every app; add two columns — what data lives here and what losing it would mean — and the classification map does the triage. The apps holding client records, financials, signed documents, and operational history are the protection tier; the lunch-ordering app is not. For each protection-tier app, answer three questions from the vendor’s documentation (or by asking them — it’s the same diligence as question five of vendor selection): what’s their native recovery capability and window, what export options exist, and does a third-party backup tool support them?
Step two: match each app to its realistic protection
SaaS backup isn’t one solution; it’s three patterns, applied per app:
Dedicated backup tools, where they exist. The major platforms — Microsoft 365, Google Workspace, Salesforce, and a growing list of popular business apps — have mature third-party backup products: automatic, frequent, independently stored, restorable at any scale. Where a real tool covers a critical app, use it; this is the gold standard, at a few dollars per user or app per month.
Scheduled exports, where tools don’t reach. The long tail of niche and industry SaaS often has no backup ecosystem — but nearly all offer export (CSV, PDF archives, API pulls). The pattern: a scheduled, owned, verified export — monthly or weekly per the app’s honest RPO — landing somewhere that’s itself backed up. The trap to avoid: the manual export “someone does quarterly” that quietly stopped in March. Exports are a calendar item with an owner and a check, or they’re fiction. Worth knowing the limits, too: an export preserves the data, rarely the configuration and connective tissue — restoring from CSVs is rebuilding, not rolling back. That’s still infinitely better than nothing, and for some apps it’s the honest ceiling.
Accepted risk, written down. Some apps will end up with thin protection — no tool, weak exports. The discipline is making that a decision: documented, revisited annually, and weighed in vendor selection next time — “what’s our backup story for this platform?” belongs in every future evaluation, because the best SaaS backup strategy is partly a purchasing habit.
Step three: fold it into the program you already run
SaaS protection shouldn’t be a parallel universe — it joins the existing discipline: coverage reconciled against the app inventory so new apps don’t slip through · restore tests that occasionally pick a SaaS target (“recover this deleted CRM account to last Tuesday”) · export jobs monitored like backup jobs · retention set deliberately per tier · and one line in the quarterly review: which critical apps are protected, which are accepted-risk, and what changed. An hour a quarter keeps the map true.
The bottom line
Your data followed your software into other people’s clouds; your responsibility for it didn’t. Inventory the apps, triage by what losing each would mean, protect the critical tier with real tools where they exist and owned exports where they don’t, and write down the risks you’re accepting on the rest. The pattern is the same one that saved the Microsoft 365 conversation — applied, finally, to everything else.