Ransomware disaster recovery plan for SaaS data

A ransomware disaster recovery plan for SaaS data is a short, specific document that answers five questions before you need them: how long each workload can be down, how much data you can afford to lose, where a clean copy lives that the attacker's credentials cannot reach, who is authorised to declare an incident and start a restore, and which notification clocks start the moment you know. What it is not is a server-recovery runbook with the word "cloud" pasted over the top. In Microsoft 365, Google Workspace, Slack and Atlassian Cloud you do not own the infrastructure, so most of the classic disaster-recovery levers are gone — and the one number everybody assumes they control, the recovery point, is quietly set for you by each platform's native retention window.

This walks through the three numbers the plan is built on, how SaaS changes them, the decisions that have to be made in advance because they are irreversible during an incident, and the regulatory clocks that run in parallel with the restore.

The three numbers a ransomware disaster recovery plan is built on

Contingency planning has a settled vocabulary, and it is worth using precisely. NIST's Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1) defines the terms that matter here:

• Maximum tolerable downtime (MTD) — the total outage the business can absorb for a given process before the impact is unacceptable.
• Recovery time objective (RTO) — "the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD". The guide notes the RTO must normally be shorter than the MTD, because reprocessing the recovered data takes time of its own.
• Recovery point objective (RPO) — "the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage". It is, in the guide's words, a factor of how much data loss the process can tolerate.

Ransomware bends the RPO in a way ordinary outages do not. When a disk fails, the newest copy is the one you want, and the RPO is however long ago it was written. When an attacker encrypts, the newest copy is the damaged one. The recovery point you need sits before the attacker acted — and if they were in the environment for six weeks before pulling the trigger, that is six weeks back. So the planning question is not "how recent is our latest copy" but "how far back can we still reach, and is that further than the attacker's dwell time".

In SaaS, the platform sets your recovery point unless you change it

This is the part that makes a SaaS plan different from a datacentre plan. On your own hardware you choose a backup schedule and the RPO follows from it. In SaaS, if the only copies you have are the ones the vendor keeps for you, your effective RPO is whatever their native window happens to be — a number nobody at your company chose, that differs per workload, and that ordinary user behaviour can shorten.

Workload	What native retention actually gives you
OneDrive & SharePoint	Two recycle-bin stages that share a single 93-day window counted from the original deletion, not 93 days each; plus Files Restore, a 30-day all-or-nothing rollback (the detail here)
Exchange Online	Deleted-item retention defaults to 14 days and an admin can raise it only to 30; a soft-deleted mailbox survives about 30 days (the three clocks)
Gmail & Drive	A 30-day trash plus a ~25-day admin window — but Gmail's counts from the deletion date while Drive's starts when the trash is emptied (why that asymmetry costs you weeks)
Slack	Whatever the workspace retention setting says. Message deletion is permanent, and Free plans roll data off on a fixed window (what is actually kept)
Jira & Confluence Cloud	Deleted projects and spaces get a hard 60 days; deleted Confluence pages have no published expiry; a deleted Bitbucket repository is rebuilt from a clone you already hold (native limits)

Read that table as a list of RPO ceilings and two things follow. First, they are all measured in weeks, which is the same order of magnitude as attacker dwell time — that is uncomfortably close for a number you are betting the business on. Second, they are not stable. A user tidying their Drive trash, an admin emptying a recycle bin during a storage cleanup, or a licence removed at offboarding all shorten the window without anyone deciding to.

A plan that says "we rely on native retention" is therefore not stating an RPO. It is stating that the RPO is unknown and moves. The alternative is an independent copy whose retention you set, held outside the tenant's trust boundary — which is the same conclusion arrived at from the other direction in does cloud backup protect against ransomware.

The decisions that must be made before the incident

During an incident, people improvise, and some improvisations are irreversible. These are the ones worth deciding in writing now, while it is calm:

• Who declares. One named role that can say "this is a ransomware incident" and start the plan, plus a deputy. Ambiguity here costs hours at the point where hours are the whole game.
• Standing authority to contain. Revoking sessions and app tokens, disabling an identity, and pausing the desktop sync clients are containment actions that stop damage propagating into the cloud. If they need a meeting to authorise, they will happen late.
• Nobody empties anything. Recycle bins, trash, and "let's clean up the mess" deletions during triage destroy the exact recovery material you are about to need. Make it an explicit prohibition with a named exception-holder.
• Offboarding freezes. Removing a licence or deleting an account starts a different, usually shorter, clock on that person's mail and files. Suspend routine offboarding while an incident is open.
• Retention changes freeze. Shortening a retention policy mid-incident is unrecoverable. So is deleting a Slack channel, which bypasses workspace retention entirely.
• Restore order. Which three workloads come back first, and who signs off that a restore point is clean before it is written over live data. Restoring the encrypted version on top of a good one is a real and common way to make an incident worse.

None of that requires tooling. It requires having had the argument in advance.

The clocks that run beside the restore

The technical recovery is not the only thing on a deadline, and the reporting timers are shorter than most restores.

For entities in scope of NIS2, Article 21(2)(c) puts "business continuity, such as backup management and disaster recovery, and crisis management" squarely among the required risk-management measures — the plan itself is the control. Article 23(4) then sets the reporting cadence: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours including an initial severity and impact assessment and any indicators of compromise, an intermediate report if the authority asks, and a final report within one month of that notification. We covered the scope and evidence questions in what NIS2 actually expects of SaaS backup.

Under GDPR, a ransomware event that only encrypts — with no data taken — is still a personal-data breach, because losing availability counts as one. That starts the Article 33 notification assessment on its own 72-hour footing, independently of NIS2 (the detail).

The practical consequence for the plan: somebody has to be producing a factual timeline while somebody else restores. If the same person is doing both, one of them is not happening. Write the two tracks down separately, with names against each.

Seven steps, adapted for SaaS

NIST's seven-step contingency planning process holds up well here; only the content changes.

1. Policy. A short statement that says who owns recovery planning and that it covers SaaS workloads explicitly — most policies were written when everything was on a server.
2. Business impact analysis. Per workload, not per system: what stops if Exchange Online is unavailable for a day, if the Jira project history is gone, if the Slack channel where decisions were made is unreadable. This is where MTD comes from.
3. Preventive controls. Multi-factor authentication, restricting who can delete at scale, app-token review, and anomaly detection so you find out on day one rather than day forty. Detection is not prevention — it shortens the time to knowing, which is what keeps a clean restore point inside your window.
4. Recovery strategies. For each workload: native window, independent copy, or accept the loss. Writing "accept the loss" for something genuinely trivial is a legitimate answer and makes the rest of the plan credible.
5. The plan document. Contact tree, declaration authority, containment steps, restore order, notification owners. Short enough that somebody reads it at 03:00.
6. Testing, training and exercises. See below.
7. Maintenance. Review when you adopt a workload, change plan tier, or change admin structure. A plan that lists workloads you no longer use is a plan nobody has read.

An untested plan is a hypothesis

Two tests, and they measure different things.

A table-top walk-through catches the organisational faults: nobody knows who declares, the contact list is out of date, two people assume the other holds the admin credential. Ninety minutes, once or twice a year.

A real restore catches the technical faults, and it is the one that gets skipped. Restore something real into a separate location, and record the elapsed wall-clock time — not the vendor's throughput figure, your actual time, including the hour spent finding the right restore point. Then compare that number with the RTO you wrote down. The first time you learn how long a full restore of your largest workload takes should not be the day you need it.

If those two numbers do not match, you have a decision to make while it is cheap: change the tooling, or change the RTO. Both are respectable. Discovering the gap during an incident is not.

Where to start

If you have nothing written today, the fastest useful version of this plan is one page with four columns — workload, MTD, RTO, RPO — filled in honestly from the table above, and a fifth column saying which copy you would actually restore from. The empty cells are your project plan.

We help you choose the right fit for your stack, deploy it, and get you protected across Microsoft 365, Google Workspace, Slack and Atlassian Cloud — you own and run the platform, we make sure the setup matches the recovery objectives you have written down. The platform-specific walkthrough for the most common case is how to recover Microsoft 365 from ransomware.

If you would rather start from where you actually stand, an assessment is a short, practical review of what you could recover today, how far back, and how long it would take.