SaaS Backup Beyond Microsoft 365: The 2026 Gap

The SaaS backup blind spot isn't just Microsoft 365 anymore

Most 2026 coverage of SaaS backup still treats Microsoft 365 as the whole problem. It isn't. A 2026 secondary-citation snapshot compiled from MSP360, Kaseya and Analytics Insight data puts SaaS data loss at 70% of businesses using SaaS apps, with 74% of those businesses lacking offsite protection for that data — the same survey moment reported two ways, not two separate findings. That statistic covers SaaS broadly: CRM, identity, project tracking, collaboration — not just email and file storage.

For UK organisations, the practical risk is that budget, tooling and policy attention have followed the M365 headlines while the estate has quietly grown around it. Every new SaaS subscription — Salesforce, Entra ID, Jira, Confluence — extends the same shared-responsibility boundary into a system nobody has explicitly assigned backup ownership for. If your organisation is still mapping which SaaS apps it even runs, it's worth first working through how to address the challenge of SaaS sprawl before deciding what to protect.

The shared responsibility model, properly explained

TechTarget's 2026 breakdown of the SaaS shared responsibility model is the cleanest statement of the boundary: the provider is responsible for uptime and infrastructure security; the customer is responsible for data protection, backup, recovery testing, retention and compliance. That split is identical whether the app is Microsoft 365, Salesforce, Entra ID or Jira — only the vendor name changes, not the division of duty.

A 2026 enterprise backup guide from Cloudsfer names the persistent failure mode directly: organisations assume the SaaS platform itself provides full data protection. It doesn't, by design — the vendor's uptime SLA protects the service, not your records inside it. Cloudsfer's recommendation is to store and recover data outside the source SaaS environment entirely, decoupling backup from the platform whose failure or misconfiguration you're trying to survive. Rewind makes the same point from a different angle: SaaS data resilience requires storage that is independent of, and not controlled by, the SaaS vendor whose data is being protected. If you haven't already, it's worth taking the time to understand why Microsoft 365 backup is essential as the reference case — then apply the identical logic to every other SaaS app on the estate.

Where the 2026 coverage gap actually sits

A 2026 survey circulated via Arcserve gives the clearest evidence that the real exposure has moved past email and files. Backup coverage varies sharply by platform: Microsoft 365 sits at 63.1%, Entra ID at 36.9%, Salesforce at 20.5%, Dynamics at 17.4%, Jira Cloud at 14.4%, and Confluence Cloud at just 9.2%. These are coverage rates for organisations actually backing up each named platform — not market share, not adoption of the app itself, and not a measure of restore success.

Read plainly, that means fewer than one in five organisations surveyed are backing up Salesforce, and barely one in seven are protecting Jira Cloud. Given that Salesforce typically holds pipeline, customer and revenue-critical data, and Entra ID holds the identity fabric that every other SaaS login depends on, the coverage gap sits squarely on the systems where an unrecoverable loss would be hardest to explain to a board or a regulator — not on the systems that get the most vendor blog attention.

• •Microsoft 365: 63.1% backup coverage
• •Entra ID: 36.9% backup coverage
• •Salesforce: 20.5% backup coverage
• •Microsoft Dynamics: 17.4% backup coverage
• •Jira Cloud: 14.4% backup coverage
• •Confluence Cloud: 9.2% backup coverage

Data loss scenarios that native tools genuinely don't cover

A 2026 vendor guide from 2W Tech lists three specific native-tool gaps in Microsoft 365 worth taking seriously as archetypes for the wider SaaS estate. First, native tools do not provide long-term point-in-time backups — you can't reliably wind the tenant back to an arbitrary earlier state. Second, native tools do not protect against ransomware-encrypted files; if data is encrypted in place, the encrypted version is what gets retained. Third, native tools do not fully back up Teams data because Teams data is distributed across multiple underlying services, so no single native mechanism captures it end to end.

Layer the retention detail on top: CyberFortress notes Microsoft 365 deleted items are retained for 30 to 93 days depending on configuration — a purge clock, not a backup guarantee. Once that window closes, or once a ransomware event has already overwritten good data with encrypted data inside the window, native retention offers nothing to restore from.

The same logic maps onto the other platforms in your estate: a Jira project accidentally deleted by a departing admin, a Salesforce integration error that silently overwrites thousands of records, or an Entra ID configuration change that breaks conditional access for every connected app — none of these are covered by a vendor uptime SLA, because uptime was never in question. The data was.

Data and metadata: why Salesforce needs both, not just records

The most commonly missed distinction in SaaS backup conversations is between transactional data and metadata — the configuration layer that makes the data usable. For a system like Salesforce, that means not just accounts, contacts and opportunities, but the custom fields, workflows, validation rules, page layouts and permission sets that define how the business actually operates inside the platform.

Losing records is a data-recovery problem. Losing metadata is a business-logic problem: a corrupted automation rule or a wiped permission set can silently break how deals get approved, how support cases get routed, or who can see what — often without triggering an obvious alarm the way a mass deletion does. A backup strategy that only captures records and ignores configuration will restore the data into a system that no longer behaves the way the business expects. Any SaaS backup evaluation for Salesforce, Jira or Entra ID should explicitly ask whether metadata and configuration are captured and restorable, not just underlying records.

What a modern SaaS backup solution actually needs to do

Rewind's 2026 guidance on SaaS data resilience restates a foundation that still holds: the 3-2-1 rule — three copies of data, across two different media types, with one copy offsite. Applied to SaaS, 'offsite' means outside the SaaS vendor's own infrastructure, so a platform outage, account compromise or vendor-side error can't take out both the live data and the only backup at once.

On top of that baseline, the capabilities worth insisting on are: independent, vendor-decoupled storage; immutable retention so backups can't be altered or deleted by an attacker (or a rogue admin) inside the retention window — you can learn about immutable backups for the underlying mechanics; granular, point-in-time restore rather than an all-or-nothing tenant rollback; and documented, repeatable restore testing, which doubles as audit evidence rather than a one-off IT exercise.

A decision framework for UK buyers

For a UK organisation weighing SaaS backup investment against risk, four questions should structure the decision, and each has a specific 2026 answer:

RTO/RPO: what's your actual recovery point objective if Salesforce or Jira is corrupted this afternoon? Native retention windows like Microsoft 365's 30-93 day deleted-item purge are not an RPO commitment — they're a countdown. Independent, point-in-time backup is what actually lets you define and hit an RPO measured in hours, not 'whatever's still in the recycle bin'.

Compliance and residency: GDPR accountability doesn't disappear because the data lives in a SaaS tenant. UK organisations should require UK/EU data residency options, role-based admin control over the backup itself, and documented restore-test evidence as tender requirements — not nice-to-haves.

Cost: compare the GBP-priced per-user subscription against the operational cost of the data loss it prevents, factoring in staff time, customer impact and regulatory exposure — the downtime cost calculator is a useful starting point for putting a number on the outage side of that comparison.

Scope: does the tool cover only Microsoft 365, or does it extend to Salesforce, Entra ID, Jira and whatever else sits in your SaaS sprawl? If you're specifically comparing M365-focused options, it's worth using a dedicated resource to compare Microsoft 365 backup solutions — but treat that as one procurement decision among several, not the whole SaaS backup strategy.

Closing the gap: what UK IT leaders should actually do

The 70%/74% snapshot and the platform coverage figures point to the same conclusion: the SaaS backup conversation has been anchored on Microsoft 365 while Salesforce, Entra ID and Jira quietly became the least protected, highest-consequence systems in most organisations' estates. Native retention windows and vendor uptime SLAs were never designed to answer 'can we restore this to a known-good point in time' — and 2026's own vendor documentation says so directly.

The fix is not another M365 tool. It's an inventory of every SaaS app that holds business-critical data or configuration, an honest answer to whether it's backed up independently and immutably today, and a tender requirement that any solution — for M365 or otherwise — proves restore testing rather than just backup scheduling.

Sources

Every figure in this article traces to the sources below.

• •CyberFortress — 70%/74% SaaS data loss and offsite protection snapshot, M365 30-93 day retention
• •Rewind — 3-2-1 rule and independent SaaS storage guidance
• •TechTarget — SaaS shared responsibility model definition
• •2W Tech — Microsoft 365 native backup gaps (point-in-time, ransomware, Teams)
• •Cloudsfer — enterprise backup gap and off-platform storage recommendation
• •LinkedIn/Arcserve — 2026 SaaS backup coverage survey by platform