Microsoft 365 ransomware recovery: what actually gets your data back

If ransomware has hit your tenant, the fastest honest answer to Microsoft 365 ransomware recovery is this: Microsoft keeps the service running, but getting your data back is your responsibility — and native retention only helps if the loss is recent and small. For a full-tenant encryption event discovered weeks later, the recycle bin will not save you. What does: an independent, point-in-time backup you can restore from at the file, mailbox and site level.

This guide walks through what Microsoft 365 actually protects, where the gaps are per workload, and the order of operations for a real recovery.

What Microsoft 365 covers on its own

Native retention is built for the everyday case — someone deletes a file and needs it back tomorrow:

• Exchange Online — deleted items sit in the Recoverable Items folder for 14 days by default (configurable up to 30).
• OneDrive for Business — the recycle bin holds files for 30 days, then a second-stage bin briefly after.
• SharePoint Online — its own two-stage recycle bin, on its own timers, per site.
• Microsoft Teams — chats and channel messages follow retention policies, not the recycle bins above — a fourth, separate clock.

Four workloads, four different timers. None of them are a backup — retention exists to keep the service lean, not to protect you from a targeted event, which is why Microsoft's own terms put data durability on the customer's side of the line. This split is the SaaS shared responsibility model in practice.

Where native recovery fails after ransomware

Ransomware is designed to beat exactly these windows:

• Dwell time outlasts retention. Modern attacks encrypt quietly and wait. By the time the ransom note appears, the 30-day windows have often already lapsed.
• The changes look legitimate. Encryption runs under a compromised but authorised account, so version history and audit logs record it as normal activity — not something the recycle bin flags.
• Versioning gets exhausted. Attackers overwrite files enough times to push clean versions out of the retained history.
• Scope is tenant-wide. Native tools recover an item or two well. Restoring thousands of files across OneDrive, SharePoint and mailboxes at once is not what they were built for.
• Legal hold and eDiscovery get in the way. Items under hold survive longer, but sifting a clean copy out of a held mailbox during an active incident is a slow, manual process — not a restore button.

How long does Microsoft 365 ransomware recovery actually take?

There's no single number — it depends on what got hit and how it was backed up. Three factors dominate:

• Detection lag. If anomaly detection flagged the encryption event within hours, the clean restore point is easy to find. If it was discovered weeks later during an audit, more work goes into confirming exactly when the data was last trustworthy.
• Blast radius. Restoring one mailbox is a same-day job. Restoring every OneDrive account and every SharePoint site across a mid-size tenant is a bigger, still-boundable operation — but only if the backup captured full-fidelity, item-level snapshots rather than periodic exports.
• Restore path. Side-by-side restores (to a parallel location for review before cutover) take longer than in-place restores, but they let you verify before you overwrite anything live — usually worth the extra time in a ransomware scenario specifically, since you don't want to reintroduce a still-active threat.

What a real recovery looks like

With an independent backup living outside the tenant, recovery becomes a controlled operation rather than a Microsoft support ticket:

1. Identify the clean point in time — the last snapshot before the encryption event began. Anomaly detection (mass file changes, unusual sharing activity, abnormal login patterns) narrows this down instead of leaving you to guess a date.
2. Scope the restore — a single mailbox, a SharePoint site, a Teams channel, or the whole tenant. Most incidents don't need a full-tenant rollback; over-scoping just adds risk and time.
3. Restore in place or side-by-side — bring data back to the original location, or to a parallel one so IT or the business owner can confirm it's correct before cutover.
4. Verify and hand back — confirm integrity (file counts, mailbox item counts, permissions intact), then return access to the affected users.

Granularity matters as much as coverage: recovering one Teams channel deleted 90 days ago is a very different job from rolling back a tenant, and both need to be possible without engaging Microsoft support.

The 30-second self-test

Ask your admin: "If a compromised account encrypted our Finance SharePoint site 45 days ago and we only noticed today, what's our recovery path?" If the answer involves opening a Microsoft ticket and hoping, native retention has already run out.

This is the gap we help you close for Microsoft 365 — we help you choose and deploy an independent solution that gives you continuous point-in-time capture, ransomware anomaly detection, and granular restore across Exchange, OneDrive, SharePoint and Teams, and we guide the setup. You own and run it. See the Microsoft 365 backup and recovery page for specifics.

---

Want to know where your gaps are before an attack finds them? Book a free risk assessment — we'll walk your tenant and map exactly what would be recoverable today, workload by workload.