Industries
Products & Services
Why palmiq?
Partners
Resources
There is an assumption baked into most conversations about Microsoft 365 that is worth surfacing directly, because it is wrong in ways that tend to become expensive. The assumption is that because Microsoft 365 is a cloud platform managed by one of the largest technology companies in the world, the data stored in it is backed up in the way an organization would back up its own on-premise systems.
It is not. And the distinction matters more than most IT teams realize until an incident reveals it.
Microsoft provides an enterprise-grade infrastructure with high availability, geographic redundancy, and service continuity built for uptime. What Microsoft does not provide is a true backup service — one that protects your organization's data from accidental deletion, user error, malicious insider activity, ransomware, or the kind of configuration mistakes that silently corrupt data over time. When any of those things happen, and across the thousands of organizations palmiq has worked with across education, government, and commercial sectors, all of them eventually do — the path to recovery depends entirely on whether your organization understood this distinction before the incident.
This post is about closing that gap.
.png)
Microsoft publishes something called a Shared Responsibility Model. It is not buried in fine print. It is a formal framework that Microsoft uses to define what it is responsible for and what the customer is responsible for. The division is clear: Microsoft is responsible for the infrastructure. The customer is responsible for the data.
That means Microsoft guarantees that the platform will be available and that the underlying servers, storage, and network will perform reliably. It does not guarantee that data deleted by a user, overwritten by a misconfigured workflow, corrupted by ransomware, or lost due to a sync error will be recoverable. That is the customer's responsibility, and satisfying it requires controls that Microsoft's native tools, on their own, are not designed to provide.
Microsoft does retain some deleted data, but with significant limitations that most users and administrators are not fully aware of. In Exchange Online, deleted items move to the Recoverable Items folder, where they are retained for 14 days by default, extendable to 30 days with specific configuration. After that window closes, the data is gone. In SharePoint Online and OneDrive, deleted files go to the site recycle bin, where they are available for 93 days. That sounds reasonable until you realize the deletion may not have been discovered for weeks, or the attacker who deleted the data also cleared the recycle bin as part of their cleanup. In Microsoft Teams, messages and files inherit the retention policies of the underlying SharePoint and Exchange workloads, which means the same limitations apply.
Many organizations configure Microsoft 365 retention policies for compliance purposes and believe those policies are protecting their data the way a backup would. They are not. Retention policies preserve data for compliance and legal hold purposes, which means the data may exist in a state that is not easily recoverable for operational use. Recovering a mailbox or a SharePoint site from a compliance retention hold is a legal process, not an IT recovery process, and it is not designed to be fast, granular, or self-service. An organization that experiences an accidental mass deletion and needs its data back in hours, not days, and at the item level rather than the archive level, will find that retention policies do not solve that problem.
The scenarios that expose the limits of Microsoft's native data protection are predictable. They happen regularly. The fact that they are predictable makes it more frustrating when organizations encounter them for the first time during an actual incident, because that is not when you want to be learning the boundaries of your recovery options.
An administrator running a PowerShell script to clean up stale accounts makes a targeting error and deletes the wrong set of mailboxes. A user accidentally deletes a SharePoint site that contained three years of project documentation. A migration script encounters an error and wipes a file library. In each of these cases, the data may or may not be within Microsoft's retention window. If it is outside that window, Microsoft cannot help. If it is within the window, the recovery process is time-consuming, requires elevated privileges, and may not restore data to its original state with full fidelity.
Microsoft 365 environments are increasingly targeted by ransomware that does not simply encrypt endpoints. Modern ransomware variants understand that organizations sync their data to the cloud through OneDrive and SharePoint, and they exploit that sync relationship to encrypt files and push the encrypted versions to the cloud before defenders can respond. By the time the attack is detected, the cloud copies of the affected files have already been overwritten with encrypted versions. Microsoft's version history for SharePoint and OneDrive can help recover some files, but version history has depth limits, and ransomware that gradually degrades files over time rather than encrypting everything at once can exhaust version history before the attack is detected.
An employee who is about to leave the organization decides to delete their email history, clear their OneDrive, and remove files from shared SharePoint libraries. Or a disgruntled administrator makes targeted deletions that are not discovered until weeks after the employee's departure. In these scenarios, the deletions may fall outside Microsoft's retention windows by the time the organization realizes what happened. Even if they do not, the forensic and operational recovery process without a third-party backup is significantly more complicated than it needs to be.
The Microsoft 365 ecosystem includes hundreds of third-party integrations and applications that connect to Exchange, SharePoint, Teams, and OneDrive through APIs. A misconfigured application with broad permissions can inadvertently modify, overwrite, or delete data at scale. This category of data loss is particularly dangerous because it may not be immediately obvious that the source of the problem is a third-party application, and the damage may accumulate over days or weeks before anyone notices.
Microsoft introduced a native Microsoft 365 Backup product in 2024, and it is a meaningful step toward addressing some of these gaps. For organizations that have not yet implemented any third-party backup solution, it is better than nothing. But understanding what it does and does not cover is important before treating it as a complete solution.
Microsoft 365 Backup covers Exchange Online, SharePoint Online, and OneDrive for Business. It provides point-in-time restore capabilities with restore points going back up to 180 days for SharePoint and OneDrive, and 180 days for Exchange. The restore is faster than Microsoft's legacy compliance-based recovery paths, and it is more operationally accessible for IT teams.
Microsoft 365 Backup does not cover Microsoft Teams conversations natively as a separate workload — Teams data recovery depends on the underlying Exchange and SharePoint protection. It does not cover other M365 workloads like Planner, Forms, Loop components, or the growing set of Copilot-generated content and interactions that organizations are accumulating as AI adoption expands inside the platform. It does not provide granular item-level recovery for all workload types with the same fidelity and speed that a purpose-built third-party backup solution provides. And critically, it does not offer the independent storage layer that security best practices recommend — a backup that lives entirely outside the Microsoft ecosystem and cannot be reached if the Microsoft tenant itself is compromised.
For organizations with stringent compliance obligations — HIPAA, CMMC Level 2, FTC Safeguards, or FERPA for educational institutions — the backup program needs to be auditable, independently stored, and documented in a way that satisfies external assessors. Microsoft 365 Backup does not provide the audit trail, the independent storage, or the compliance documentation framework that these requirements demand.
A complete protection strategy for Microsoft 365 addresses every workload, operates on an independent storage layer outside the Microsoft tenant, provides granular recovery at the item level without requiring administrative escalation, and generates documentation that supports compliance requirements. It runs continuously, not on a schedule that creates gaps between backup windows, and it integrates with the broader security and incident response posture so that a threat detected at the endpoint triggers a review of backup integrity in the same workflow.
Exchange Online mailboxes, calendars, and contacts. SharePoint Online sites and document libraries. OneDrive for Business accounts. Microsoft Teams channels, chats, and associated files. For organizations using additional M365 workloads, the backup strategy needs to explicitly address each one rather than assuming platform-wide coverage from a single backup configuration. This is an area where many third-party backup tools, including Acronis Cyber Protect Cloud's Microsoft 365 backup module, have extended their coverage as Microsoft has expanded the platform's footprint.
Best practice in backup architecture calls for at least one copy of backup data to reside on storage that is completely independent of the production environment. For Microsoft 365, that means backup data stored outside the Microsoft tenant, on infrastructure that cannot be reached through a compromised Microsoft account, a malicious application with delegated permissions, or a ransomware variant that exploits the sync relationship between endpoints and the cloud. This is the principle behind the 3-2-1 backup rule — three copies of data, on two different media, with one copy offsite — applied to cloud workloads.
The operational test of a backup solution is not whether data was captured. It is how fast and how precisely an administrator can recover a specific item — a single email, a single file version, a specific calendar entry, a Teams channel history — without escalating to Microsoft support, without a lengthy compliance hold process, and without restoring an entire mailbox or site to recover one item. A purpose-built Microsoft 365 backup solution makes this possible. Microsoft's native tools, even with the newer Backup product, do not consistently deliver item-level recovery with the speed and granularity that operational recovery scenarios require.
For organizations subject to regulatory frameworks, the backup program needs to produce evidence that assessors and auditors can evaluate. That includes retention logs, recovery test records, access controls on backup data, and documentation of the backup architecture itself. palmiq manages this documentation as part of the Microsoft 365 backup service we provide to clients in the K-12, healthcare-adjacent, and government sectors, where the compliance obligation is not just to have a backup but to demonstrate that it works and that it is managed with appropriate controls.
palmiq deploys and manages Microsoft 365 backup for clients through Acronis Cyber Protect Cloud, which provides coverage across Exchange Online, SharePoint, OneDrive, and Teams, stored in an independent cloud infrastructure outside the Microsoft tenant. The backup runs on a continuous or frequent scheduled cadence depending on the client's recovery point objectives, and recovery is available at the item level without requiring Microsoft support involvement.
The integration with Acronis Cyber Protect Cloud means that the Microsoft 365 backup does not operate in isolation. It is part of the same platform that manages endpoint protection, patch management, and threat detection. When a security event occurs — whether it originates at an endpoint, in email, or within the Microsoft 365 environment directly — the backup status for affected workloads is immediately visible in the same console, and recovery can be initiated without switching platforms or waiting for a separate tool's data to catch up.
For clients in the education sector managing student records, financial data, and communications across Microsoft 365, the question of what happens to that data after an incident is not abstract. E-Rate compliance, state data privacy requirements, and the practical reality of running an organization on a platform that hundreds of users interact with every day all create concrete exposure when the backup strategy is inadequate. palmiq's managed Microsoft 365 backup service ensures that exposure is understood, documented, and addressed — before the incident that would otherwise reveal the gap.
For DoD contractors using Microsoft 365 in environments that require CMMC compliance, the backup requirements are explicit. System backups of organizational data must be conducted, protected, and tested. That is not a recommendation. It is a practice requirement with assessment implications. Managing that requirement through a third-party backup service that provides the documentation, the independent storage, and the recovery testing that CMMC assessors look for is the approach palmiq takes with clients working toward certification.
Most organizations that discover the limits of Microsoft's native data protection do so at the worst possible time: during an incident, when recovery is urgent, and the options available to them are defined by decisions made months or years earlier. The conversation about what Microsoft retains, for how long, and what the organization's actual recovery path looks like is not a technical conversation that lives with the IT team. It is a business continuity conversation that belongs with leadership, because the consequences of getting it wrong — regulatory exposure, operational downtime, data loss, reputational damage — are leadership-level problems.
The starting point is an honest inventory of what the organization stores in Microsoft 365, how critical each workload is to daily operations, and what the recovery time objective is if any part of it becomes unavailable. For most organizations, that exercise surfaces a gap between the recovery they assume they can achieve and the recovery they can actually demonstrate. Closing that gap is what palmiq does.
Microsoft 365 is an exceptional productivity platform. It is not a backup strategy. The organizations that understand that distinction, and act on it before something goes wrong, are the ones that emerge from incidents as functioning businesses rather than cautionary examples.
Is your Microsoft 365 data actually protected — or just stored?
Contact palmiq for a Microsoft 365 protection assessment. We will map every workload you have in the platform, identify what Microsoft retains and what it does not, and show you exactly what it would take to recover your organization's data after an incident — not in theory, but in practice.
