The Shared Responsibility Gap in SaaS Security

We’ve talked to scores of IT teams right after they discovered a gap in their SaaS backup assumptions. The first thing they say is almost always the same: “We honestly thought the SaaS provider had this covered.”

It’s a completely understandable belief. SaaS providers lead with impressive uptime guarantees—99.9% to 99.99% availability—backed by infrastructure resilience that sounds a lot like “we’ve got your data, no matter what.”

But those guarantees measure platform availability, not application-level data recoverability.

The confusion isn’t a knowledge problem. It’s a communication gap that’s been building since organizations started moving to SaaS, and it’s leaving smart teams exposed in ways they don’t realize until it’s too late.

How Uptime Guarantees Create False Confidence

The shared responsibility model exists in every SaaS provider’s documentation. The diagrams are accurate. The boundaries are clear on paper: providers handle infrastructure and platform security, customers handle application data, access controls, and configuration.

But the abstraction fails in the gap between the diagram and the story told over it.

In workshops and onboarding sessions, the surrounding narrative leans heavily on uptime, availability, and built-in protections. Attendees walk away feeling like the provider effectively “has their back” end-to-end, even though no one explicitly said that.

The formal shared responsibility diagrams rarely say in plain language: “If a user, integration, or attacker deletes or corrupts your application data, we will not restore it for you. You must have your own backups and recovery.”

Research confirms this gap. According to the 2024 State of SaaS Data and Recovery report, 79% of IT professionals mistakenly believed that SaaS applications include backup and recovery capabilities by default. Another study found that 60% of companies still believe their SaaS providers are responsible for data protection, when providers explicitly state that application-level data protection is the customer’s responsibility.

Years of “move to SaaS, reduce complexity” messaging created a default mental model of risk outsourcing. When people see a complex diagram, they compress it to the simpler story they already believe: the SaaS provider handles the hard reliability stuff.

That shortcut means the same diagram meant to clarify boundaries ends up reinforcing a wrong belief: that application-level rollback after mistakes or ransomware is implicitly part of what “secure and highly available SaaS” guarantees.

The Moment Teams Discover the Gap

For most teams, the shift from “we’re fine” to “we’re not fine” happens in hours, not days.

But it takes getting all the way to the restore step in a drill or simulation for the realization to hit.

In structured exercises, teams feel confident for the first 30 to 60 minutes. Backup jobs show as successful, snapshots exist, dashboards look healthy. Then they spend the next several hours fighting API rate limits, partial restores, missing data, and manual steps.

That’s when they realize their assumed RTO was fantasy.

The numbers tell the story. According to Spanning’s 2025 State of SaaS Backup and Recovery Report, more than 60% of organizations believe they can recover from a downtime event within hours, while only 35% actually meet that target in practice. The “oh, we’re not fine” moment usually lands within a single working day of real testing.

Lightweight checks—seeing backup jobs succeed, spot-restoring a single file—rarely expose the gap. It takes a scenario that mimics real blast radius to surface the operational drag: multiple users, shared data, permissions, time windows.

The Semantic Gap Between Marketing and Reality

The part that really shocks teams isn’t the technical friction. It’s the semantic gap between what they thought “restore” meant and what the platform actually does.

Teams expect “restore this workflow to how it looked at 9:12 AM.” They discover the tooling really means “bulk rehydrate these objects, in these scopes, to approximately this point,” often losing context, permissions, or recent legitimate work.

That mismatch shows up as partial restores, missing shared items, or restores to alternate locations users can’t find. Technically “successful,” but operationally far from what the business assumed recovery would look like.

API rate limits, throttling, and coarse restore primitives turn what leaders imagined as a quick, surgical operation into hours of batched, manual work. Complex data relationships—cross-team shares, third-party integrations, nested permissions—mean that even when the data comes back, rebuilding a coherent, working state often requires human triage and re-wiring on top.

The first wall teams hit is usually technical. But the deeper “we’re not fine” moment comes when they realize: even if the tech were faster, the current model of restore can’t actually give them the precise, business-level rollback they thought they were buying.

When IT Becomes a Business Conversation

Once an organization sees that “restore” doesn’t mean “put my workflow back the way it was,” the conversation almost never stays inside IT.

It very quickly becomes a business and risk conversation, because the gap is about outcomes, not just tooling.

The immediate reaction in IT is usually: “We can get the data back, but not the workflow the business thinks it’s buying.” That reframes the issue from “our backup product” to “our entire recovery model is mis-specified.”

Engineers start talking in terms of Recovery Time Actual and Recovery Point Actual for specific business processes, not just global RTO/RPO numbers. Those questions naturally invite stakeholders they cannot answer alone.

As soon as IT shows that a “successful” restore still leaves finance closing late, sales working from stale data, or compliance unable to reconstruct records, owners from those domains realize their risk assumptions were wrong.

That’s typically when CISOs, CIOs, and sometimes legal and compliance step in. The gap is now about missed SLAs, regulatory exposure, and revenue impact, not just API limits or script complexity.

The Reality of SaaS Data Loss

The threat is not theoretical. According to the 2025 State of SaaS Backup and Recovery Report, 87% of IT professionals reported experiencing SaaS data loss in 2024. The leading causes paint a clear picture of where the gaps lie:

Malicious deletion tops the list, with more than 50% of organizations suffering data loss from this cause—29% impacted by external threats and 27% by insider actions.

Accidental deletion accounts for approximately 20% of data loss events, highlighting the human element that no amount of infrastructure security can prevent.

Third-party integration risks are growing, with SaaS applications serving as the attack vector for 61% of ransomware breaches. The average organization now uses 490 SaaS applications, but only 229 are officially authorized—leaving 261 apps on average outside security oversight.

The financial impact is severe. The global average cost of a data breach reached $4.88 million in 2024, with healthcare organizations facing the highest costs at $9.77 million per breach. For organizations experiencing prolonged data loss lasting 10 days or more, 93% go bankrupt within the following year.

How Compliance Accelerates Discovery

Compliance-driven discoveries feel different from drill- or incident-driven ones. They create formal urgency instead of emotional urgency.

A regulator or auditor has effectively put a date and a paper trail on the gap, which makes it much harder to ignore or “manage by hope.”

Frameworks like GDPR, HIPAA, and industry standards tie data availability and recoverability directly to legal and contractual obligations. A backup/recovery shortfall is immediately framed as a compliance risk, not just an IT weakness.

Audits demand evidence: tested RTO/RPO, logs, documented drills. Once a gap is on record, leadership knows it may be re-examined in the next cycle or by customers, which raises the cost of inaction.

Because findings appear in official reports and questionnaires, they pull in CISOs, legal, compliance, and sometimes the board much faster than a quiet failed drill would. Funding conversations shift from “nice to have” to “we need this to stay compliant and close open findings.”

The downside is that compliance can drive a minimum-viable fix mindset: “enough to pass the next audit.” The strongest programs use audits as an early warning, then push beyond checkbox remediation toward recovery as a first-class design goal.

The Current State of SaaS Backup Preparedness

Despite the clear risks, organizational preparedness remains surprisingly inadequate:

Only 40% of IT professionals expressed confidence that their backup and recovery solution can protect critical digital assets sufficiently in a disaster.

45% of organizations surveyed still do not have a formal backup or recovery strategy for their SaaS applications.

Backup coverage varies widely by platform:

Microsoft 365: 70% have a backup strategy in place
Google Workspace: 66% report having a backup plan
Salesforce: Only 53% have a dedicated backup strategy

Outdated solutions compound the problem—over 28% of respondents indicated their backup systems haven’t evolved in five years, leaving them ill-equipped to handle modern threats.

The recovery time gap is perhaps most concerning: 90% of respondents are unable to recover encrypted SaaS data within an hour, and only 14% of IT leaders feel confident they can recover critical SaaS data within minutes following an incident.

From Static Documents to Operational Practice

The clearest signal that an organization has made the shift is when recovery stops being a static document and becomes a measured, recurring operational practice with owners, SLOs, and drills on the same footing as uptime and security incidents.

You see scheduled, realistic recovery exercises on the calendar, with RTO/RPO measured as Recovery Time Actual and Recovery Point Actual for specific services, and those numbers tracked over time.

Findings from those drills feed directly into backlogs and architecture work. Runbooks, automation, tooling, and even SaaS selection criteria get updated based on what actually happened under pressure, not what the policy said should happen.

Recovery SLOs show up in dashboards and leadership reviews alongside availability and security KPIs. Missing them triggers the same level of scrutiny as missing uptime targets.

Product, security, and IT architects design new SaaS workflows with recovery in mind from the start—asking how they will be detected, contained, and restored—rather than bolting backup on at the end to satisfy an audit checkbox.

What Different Looks Like in Practice

On their worst days, organizations that treat recovery as part of the live control loop still have an incident. But it looks like a short, contained disruption with a clear playbook, not an open-ended crisis that takes over the company.

The biggest difference in practice is that time and scope are under control. They know quickly what happened, what’s impacted, and when they’ll be back to a clean state.

In the old model, detection is slow and noisy. Ransomware or a bad integration has hours to encrypt or corrupt data across many users and apps before anyone is sure what’s happening. Recovery is manual and linear. Teams fight API limits, piece together what’s missing, and lose hours—sometimes days—reconstructing workflows that should have taken minutes to restore.

In the new model, detection is fast because monitoring is continuous. Automated alerts trigger when unusual deletion patterns appear, when external sharing spikes, or when API access patterns change. Recovery is parallel and tested. The team already knows which applications are critical, what their RTO/RPO targets are, and exactly how to restore them because they’ve practiced it quarterly.

The difference shows up in metrics: hours become minutes, days become hours, and “we’re still assessing the damage” becomes “we’re already restoring to the last known good state.”

Moving Forward

The shared responsibility model in SaaS isn’t going away.

The Path Forward

The shared responsibility gap isn’t a failure. It’s a natural growing pain in SaaS adoption that we can solve together. As organizations continue to adopt SaaS applications—with the average company now using between 106 and 490 applications depending on size—the gap between what IT teams assume and what’s actually protected will only grow if left unaddressed.

The confusion stems from how quickly organizations moved to SaaS, combined with provider messaging that emphasizes infrastructure reliability without clearly distinguishing it from data recoverability.

But the market is evolving. Organizations face 1,925 cyberattacks per week on average, a 47% increase since 2024. Ransomware incidents surged 126% in Q1 2025 alone. The pressure is forcing organizations to confront the gap earlier.

The good news is that protecting SaaS applications is a top IT priority for more than 40% of organizations, with another 45% reporting it’s in their top five priorities. The market is consolidating around unified platforms that eliminate the guesswork by delivering both visibility and recovery under clear, testable SLAs.

Recovery is becoming a primary reliability metric, not an afterthought. Organizations are building the operational muscle memory that treats recovery with the same rigor they apply to uptime.

The shift from “we thought the SaaS provider had this covered” to “we measure how reversible our worst days are” is underway.

The path forward requires:

Clear communication about what SaaS providers do and don’t protect Regular testing of backup and recovery processes, not just backup creation Business-aligned RTO/RPO targets that reflect actual operational needs Investment in third-party backup solutions designed specifically for SaaS applications Continuous monitoring of data sharing, access patterns, and integration risks Training and awareness to reduce accidental deletion and improve security posture

Organizations that wait until a data loss event to discover these gaps face recovery times measured in hours or days, costs measured in millions of dollars, and in the most severe cases, existential threats to the business itself.

Those that treat SaaS data protection as a first-class operational requirement—with the same rigor applied to infrastructure security—transform potential crises into manageable incidents with known recovery paths and minimal business impact.

References and Further Reading

Hacker News. (2025). https://thehackernews.com/2025/01/insights-from-2025-saas-backup-and-recovery-report.html
Cloud Security Alliance. (2025). SaaS Security Survey Report: 2025 Priorities. https://cloudsecurityalliance.org/artifacts/the-annual-saas-security-survey-report-2025-plans-and-priorities
DataNumen. (2025). Data Loss Statistics 2024: 85% of Organizations Affected. https://www.datanumen.com/reports/data-loss-statistics-2024/
Expert Insights. (2025). SaaS Backup & Recovery in 2025: A Deep Dive into Key Stats & Trends. https://expertinsights.com/backup-and-recovery/saas-backup-recovery-2025-stats
Invenio IT. (2025). 15 Data Loss Statistics All Businesses Should Know in 2025. https://invenioit.com/continuity/data-loss-statistics/
Kaseya. (2024). Closing the year strong: SaaS security gaps you can’t carry into 2026. https://www.kaseya.com/blog/saas-security-gaps-you-cant-carry-into-2026/
Obsidian Security. (2025). SaaS Security Shared Responsibility Model: Who’s Responsible for SaaS Security? https://www.obsidiansecurity.com/blog/saas-security-shared-responsibility-model
Rewind. (2024). 2024 State of SaaS Data and Recovery. https://rewind.com/resources/state-of-saas-data-security-2024/
Rewind. (2025). The true cost of SaaS data loss. https://www.rewind.com/blog/cost-of-data-loss/
The Hacker News. (2024). State of SaaS Security Report: Bold Moves Required to Secure SaaS in 2024 and Beyond. https://thehackernews.com/expert-insights/2024/11/state-of-saas-security-report-bold.html
Valence Security. (2024). State of SaaS Security 2024. https://www.valencesecurity.com/lp/2024-state-of-saas-security-report
Keepit. “The Shared Responsibility Model for SaaS Data Security.” https://www.keepit.com/blog/shared-responsibility/
Spin.AI. “Recovery Time Actual in Cloud Office Suites: What SMBs Do Not Expect.” https://spin.ai/blog/recovery-time-actual-in-cloud-office-suites-what-smbs-do-not-expect/
EntreMT. “Cloud Security Shared Responsibility Model 2025.” https://www.entremt.com/cloud-security-shared-responsibility-model-2025/

Share this article

Was this helpful?