SaaS disaster recovery plan: the failures backup alone will not fix

A SaaS disaster recovery plan is the document that says what happens when Microsoft 365, Google Workspace, Slack or Atlassian Cloud stops being usable — for any reason, not only an attack. The distinction matters more than it sounds, because most SaaS disasters are not data-loss events. A regional outage, a failed single sign-on, a subscription that lapsed over a holiday, an integration that deleted forty thousand files in nine minutes: in three of those four cases the data is entirely intact and entirely out of reach. A backup answers one of them. The plan has to answer the rest.

This is the all-hazards counterpart to a ransomware disaster recovery plan, which covers the attack case and the RTO/RPO arithmetic in detail. What follows is everything else — the hazards, the dependency almost nobody maps, the commercial clock that quietly doubles as a deletion clock, and how to test any of it without waiting for the real thing.

What counts as a disaster when you do not own the infrastructure

Classic disaster recovery was written for hardware you could walk up to. The disasters were physical — a failed array, a flooded room, a site you had to fail over from — and the answer was a second copy in a second place.

In SaaS, none of the failure modes you plan for are yours. There is no array to fail, no site to flood, no hypervisor to restart. What can fail instead is the set of arrangements that let you reach the data: the vendor's service, your authentication, your entitlement to the tenant, and the trust you have granted to applications and administrators. Those are the four things a SaaS plan has to be about, and only one of them is fixed by having a copy of the files.

The useful reframing is this: on-premises, disasters destroyed data and left access intact. In SaaS, disasters usually destroy access and leave the data intact. That inverts the plan.

The five hazards worth naming explicitly

Write these down as named scenarios, because each one has a different first move and a different owner:

1. Vendor or regional outage. The service is down or degraded and there is nothing to restore — your data is safe on the other side of a door you cannot open. The plan needs a work-around, not a recovery: where the incident bridge runs if Teams or Slack is the incident bridge, how customer commitments get met for a day, who communicates.
2. Identity failure. Single sign-on, the identity provider, or the conditional-access rules break, and every workload becomes unreachable at once. This is the highest-correlation failure in the whole estate, and it is discussed below on its own.
3. Entitlement failure. A subscription lapses, a payment method expires, a reseller relationship ends, an account is suspended. Access degrades on a schedule set by the contract, and after that schedule runs out, so does the data.
4. Mass deletion at machine speed. A misconfigured sync client, a migration script pointed at the wrong tenant, a third-party app with broad OAuth scopes, an offboarding automation that ran a week early. This is the hazard a backup genuinely and completely solves — and it is more common than ransomware.
5. Loss of control over an administrator. A compromised global admin, or a departing one. Anything held inside the tenant is reachable with those credentials, including the retention settings. Anything outside is not.

Only hazard 4 is a backup problem in the ordinary sense. Hazards 3 and 5 are backup problems only if the copy already lives outside the tenant boundary before the event. Hazards 1 and 2 are not backup problems at all — and they are the two that happen most often.

The dependency nobody maps: identity

On a server estate, failures are mostly independent. A storage fault in one system does not touch another. In a SaaS estate, one component sits underneath everything: the identity provider.

If authentication fails — an expired federation certificate, a misapplied conditional-access policy, an outage at the identity provider, a compromised directory — then Microsoft 365, Google Workspace, Slack and Atlassian Cloud all become unavailable simultaneously, along with the admin consoles you would use to fix them. The data is untouched in all four. You simply cannot prove you are you.

Three practical consequences for the plan:

• A break-glass path must exist and must be tested. At least one administrative account per platform that does not depend on the federated identity path, with its credentials stored somewhere that does not itself require that login. Written down, held physically or in a separate vault, and used once a year so you know it still works.
• Your recovery tooling must not share the single point of failure. If the console you would restore from authenticates through the same identity provider that just failed, it is inside the blast radius. This is a question worth asking out loud of anything you deploy.
• Identity belongs in the business impact analysis as a workload. Most impact analyses list Exchange, Drive, Jira. Almost none list "being able to log in", which is the thing all of them depend on.

Your subscription is also a data-retention clock

This is the hazard that surprises people, because it arrives through finance rather than IT, and it is documented in the commercial terms rather than the security ones.

Microsoft publishes the lifecycle plainly for Microsoft 365 for business subscriptions: a subscription moves Active → Expired → Disabled → Deleted. For most offers, Expired lasts 30 days — users carry on working normally and may not notice anything. Disabled lasts a further 90 days, and during it users lose access while admins keep it, specifically so the organisation can retrieve its data. After that the subscription reaches Deleted, and Microsoft is explicit that the customer data is deleted and that buying the same subscription again does not bring it back.

Two details inside that are worth pinning to the wall. If you explicitly delete a subscription rather than letting it lapse, it skips both Expired and Disabled, and Microsoft documents that SharePoint Online content, including OneDrive, is deleted immediately. And if you cancel within the cancellation window, the subscription goes straight to Disabled — data left behind may be deleted after 90 days and, per Microsoft, no later than 180 days after cancellation.

Google's position on cancellation is shorter and firmer: cancelling a Google Workspace subscription deletes users' Workspace data — Gmail, Calendar, Chat and Drive — and it cannot be restored, while the user accounts and organisational structure remain. Google's own advice is to export first. The catch is timing: the admin Data Export tool is documented to become available no earlier than 48 hours after you start it, typically takes about 72 hours, and can take up to 14 days for a large domain. If the decision to leave is made in the same week the billing lapses, the tool that saves you can be slower than the clock you are racing.

So the plan needs one unglamorous line that has nothing to do with security: who is notified when a renewal, payment method or reseller agreement is about to change, and what they check before it does. In practice that means naming the billing owner in the same document as the incident owner.

Restoring is not the same as recovering somewhere else

Here is the question that separates a backup from a disaster recovery capability, and it takes one sentence to ask:

Can you restore your data into a tenant, domain or workspace that is not the one it came from?

Every hazard above except mass deletion ends with the original tenant unavailable, untrusted or gone. If the only restore path writes back into that tenant, the copy is useless in exactly the scenarios you built it for. Restore-in-place handles the file someone deleted on Tuesday. Restore-elsewhere handles the disaster.

Two related capabilities are worth confirming at the same time, because they are what turn a copy into a recovery: whether you can read and search the copy while the source platform is unavailable — an outage is precisely when you need last month's contract — and whether the export format is something a different platform could ingest, which is the difference between owning your data and merely storing it somewhere else. That independence is the same argument the SaaS shared responsibility model makes from the vendor's side: they guarantee the platform, you guarantee your data's continuity.

Testing a SaaS disaster recovery plan without a disaster

Three exercises, each cheap, each testing something the others do not.

The login test. Once a year, deliberately authenticate to each platform's admin console through the break-glass path rather than single sign-on. This takes twenty minutes and it is the single highest-value test in the list, because it exercises the dependency everything else rests on.

The restore-elsewhere test. Recover something real into a location that is not production — a different account, a spare domain, an isolated workspace — and time it with a clock, not a datasheet. Record the wall-clock number, including the part where somebody hunts for the right restore point. Then compare it with the recovery time you wrote down. If the two do not match, change the tooling or change the objective; both are honest answers, and discovering the gap mid-incident is not.

The lights-out walk-through. Ninety minutes around a table, with one rule: the platform in the scenario is unavailable, and so is anything that runs on it. If the contact list lives in Teams, and Teams is the scenario, you have just found the finding. This is also where you check that the notification clocks are owned — for entities in scope, NIS2 sets an early warning at 24 hours and an incident notification at 72 hours, and those run whether or not the restore is going well, as covered in what NIS2 actually expects of SaaS backup.

None of the three needs a budget. They need a date in a calendar and someone willing to be told an uncomfortable answer.

Where to start

If nothing is written down today, the first version fits on one page: the five hazards above as rows, and four columns — who owns it, what the first move is, whether a copy outside the tenant would help, and when it was last tested. The empty cells are the project plan, and they will not be evenly distributed. For most organisations the gaps cluster around identity and around the commercial clock, because those two belong to nobody in particular.

We help you choose the right fit for your stack and deploy it across Microsoft 365, Google Workspace, Slack and Atlassian Cloud, and we guide the setup so the recovery paths in your plan are the ones you actually have. You own and run the platform; our job is making sure it answers the scenarios you have written down, including restoring somewhere other than where the data started.

If you would rather begin from where you actually stand than from a blank page, an assessment is a short, practical review of what you could recover today, from where, and how long it would take.