M365 Disaster Recovery: RTO/RPO Runbook

"Microsoft backs it up, right?" That question — usually from a CFO reading a cyber-insurance renewal — is the entry point to almost every enterprise disaster-recovery conversation we walk into. The answer is *partly*. Microsoft protects the platform: hardware, region redundancy, service availability, geographic failover for the underlying infrastructure. Microsoft does not protect *your* data from *you*: an accidental tenant-wide deletion, a ransomware event that hits your admin account, a disgruntled administrator who empties recycle bins, a region-wide outage during a business-critical event, or a compromised tenant that Microsoft's own controls will not roll back. This runbook is what we build with enterprise clients during our SharePoint support engagements. It maps the shared-responsibility model, gives five real DR scenarios with recovery paths, prescribes RTO/RPO by industry, and lays out a four-quarter DR test schedule.

The shared-responsibility model — clarified

Microsoft's service availability documentation describes what Microsoft protects and what remains your obligation. The short version:

| Layer | Microsoft protects | You protect |

|-------|--------------------|--------------|

| Physical infrastructure | Yes | — |

| Region availability, geo-redundancy | Yes | — |

| Service SLA (financial credits) | Yes | — |

| Short-term recycle bin (93 days SharePoint) | Yes | — |

| Retention policies you configured | Yes (as configured) | You must configure |

| eDiscovery holds | Yes (as configured) | You must place |

| Data from admin error, insider action, tenant compromise | No | Yes |

| Long-term retention past retention window | No | Yes |

| Point-in-time restore of a specific site to yesterday | No | Yes (with third-party backup) |

The gap between "Microsoft protects the platform" and "you must protect the data" is where enterprises get injured. The 93-day recycle bin is not a backup. A retention policy is not a backup. eDiscovery is not a backup. Each of these is helpful within its own use case, but none of them protects against the scenarios that keep DR officers awake.

Five real DR scenarios

Every scenario below has happened to enterprises we support. The recovery paths are what we would run today.

Scenario 1: accidental tenant-wide deletion

Description: A global admin runs a PowerShell script intended for a test tenant against production. Three site collections are deleted. Users notice within the hour.

Recovery path:

• Immediately open the SharePoint admin center, navigate to Deleted sites, and restore. Deletion is recoverable for 93 days from the site collection recycle bin.
• If the deletion also removed the Microsoft 365 Group, restore the group from the Entra ID admin center within 30 days (default group soft-delete window).
• Verify permissions, sharing settings, retention labels, and Power Automate flow connections still resolve — restored sites sometimes come back with detached flows.

RTO: 1-4 hours. RPO: near zero (site is restored intact).

Prevention: dual-control for tenant-wide scripts (peer review + break-glass approval), and a policy that no script runs first in production.

Scenario 2: ransomware

Description: A user's OneDrive is infected with ransomware. The encrypted files sync to OneDrive, then propagate to a shared SharePoint library via a synced folder. The library is now encrypted.

Recovery path:

• OneDrive Files Restore recovers a personal OneDrive to a point in time within the last 30 days. Site owners cannot invoke Files Restore for a SharePoint library — the platform equivalent is version history restore, per file, if versioning is enabled.
• If versioning was enabled, restore each affected file to its last clean version. This is manual for hundreds of files and requires a script for thousands.
• If versioning was disabled or the version window was insufficient, restore from third-party backup.
• Disable the compromised account, revoke sessions, force password reset, review sign-in logs, and inspect other sites the account had access to.

RTO: 4-24 hours if backup is available; days if manual per-file restore. RPO: depends on the backup schedule — 24 hours is common for third-party solutions.

Prevention: version history enabled with sufficient cap on all libraries, third-party backup for high-value sites, MFA enforced tenant-wide, conditional access blocking unmanaged devices.

Scenario 3: disgruntled administrator

Description: An administrator with tenant-wide access gives notice, then in the final week deletes content, empties recycle bins, and disables retention policies before leaving.

Recovery path:

• If deletion happened within the recycle bin retention window and the recycle bin has not been emptied, restore from stage 2 (site collection recycle bin).
• If the recycle bin was also emptied, only third-party backup or retention-policy preserved copies can recover the content.
• Retention policies configured in Purview cannot be disabled by a single administrator in a well-governed tenant — they require dual-control or a preservation lock. If a preservation lock was applied, the content is unaffected even if the retention policy was tampered with.

RTO: hours to days depending on backup availability. RPO: backup schedule.

Prevention: privileged access workstations, just-in-time admin elevation via Privileged Identity Management, preservation lock on critical retention policies, alert when admins bulk-empty recycle bins.

Scenario 4: region outage during a critical event

Description: A regional Microsoft 365 outage occurs during the last day of a quarter's close. Finance cannot access SharePoint sites containing working papers. The outage lasts 6 hours.

Recovery path:

• Microsoft does not offer customer-invoked regional failover for SharePoint Online. Recovery is Microsoft's responsibility and is invisible to you.
• During the outage, your users need alternative access to their working papers. This is where a read-only backup mirror in a different region (via a third-party backup product) provides business continuity, not recovery.
• Post-outage, reconcile any changes made in the mirror against the primary tenant.

RTO: Microsoft's regional SLA (see current SLA in your service description). RPO: near zero (Microsoft syncs its own state).

Prevention: business-continuity plan for the outage window (offline copies of critical templates, alternative collaboration path for the moment), do not expect DR product to substitute for the tenant.

Scenario 5: tenant compromise

Description: A tenant is compromised via a phishing attack that compromises a global admin. The attacker exfiltrates data, then encrypts and threatens deletion. The tenant is now hostile.

Recovery path:

• Immediately: disconnect network access, invalidate all sessions, revoke all refresh tokens, reset all admin credentials with new device enrollment, review sign-in logs for the extent of the compromise.
• Restore compromised data from third-party backup, ideally to a separate tenant that was never accessible from the compromised admin. This is the most expensive scenario and the reason enterprises with regulated data invest in immutable, air-gapped backup.
• Engage Microsoft support and CISA / your national CERT.

RTO: days to weeks. RPO: backup schedule.

Prevention: hardware token MFA for all admin accounts, admin accounts separate from user accounts, no admin activity from production user devices, alerting on unusual admin sign-in patterns, tabletop this scenario annually.

RTO/RPO by industry

RTO (Recovery Time Objective) is how long you can tolerate the service being down. RPO (Recovery Point Objective) is how much data you can afford to lose. Enterprises often adopt vendor-provided defaults instead of setting these numbers against their own risk tolerance. Below are realistic targets by industry.

| Industry | RTO (critical systems) | RPO | Notes |

|----------|:----------------------:|:---:|-------|

| Healthcare | 2 hours | 1 hour | Clinical documentation cannot lose more than one hour of chart notes |

| Financial Services | 1 hour | 15 minutes | Regulatory reporting cannot tolerate multi-hour outages |

| Legal | 4 hours | 4 hours | Matter management workflows tolerate a business shift |

| Manufacturing | 4 hours | 24 hours | Non-production systems; SCADA is outside M365 scope |

| Public Sector | 24 hours | 24 hours | Statutory obligations often specify recovery windows |

These are starting points. A trading floor's RTO on order-processing systems is measured in seconds; a public library's RTO on its intranet may be days. Set your own numbers against your own risk register, and defend them in writing.

The four-quarter DR test schedule

A DR runbook that is not tested is fiction. We prescribe a rotating four-quarter test cadence.

Q1 — Tabletop exercise. No systems touched. Convene the DR team, walk through Scenario 1 or Scenario 5 as a discussion, capture gaps in the runbook. Duration: 2 hours. Output: updated runbook.

Q2 — Partial restore test. Restore a single non-production site or list from backup to a test destination. Verify all metadata, versioning, permissions, and retention labels come across correctly. Duration: 4 hours. Output: verified restore procedure.

Q3 — Full restore test. Restore a full site collection from backup to a spare tenant or a designated recovery URL. Time the operation. Compare against target RTO. Duration: full day. Output: RTO measurement, gap report.

Q4 — Business simulation. Take a non-critical site "offline" for a business unit, invoke the DR runbook, restore, hand back, capture the elapsed time and any user-facing impact. Duration: half day. Output: user-facing RTO/RPO measurement.

The rotation matters. Testing only tabletops means procedural gaps are found but technical gaps are not. Testing only restores means the human decision path is untested. The four-quarter rotation touches all layers.

Site-collection deletion and restore

Microsoft's guidance on deleting a site collection covers the platform mechanics. The key point for DR planning: a deleted site collection is recoverable from the SharePoint admin center for 93 days by default. Past that window, only a third-party backup will restore it. Model your recycle-bin retention against your DR RTO and RPO; do not assume the 93-day default is generous enough for your scenarios.

What third-party backup adds — and what it does not

Third-party M365 backup solutions add:

• Point-in-time restore of specific items, sites, mailboxes at a granularity Microsoft does not provide.
• Retention past Microsoft's built-in windows.
• Immutability options that survive tenant compromise.
• Cross-tenant restore (recover to a different tenant).

They do not add:

• Protection against the current, active user session that deletes content — the backup captures the state at the last backup, not this second.
• Regional failover of the M365 service itself.
• Substitute for eDiscovery holds (backup and legal-hold are different tools with different guarantees).

If your organization needs a formal DR posture with defensible RTO/RPO, our SharePoint support team builds these programs — runbook, tests, backup product evaluation, tabletop facilitation, and audit-ready documentation.

What to write down

Your DR runbook is only useful if it exists in writing. Minimum contents:

• Named DR team members with primary and backup contact.
• Each of the five scenarios with a recovery procedure.
• Named tools for each scenario (recycle bin, backup product, admin center path, PowerShell cmdlet).
• RTO and RPO targets per scenario per system.
• Test schedule and results log.
• Escalation path to Microsoft support with premier support contract number if applicable.
• Preservation of the runbook in a location accessible during a tenant outage (paper copy at a secondary site or in a physically separate cloud).

The last bullet is the one most enterprises miss. The runbook stored inside the same M365 tenant it describes is unavailable when the tenant is compromised.

FAQ

Expert help from our SharePoint consultants

Enterprise disaster recovery for Microsoft 365 is a written program, not a product. Our SharePoint consulting team builds the runbook, facilitates the tabletops, tests the restores, and hands your team an audit-ready DR program you can present to the board or the regulator. Reach out via our contact page and we will scope an engagement.