Microsoft 365 and Azure: Why Native Recovery Is Not Backup

European organisations are placing a dangerous amount of faith in the idea that Microsoft 365 and Azure automatically solve every data-protection problem. They do not. The platforms provide formidable availability, security, and infrastructure capabilities, but cloud service resilience is not the same thing as a customer’s independently recoverable backup strategy—a distinction that matters more as ransomware, accidental deletion, compliance scrutiny, and multi-cloud complexity converge.
That is the central warning in a recent Kaseya analysis of Microsoft 365 and Azure backup risk: cloud convenience can turn into cloud complacency when businesses confuse SaaS availability with guaranteed long-term recoverability of their own data.
For European companies that run email, documents, collaboration, line-of-business workloads, and identity-connected applications through Microsoft’s cloud, the issue is not whether Microsoft has redundancy. It plainly does. The issue is whether the organisation can restore the correct data, at the required point in time, with sufficient granularity, after an incident that may have remained undetected for months.
That question has moved beyond routine IT housekeeping. It now belongs in the boardroom, the business continuity plan, the incident response playbook, and—where organisations fall under its scope—the evidence trail for NIS2 cybersecurity risk management.

---

The cloud misconception: availability is not a backup policy​

The appeal of software as a service is obvious. Microsoft 365 removes the burden of operating Exchange servers, SharePoint farms, storage arrays, and much of the underlying infrastructure. Azure similarly offers globally distributed services, managed platforms, regional redundancy options, and a vast range of resilience tooling.
Yet the operational simplicity can obscure an inconvenient fact: customers still own the consequences of lost, corrupted, encrypted, or improperly retained business data.
Microsoft’s own cloud guidance is built around a shared responsibility model. In SaaS scenarios, Microsoft operates the application and underlying infrastructure, while customers retain responsibility for their information and data, access decisions, configurations, and business processes. Microsoft’s guidance for the Essential Eight backup controls puts it plainly: under the shared-responsibility model, customers “always retain responsibility” for information and data. Microsoft Learn
That does not mean Microsoft 365 or Azure are unsafe. It means they should be understood correctly.
A resilient cloud platform protects against many classes of hardware failure and service disruption. A recoverable data-protection architecture protects against a different set of failures, including:

• A user accidentally deleting a folder, mailbox, SharePoint library, or entire site.
• An administrator applying the wrong retention setting, lifecycle rule, or destructive automation.
• An attacker encrypting, deleting, or overwriting files after stealing valid credentials.
• A compromised privileged account purging content or altering recovery settings.
• A synchronisation error spreading incorrect changes across endpoints and cloud repositories.
• A regional incident or customer-initiated failover that leaves recent writes behind.
• A regulatory, legal, or audit requirement to retrieve an older version of a record.

The distinction is particularly important in environments where Microsoft Teams content, SharePoint sites, OneDrive files, Exchange mailboxes, Azure Storage, virtual machines, and third-party SaaS applications together form a single operational dependency chain. A business can remain technically “online” while still being unable to access accurate data.

Why confidence can create the greatest risk​

Kaseya cites an IDG cloud-data survey in which 68% of respondents said they were extremely or very confident that their SaaS provider could restore their data. Kaseya That number should be treated carefully because the underlying survey methodology is not reproduced in the article, but it captures a familiar enterprise assumption: if the service is cloud-hosted, restoration is assumed to be included.
That assumption is not a recovery objective.
A backup policy should answer detailed questions that ordinary cloud confidence does not address:

• What data is protected?
  Not merely “Microsoft 365,” but specific SharePoint sites, OneDrive accounts, Exchange mailboxes, Teams-connected content, Azure workloads, databases, keys, configurations, and logs.
• How frequently are recovery points created?
  A daily backup may be suitable for one workload and unacceptable for another. Some financial, operational, manufacturing, healthcare, or customer-service systems require far tighter recovery point objectives.
• How far back can the organisation restore?
  Thirty days, 93 days, one year, seven years, and indefinitely are radically different answers.
• Can an administrator restore one file without rolling back an entire collaboration space?
  Granularity determines whether recovery is a precise repair or a disruptive last resort.
• Is the backup protected from the same compromised identity or tenant?
  If an attacker can erase production content and backups through the same administrative plane, the organisation may have redundancy without true recovery independence.
• Has recovery actually been tested?
  A completed backup job proves only that data was copied. It does not prove that data can be restored into a usable, consistent, permission-aware state within the business’s required timeframe.

These are not theoretical distinctions. They define whether an organisation can resume work after a bad day—or simply begin a longer, more expensive incident.

---

The recovery-window problem in Microsoft 365​

Microsoft 365 includes useful native recovery features, and IT teams should use them. But useful native features must not be mistaken for an all-purpose, long-term Microsoft 365 backup strategy.

SharePoint and OneDrive recovery have practical limits​

For widespread file deletion, corruption, overwrite, or malware activity, Microsoft allows users and administrators to restore a SharePoint library or OneDrive to a prior state within the previous 30 days. Microsoft’s own guidance notes that this capability can be used to recover a SharePoint document library or OneDrive from a known good state during that window. Microsoft Learn
Thirty days can be extremely valuable. It can also be insufficient.
A library-level point-in-time restoration is inherently blunt. Restoring the entire area to an earlier state may reverse the incident, but it may also reverse legitimate work completed since that selected restore point. For a highly active project site, legal repository, engineering workspace, finance folder, or Teams-connected SharePoint library, that can create a difficult choice between accepting damage and discarding valid recent changes.
Deleted SharePoint sites have a longer native retention period: Microsoft says deleted sites are retained for 93 days before permanent deletion. Microsoft Learn Likewise, a deleted OneDrive can remain recoverable after its initial retention period for up to 93 days in a deleted state, although the administrative process and the specific state of the user account matter. Microsoft Learn
Those retention windows are important safeguards. They are not substitutes for a recovery plan designed around an organisation’s actual detection timeline, compliance needs, and operational dependency.

A breach may be discovered long after the native window closes​

IBM’s 2025 Cost of a Data Breach research reported a global average breach lifecycle of 241 days to identify and contain a breach, including restoring services. IBM That does not mean every incident lasts that long, nor does it mean a company should wait months before restoring data. It does demonstrate why a 30-day rollback facility should not be treated as the only line of defence against sophisticated compromise.
An attacker with access to a tenant may quietly enumerate data, establish persistence, alter privileges, manipulate retention configurations, and exfiltrate information long before triggering a destructive event. Once the damage becomes visible, the organisation may need to restore to a point far earlier than the most recent native recovery window allows.
This is also why incident response and backup strategy cannot be designed separately. The right restore point is not always “yesterday.” It is the last known-good state—one that predates the attacker’s actions, not merely the date on which the business noticed them.

Native retention, versioning, and backup solve different problems​

Microsoft Purview retention policies can preserve copies of modified or deleted SharePoint and OneDrive content for governance purposes, and versioning retains prior versions of files. Microsoft Learn These are important capabilities for records management, legal preservation, collaboration recovery, and compliance controls.
But retention is not automatically a full backup architecture.
Retention settings can be misconfigured. They may not cover every workload. They can impose storage and administrative considerations. They may preserve data in place rather than create an operationally independent restoration copy. And they do not, by themselves, prove that a business can restore a complete service, user workspace, data set, permission model, or application dependency within a defined recovery time objective.
The practical lesson is simple: use retention and versioning, but do not stop there.

---

Microsoft 365 Backup changes the equation—but does not end the design work​

The supplied Kaseya report correctly identifies a historic concern around broad restore operations and limited backup retention. However, Microsoft’s current documentation shows that its paid Microsoft 365 Backup service has evolved, including support for restoring selected files and folders from protected OneDrive accounts and SharePoint sites. Microsoft Learn
That matters because granular recovery is central to reducing disruption. A business that can restore a specific folder or set of files avoids having to overwrite an entire site simply to repair a targeted loss.
Microsoft 365 Backup also provides one year of retention for OneDrive, SharePoint, and Exchange Online, according to Microsoft’s feature overview. Microsoft Learn The platform describes recovery points at 10-minute intervals for the previous two weeks for OneDrive and SharePoint, followed by weekly snapshots through the remainder of the year. Exchange Online is documented with 10-minute recovery points for the previous 52 weeks. Microsoft Learn
These are meaningful improvements over relying only on recycle bins and short rollback windows.

The strength: fast, integrated recovery​

Microsoft 365 Backup has several clear advantages:

• It is integrated into the Microsoft 365 administrative environment.
• It covers SharePoint, OneDrive, and Exchange Online.
• It provides recovery points designed for major operational incidents, including ransomware and accidental deletion.
• It supports recovery to the same location or, in important cases, to a new location for safer validation.
• Microsoft documents selected-content restore for protected OneDrive and SharePoint data. Microsoft Learn
• Microsoft states that backup copies are stored on append-only Azure blobs, preventing the service itself from modifying existing backup copies. Microsoft Learn

For many organisations, that native service may form a strong layer in a modern Microsoft 365 data-protection design.

The risk: one year is not every organisation’s retention requirement​

A one-year recovery horizon can be adequate for incident remediation. It may be insufficient for financial records, regulated research, contractual archives, public-sector material, legal hold scenarios, intellectual property, or long-running investigations.
The same is true of workload coverage. Microsoft 365 Backup is not a universal backup solution for every cloud dependency simply because it protects core Microsoft 365 data. Organisations still need to inventory what is not covered in their recovery plan: Azure resources, Azure configuration, application databases, SaaS-to-SaaS data flows, third-party applications, endpoint data, identity configuration, automation scripts, and critical logs.
A sound design therefore starts with a business impact analysis rather than a product checklist.

---

Azure resilience does not eliminate the need for Azure backup​

Azure’s global infrastructure and redundancy options are among its strongest selling points. But redundancy is not synonymous with data integrity.
Microsoft’s documentation on customer-managed unplanned failover for Azure Storage is unusually direct: an unplanned failover can involve data loss and can introduce file and data inconsistencies. Microsoft Learn This is a consequence of asynchronous replication. If writes in the primary region have not reached the secondary region when a failover occurs, those writes may be permanently lost.
Microsoft also warns that after a customer-managed unplanned failover, the original primary copy is deleted, the secondary becomes the primary, and geo-redundancy must be manually reconfigured. Microsoft Learn
That is not a flaw in Azure’s design. It is an engineering reality of distributed systems and asynchronous replication. Every organisation using geo-redundant storage should understand its recovery point objective: how much recent data can the business tolerate losing during a regional failure?

Failover solves a different problem than backup​

Failover is designed to restore service availability after an outage. Backup is designed to restore data after corruption, deletion, ransomware, operational error, or a bad change.
A failover may preserve availability while faithfully carrying forward corrupted data. It may move the organisation to a secondary region while leaving the root data-quality issue unresolved. It may also leave recent data behind if replication was incomplete.
For Azure workloads, a recovery design should distinguish among:

• High availability within a region.
• Disaster recovery across regions.
• Point-in-time data recovery.
• Long-term retention.
• Immutable or append-only backup protection.
• Configuration recovery for infrastructure-as-code, policy, network, identity, and application settings.
• Operational restoration testing.

An Azure virtual machine can be available while an attached database is corrupted. A storage account can fail over successfully while the organisation loses its most recent writes. An application can be redeployed while critical secrets, certificates, configuration values, or audit logs are missing. Cloud resilience must be assessed as an end-to-end service, not as a checkbox beside individual Azure resources.

---

The threat landscape makes “assume breach” the sensible posture​

The cloud-data recovery conversation is becoming more urgent because attackers are increasingly comfortable operating in cloud environments. Microsoft’s 2025 Digital Defense Report says destructive campaigns targeting cloud environments rose 87%, while urging organisations to design for continuity using an assume-breach, Zero Trust mindset. Microsoft Security
Identity remains a central concern. A threat actor does not always need to defeat Azure or Microsoft 365 infrastructure directly. Compromised credentials, consent abuse, token theft, malicious OAuth applications, overly broad permissions, or a hijacked privileged account can provide enough access to delete content, encrypt synced data, alter sharing, or interfere with recovery processes.
This changes what “backup security” means.
A protected copy should be:

• Logically separated from routine production access where possible.
• Protected by strong administrative role separation.
• Resistant to alteration or deletion.
• Monitored for unusual backup-policy changes and mass deletion events.
• Covered by tested emergency access procedures.
• Accompanied by immutable copies where risk and regulation justify them.
• Auditable through logging, alerting, and periodic proof-of-restore exercises.

The goal is not to make recovery impossible to administer. It is to make it substantially harder for a single compromised identity, device, or tenant-level mistake to destroy both production data and the means of recovering it.

---

NIS2 puts business continuity squarely in scope​

For organisations that fall within the scope of the NIS2 Directive, backup and disaster recovery are not merely good practice. Article 21 identifies business continuity, including backup management, disaster recovery, and crisis management, as part of the cybersecurity risk-management measures that Member States require relevant entities to take. EUR-Lex
NIS2 should not be reduced to a simple requirement to buy backup software. The directive is concerned with risk management, governance, security controls, incident handling, supply-chain security, and continuity. In practical terms, an organisation needs defensible evidence that it understands its risks and has taken proportionate measures to manage them.
For Microsoft 365 and Azure environments, that evidence should include more than a screenshot showing a successful backup status.

What credible evidence looks like​

A stronger NIS2-aligned backup and recovery posture can include:

• Documented ownership for Microsoft 365 and Azure data protection.
• A current data inventory and classification model.
• Defined recovery point objectives and recovery time objectives by workload.
• Backup policies mapped to legal, contractual, and operational retention requirements.
• Named recovery roles, including authority to invoke emergency restoration.
• Audit logs for backup-policy changes, privileged-role changes, and restore operations.
• Periodic recovery tests that document outcomes, exceptions, and remediation work.
• Supplier and MSP service schedules that clearly describe responsibilities.
• Incident response procedures that account for compromised identities and contaminated restore points.

The most important shift is cultural: a successful backup is not an event. A successful recovery is the outcome that matters.

---

MSPs have an opportunity—and a responsibility to define the boundary​

Managed service providers sit at the centre of this issue. Many customers assume that “managed Microsoft 365” includes backups, long-term retention, disaster recovery, and restoration testing. Sometimes it does. Often, the service description is less specific than the customer believes.
That ambiguity is risky for everyone.
An MSP should define, in writing, what it manages and what remains with the customer. The schedule of services should answer questions such as:

• Which Microsoft 365 workloads are protected?
• Which Azure resources are protected?
• What backup frequency and retention period apply?
• Is data restored in place, to a new location, or both?
• Are restores included in the monthly service or billed separately?
• Who authorises a production rollback?
• Is the backup platform independently monitored?
• How often are restore tests performed?
• What is the expected recovery time for a single file, a SharePoint site, a mailbox, or a large-scale ransomware event?
• Which legal or regulatory retention obligations remain the customer’s responsibility?

This is where a strong MSP differentiates itself. Selling licences and enabling backup is straightforward. Demonstrating recovery readiness—with verified jobs, alerting, recovery simulations, documented evidence, and informed business conversations—is far more valuable.

---

Building a practical Microsoft 365 and Azure recovery strategy​

A resilient cloud backup strategy does not need to be needlessly complicated, but it must be intentional.

Start with a recovery inventory​

Identify the systems and data that the organisation cannot afford to lose. This should include not only user documents and email, but also SharePoint intranets, Teams-connected sites, project spaces, Azure databases, storage accounts, application configurations, encryption keys, logs, DevOps assets, and identity-related settings.
Classify each workload by business impact. A low-value collaboration site may tolerate a 24-hour recovery point objective. A production database processing customer orders may not.

Set recovery objectives before selecting tools​

Define the following for every critical service:

• Recovery Point Objective (RPO): the maximum acceptable amount of lost work or data.
• Recovery Time Objective (RTO): the maximum acceptable time to restore service.
• Retention period: how long recovery points must remain available.
• Restore granularity: file, folder, mailbox item, site, account, database, virtual machine, or entire environment.
• Recovery destination: original location, clean-room location, isolated tenant, or alternate region.

These objectives expose gaps quickly. If the organisation needs a six-month clean recovery point but holds only 30 days of rollback history, the gap is measurable rather than theoretical.

Apply the 3-2-1-1-0 principle where appropriate​

The familiar 3-2-1 model remains useful: maintain three copies of data, on two different media types, with one copy off-site. Modern cloud strategies often add two more safeguards:

• 1 immutable or offline copy that cannot be altered by an attacker or routine production credentials.
• 0 unverified recoveries—meaning backup success is not accepted until restoration is tested.

The exact implementation varies. A smaller business may use Microsoft 365 Backup alongside a specialist backup provider and immutable storage. A large enterprise may use separate security domains, backup vaults, cross-region storage, isolated recovery environments, and formal clean-room testing.
The principle remains stable: do not make the survival of business data depend on one platform, one account, one administrator, or one untested assumption.

Test for business usability, not merely technical completion​

A recovery test should prove more than that a file can be downloaded.
Test whether:

• The restored SharePoint site has the expected documents, versions, metadata, and permissions.
• The restored mailbox includes usable mail, contacts, calendars, and attachments.
• Azure applications can reconnect to restored databases and storage.
• Recovery procedures work when a normal administrator account is unavailable.
• Users can resume critical workflows after restoration.
• Logging and audit evidence are available for compliance and post-incident review.
• The process meets the organisation’s stated RTO and RPO.

IBM’s 2025 research specifically recommends regularly testing incident-response plans and backups, defining clear roles, and conducting crisis simulations. IBM That advice is not glamorous, but it is decisive. The organisations that recover well are generally those that rehearsed recovery before it became an emergency.

---

The real cloud risk is not using the cloud—it is assuming the cloud removes responsibility​

Microsoft 365 and Azure remain powerful platforms for European businesses. Their security, availability, redundancy, and native recovery capabilities can form the foundation of a highly resilient technology environment.
But the foundation is not the finished structure.
The operational risk emerges when businesses treat platform availability as a complete data-protection strategy, assume native retention is equivalent to long-term backup, or discover during an incident that their only restore option is too recent, too broad, too slow, or too exposed to the same compromise.
The remedy is not fear of cloud services. It is disciplined ownership: clearly defined recovery objectives, layered backup protection, immutable copies where needed, granular restoration capability, tested procedures, explicit MSP responsibilities, and auditable evidence that the plan works.
In the Microsoft 365 and Azure era, business continuity is no longer about whether the cloud stays online. It is about whether the organisation can recover its own trusted data—accurately, securely, and on its own terms—when the cloud alone is not enough.

---

Update: Additional details (July 28, 2026)​

Microsoft 365 Backup’s granular SharePoint and OneDrive file-and-folder restore capability is described as being in public preview. Its recovery-point cadence for that granular option is roughly daily in the recent recovery period, then weekly further back.
By comparison, full SharePoint site and OneDrive account restores can use 10-minute recovery points for the most recent 14 days, followed by weekly points from day 15 through day 365. That distinction matters for organisations setting recovery-point objectives: file-level recovery may offer less frequent historical points than a full workload rollback.

---

References​

1. Primary source: Kaseya
   Published: 2026-07-27T12:16:27+00:00
   
   

   Microsoft 365 & Azure Backup: Why Cloud Data Recovery Matters

   Microsoft 365 and Azure data is your responsibility. Learn why backup and recovery are essential to protect cloud data from loss, ransomware, and disruption.

   www.kaseya.com
2. Related coverage: learn.microsoft.com
   
   

   How Azure Storage account customer-managed unplanned failover works - Azure Storage | Microsoft Learn

   Azure Storage supports failover for geo-redundant storage accounts to recover from a service endpoint outage. Learn what happens to your storage account and services during a customer-managed unplanned failover to the secondary region if the primary endpoint becomes unavailable.

   learn.microsoft.com