When disaster strikes, who controls your SaaS data?

One of the things I've noticed over years of working in the Microsoft ecosystem is how many organizations assume their SaaS data is automatically protected. It's an understandable assumption. These platforms are reliable. The uptime is impressive. But availability and recoverability are different considerations — and that distinction matters a great deal when something goes wrong.

SaaS changed disaster recovery in a fundamental way. In an on-premises model, the organization owns both the application and the data, so the recovery model is relatively unified. In SaaS, the provider runs the service, but the customer still carries the consequences if data is lost, corrupted, or locked. The shared responsibility model makes this explicit: The SaaS provider runs the platform; you're responsible for your data, identities, configurations, and recoverability. This is commonly referred to as the data protection gap.

That gap is wider than most organizations realize. A recent CIO MarketPulse survey found that 37% of organizations still do nothing for SaaS data protection beyond relying on native protections. Nearly half had already suffered a major data loss event. And yet 53% believed they could recover from a major loss within 24 hours, while 11% said it would take a month or might not be possible at all. Confidence and readiness don't always match.

The four Ms of data loss

Most SaaS data loss incidents follow patterns. I've found it useful to frame the most common causes as “the four Ms.”

Malicious attacks. Ransomware, credential abuse, destructive compromise. Attackers increasingly look for and compromise backups because weakening recovery gives them a more effective position when negotiating a ransom. Resilience here requires immutable, logically isolated backup copies. Speed of recovery matters, but so does sequence: In a SaaS incident, you often need to restore identities before data, and permissions before access.

Mistakes by admins. These are among the most common (and most underestimated) causes of data loss. A retention setting changed by accident. A security group deleted. An AI agent given too much authority over live data and not enough guardrails. The blast radius of a single admin action in Microsoft 365 can be surprisingly large. Admins aren't careless; they're under pressure to do more, faster, with less. Mistakes are going to happen. The question is whether your backup can restore not just content, but metadata, object relationships, and identity structures.

Mishaps at your cloud provider. Hyperscalers are highly resilient, but not infallible. Microsoft's Azure Front Door incident in late 2025 was a useful reminder. A valid sequence of configuration changes exposed a latent bug in the data plane, producing cascading impacts across Azure, Microsoft 365, Power Platform, and Entra ID. The provider fixed it, but the takeaway for customers is clear: Availability of the service is not the same as recoverability of your data. You still need an independent path.

Migrations gone bad. Tenant moves, mergers and acquisitions, divestitures, cutovers — these create data risk even when no attack has occurred. If a migration fails halfway through, if data ends up in the wrong environment, or if the wrong content gets transferred in a divestiture, you need a known-good record of the source state. Without one, it's very hard to prove what should have moved, what should have stayed, and whether sensitive data ended up somewhere it shouldn't.

Resilience is backup plus tested recovery

Here's the thing about backup: You only get resilience when you've proved you can actually recover with your backups. A backup that exists in theory but has never been exercised under realistic conditions doesn’t count.

Your testing needs to be scenario-based. That means running through the incidents you're actually likely to face — ransomware, large-scale admin error, provider-side disruption, identity corruption, bulk restore — not just demonstrating that someone can recover a single deleted file. Keepit's Annual Data Report found that nine in 10 enterprise and commercial-size organizations validate bulk recovery at least once a year, which suggests it's already a standard marker of recovery maturity at scale.

Identity recovery is a persistent blind spot. Organizations test identity restores roughly four times less often than productivity data restores. And that difference matters. If Entra ID (Microsoft's cloud identity service) can't be recovered cleanly, access to Microsoft 365 and every other SaaS system federated to it may be unavailable, even when the underlying data is intact. Testing has to include identities, object relationships, and cross-tenant restore scenarios, not just files and mailboxes.

How often you test matters, but cadence alone doesn't define readiness. You can test monthly and still have weak documentation, unclear ownership, or blind spots around control-plane recovery. The real measure is whether the organization can restore the right data, in the right order, in a realistic scenario.

Sovereignty has to be part of the design, not an afterthought

The conversation around data governance and sovereignty has shifted considerably. It's no longer just a question of where data physically sits in a data center; it's about which laws apply to the data, who can compel access to it, which providers and sub-processors sit in the dependency chain, and whether or not your backup is genuinely independent of your production environment.

If your SaaS provider and your backup provider depend on the same underlying hyperscaler or are under the same legal jurisdiction, you may have redundancy without true independence. Real resilience means your backup data is stored in a vendor-independent infrastructure, accessible even if your primary provider is unavailable, and governed on terms you understand and control.

Shared responsibility says you still own the data risk, while sovereignty says you also own the rules and obligations attached to that data. Together, they determine whether you truly control your SaaS data — in a much broader sense than just knowing where it's stored.

Where to start

Maturity in disaster recovery isn't about achieving perfection. It's about pursuing it and making the next most valuable improvement and building from there. Even small improvements compound to meaningfully reduce risk.

A good starting point: Identify which SaaS data and identity services have to come back first for your business to keep operating. From there, validate that your backup is genuinely independent and immutable. Extend your testing scope beyond files to include identities, metadata, and object relationships. And take a hard look at your sovereignty situation — who controls the infrastructure your backup depends on, and which jurisdictions can assert authority over it.

Want to learn more?