Why Microsoft 365 and Google Workspace Still Need Backup

No. Microsoft and Google both say, in writing, that recovering a client's deleted mailbox item or file past a short window is not their job. Exchange Online purges permanently deleted items in 14 days by default. Google Workspace gives admins only an additional 25 days to restore a message after it leaves Trash before it is gone for good.

Who Actually Backs Up Microsoft 365 and Google Workspace Data?

The client does, or you do on their behalf. Microsoft's own services agreement states it plainly: "We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services." That line sits in the same contract every Microsoft 365 tenant agrees to, and it is not a suggestion buried in marketing copy. It is Microsoft telling you, directly, that uptime and backup are two different promises, and only one of them is included.

Most MSPs already know this in theory. In practice, the gap still shows up on invoices and in incident reports.

A 2025 Syncro survey of 152 MSPs looked at exactly this pattern. 60 percent of MSPs now have Microsoft 365 running more than 80 percent of their client base. Yet more than half of them admit their own backup coverage is still incomplete. That gap describes the majority of your stack, not a fringe exception.

How Long Do Native Retention Windows Really Last?

Shorter than most techs assume, and shorter than most clients would accept if you asked them outright. Exchange Online keeps a permanently deleted item in the Recoverable Items Deletions folder for 14 days by default, and an admin can extend that to a maximum of 30 days. Past that ceiling, native recovery is not an option at all, litigation hold aside.

Google Workspace works differently but lands in the same place. A deleted Gmail message sits in the user's Trash for 30 days. After that, an admin has an additional 25 days to pull it back through the Admin Console's restore tool. Once that combined window closes, Google states plainly that it does not store account data past the additional 25-day deletion period. At that point the data is gone, full stop.

Here is the comparison side by side:

Neither window was built to survive a departing employee who deletes a mailbox out of spite, a ransomware actor who empties Trash as a final step, or a gap between when data goes missing and when anyone actually notices. Those are exactly the scenarios that land on your desk, not a vendor's support queue.

Why MSPs Still Treat SaaS Backup as an Afterthought

Because it hides behind platform uptime. Clients see Microsoft 365 or Google Workspace rarely going down and assume "the cloud" means their data is safe by default. You know the difference between availability and recoverability. The problem is that difference rarely gets priced, scoped, or sold as its own line item, so it quietly becomes your liability instead of your client's purchase decision.

The data backs this up from the vendor research side too. A 2025 State of SaaS Backup and Recovery report from Backupify surveyed over 3,000 IT and security professionals. It found that 87 percent had experienced some form of SaaS data loss in the prior 12 months.

Recovery confidence was worse than the loss numbers suggest. Only 14 percent of respondents said they could restore critical SaaS data within minutes. 35 percent said recovery could take days or even weeks instead. On top of that, more than half of respondents said they spend more than two hours a day just managing their existing backup tools, which is technician time you are either billing for or absorbing.

Does Fragmented Tooling Make the Gap Worse?

Yes, and the same Syncro survey measured that too. 40 percent of MSPs named operational complexity and a lack of integrated tools as their top Microsoft 365 management challenge, ahead of cost or client pushback. 28 percent said they only review or update their security baselines after an incident occurs, which means the backup conversation and the security conversation are both happening in reactive mode at the same MSPs.

Stacking a dedicated SaaS backup tool on top of an already fragmented toolkit does not fix either problem by itself. It just adds another login to a stack that is already hard to manage end to end. The more durable fix is picking a service line that handles cloud-to-cloud backup as part of a broader, already-integrated catalog instead of bolting on one more standalone subscription with its own console, its own alerts, and its own renewal date.

What Does This Gap Cost You in Deals and Liability?

Every renewal conversation where a client assumes Microsoft is already backing up their mail is a conversation you are losing margin in, and every incident where native retention has already expired is a conversation about why you did not say something sooner. The Syncro survey puts a number on the first half of that. 29 percent of MSPs reported a client data loss incident that dedicated backup would have prevented. Those are MSPs eating a cost, an apology, or a canceled contract over a gap that a single add-on service line would have closed.

The operational fix is not complicated. It is a sales and packaging problem as much as a technical one.

• Scope cloud-to-cloud backup as its own SKU, separate from endpoint and server backup, so the quote line item matches the actual risk being covered.
• Set retention and recovery point targets per platform, since Exchange Online and Google Workspace do not fail the same way or on the same timeline.

How to Productize Cloud-to-Cloud Backup as a Service Line

Treat it like any other recurring-revenue service: standardized scope, standardized onboarding, and a clear answer to what happens once native retention has already expired. Delivering that consistently also takes technicians who know the recovery side well, and Forge University offers AI-mentored IT and security certification training to build those skills. Pair that with a clear view of where cloud-to-cloud backup sits next to the rest of your toolset using Stack Builder, so you are not stacking another overlapping tool on top of the ones you already pay for.

The underlying economics favor you here. Clients already pay a monthly seat price for Microsoft 365 or Google Workspace and already assume their data is protected. Closing that assumption gap with a priced, white-labeled backup service is a smaller sales lift than most new offerings, because the need is already proven in their own daily use of the platform. It also sits on top of a renewal cycle you already own, instead of requiring a new sales motion built from scratch.

Write the service down the same way you would any other managed service. Define what counts as a restorable object, which platforms are in scope at launch, what the recovery point target is per platform, and who gets notified when a restore request comes in outside business hours. Clients will not know to ask for this level of detail, which is exactly why putting it in the statement of work protects you as much as it protects them.

Where This Fits Next to the Rest of Your BCDR Stack

Cloud-to-cloud backup is not a replacement for server, endpoint, or immutable storage strategy. It is a distinct layer that protects data living entirely inside a SaaS platform whose infrastructure you do not control, which is a different failure mode than a ransomware attack on a physical or virtual server. Selling it separately, rather than assuming it is bundled into whatever backup platform you already resell, is the operational trend worth acting on before the next client finds out the hard way that 14 days was all they had. Browsing the full catalog of products is the fastest way to see how a cloud-to-cloud backup line item sits next to the other white-labeled tools built for this kind of coverage gap.

See the full stack of white-labeled tools Actiforge offers MSPs closing gaps like this one.