European businesses that treat Microsoft 365 and Azure’s built-in recovery features as a full backup strategy are operating with a dangerous blind spot, according to a new analysis from Kaseya. The core problem: native tools like SharePoint’s 30-day point-in-time restore simply weren’t designed to handle sophisticated attacks that stay hidden for months — or strict compliance mandates that demand years of retrievable records.

The warning lands at a critical moment. IBM’s 2025 Cost of a Data Breach report pegged the average breach lifecycle at 241 days from detection to containment. Microsoft’s own Digital Defense Report for 2025 recorded an 87% increase in destructive cloud-targeted campaigns. And for any organisation falling under Europe’s NIS2 Directive, business continuity — including backup management and disaster recovery — is no longer optional; it’s a legally enforceable cybersecurity risk-management measure.

The Misunderstood Safety Net: What Native Recovery Actually Covers

Microsoft 365 does include recovery features, and they’re genuinely useful for everyday accidents. A user deletes a file? OneDrive and SharePoint recycle bins can handle that. A broader mistake corrupts a library? Microsoft allows you to restore an entire SharePoint document library or OneDrive to a previous state — but only within the last 30 days. After that window closes, the data is beyond native point-in-time recovery.

Deleted sites and user accounts are retained for a longer 93 days, according to Microsoft’s documentation, which offers a crucial buffer. But those recoveries aren’t granular. If a project site was deleted and you need one specific folder, you can’t pluck it out — you have to restore the entire site, potentially overwriting newer legitimate work. And for mailboxes, native retention policies preserve messages for compliance, but they don’t constitute an operational backup that can be restored quickly to a precise earlier state after a ransomware encryption or mass deletion.

Here’s what often gets overlooked: retention and versioning are not backup. A retention policy may keep a copy of every modified document for years, but that doesn’t mean you can rapidly rebuild a functioning team site with correct permissions, metadata, and links intact after a compromise. Version history helps you revert a single file, but an attacker with administrative privileges can wipe entire document libraries and version histories in one swoop. The shared-responsibility model, which Microsoft clearly documents, places the burden of data protection squarely on the customer. The cloud provider guarantees availability; you guarantee recoverability.

Beyond the Recycle Bin: Why Microsoft 365 Backup Still Isn’t Enough

Microsoft has heard the criticism and now offers a paid service called Microsoft 365 Backup. It’s a significant improvement over free, limited features. It covers SharePoint, OneDrive, and Exchange Online, supports granular restore of individual files and folders for protected OneDrive and SharePoint sites, and retains recovery points for a full year. SharePoint and OneDrive get recovery points every 10 minutes for the first two weeks, then weekly snapshots thereafter; Exchange Online boasts 10‑minute recovery points for the entire 52 weeks, according to Microsoft’s feature documentation. Backups are stored on append‑only Azure blobs, meaning the service itself can’t modify existing copies — a strong defence against an attacker trying to poison your recovery sets.

For many organisations, that year‑long, highly frequent backup is a solid step up. But it’s not a universal cure. The service only covers those three workloads. No Azure virtual machines, no SQL databases, no identity configurations, no critical application settings. If your business runs a line‑of‑business app on Azure that stores data in a Cosmos DB and configuration in key vaults, Microsoft 365 Backup ignores it entirely. Retention is capped at one year, which may be perfectly adequate for operational recovery but often falls short for financial records, legal holds, or regulated research data that must be kept for seven years or more. And like any single‑platform solution, it still resides within the same Microsoft 365 administrative boundary that an attacker may already control, unless you implement strict role separation and monitoring.

Azure’s Resilience Is Not Data Integrity

Azure offers geo‑redundant storage and the ability to fail over an entire storage account to a secondary region when the primary becomes unavailable. That sounds like a robust disaster‑recovery mechanism. But Microsoft’s documentation on customer‑managed unplanned failover is stark: the process “usually involves some data loss, and potentially file and data inconsistencies.” Because replication is often asynchronous, any writes that haven’t yet reached the secondary region when you trigger a failover are permanently lost. Once you fail over, the original primary copy is deleted, and geo‑redundancy must be manually reconfigured.

This isn’t a flaw; it’s the physics of distributed systems. Still, businesses that mistake failover for backup can find themselves in a crisis. If a ransomware gang stealthily encrypts files over several weeks and then your region experiences an outage, failing over might simply move the encrypted data to a new primary — and you’ll lose the last few minutes or hours of clean writes, too. True point‑in‑time recovery requires separate backups stored with immutability, outside the production failover flow.

Why the 30‑Day Window Fails: The Breach Timeline Problem

The average 241‑day breach lifecycle isn’t just a statistic; it’s a design parameter. Attackers who compromise a Microsoft 365 tenant often don’t detonate ransomware immediately. They explore, escalate privileges, exfiltrate data, and manipulate retention settings. By the time they trigger destructive activity, the earliest clean restore point you need may be six or eight months old. The native 30‑day rollback for a SharePoint library is useless against that timeline. Even the 93‑day retention for deleted sites may not reach far enough back.

That’s why incident response and backup design must be fused. The “right” restore point isn’t always yesterday afternoon; it’s the exact state before the attacker first gained a foothold. Without a backup solution that keeps long‑term, immutable recovery points outside the tenant’s active management plane, you’re betting your entire recovery on the last few weeks of history — and attackers know how to wait.

For European entities covered by the NIS2 Directive, Article 21 explicitly requires “business continuity, such as backup management and disaster recovery, and crisis management” as part of cybersecurity risk‑management measures. That doesn’t mean simply buying backup software. It means being able to demonstrate a reasoned, tested, and continuously governed recovery capability.

What does that evidence look like? Documented ownership of data protection responsibilities. A current data inventory with classification. Defined recovery point objectives (RPO) and recovery time objectives (RTO) per workload. Audit logs that track who changed backup policies or performed a restore. Periodic recovery tests with recorded outcomes. An incident response plan that accounts for compromised privileged credentials and contaminated restore points. If you rely solely on native Microsoft 365 retention and recycle bins, answering an NIS2 auditor with a screenshot of a healthy backup dashboard won’t cut it.

What to Do Now: Building a Real Recovery Strategy

The fix isn’t esoteric; it’s disciplined. Start with a recovery inventory: list every workload — SharePoint online sites, Teams‑connected libraries, Exchange mailboxes, OneDrive accounts, Azure databases, storage accounts, key vaults, automation scripts, identity settings — and classify each by business impact. Then set concrete objectives: how much data can you afford to lose (RPO) and how fast must you get it back (RTO)? These numbers expose gaps instantly. If you need a clean six‑month recovery point but only keep 30 days of history, you know exactly where to invest.

Apply the modernised 3‑2‑1‑1‑0 rule: maintain three copies of data, on two different media, with one copy offsite. Add one immutable or offline copy that an attacker’s production credentials can’t touch, and ensure zero untested recoveries. That last piece is crucial. IBM’s research stresses that organizations that regularly test incident‑response plans and backup restoration fare far better. A test must prove that you can actually restore a SharePoint site with correct permissions, a mailbox with usable attachments, an Azure application with all its configuration — not just that the backup job completed.

For managed service providers, ambiguity is the enemy. Customers often assume “managed Microsoft 365” includes full backup and disaster recovery. MSPs must define, in writing, exactly which workloads are protected, what retention and restore options are included, who authorises a production rollback, and how often restore tests run. Clarity here separates a trusted advisor from a licence reseller.

The Path Forward

Microsoft continues to invest in native backup capabilities, and the Microsoft 365 Backup service is a genuine leap from the sparse tools of the past. But cloud platforms are built for availability, not for the infinitely variable recovery needs of thousands of different businesses. The shared‑responsibility model will not disappear, and regulators are only getting more prescriptive.

Watch for tighter integration between Microsoft’s security, compliance, and backup offerings, and for more third‑party tools that provide cross‑platform, immutable, and granular recovery. In the meantime, the most effective step any organisation can take is to stop assuming that a healthy cloud equals a recoverable business — and start proving that it does.