The SaaS shared responsibility model — why Microsoft, Google and Atlassian don't back up your data

Every SaaS contract you've signed contains the same sentence, buried under a heading like "Customer responsibilities". It says, in effect: we keep the service running; you keep your data. Almost nobody reads it. Then something happens — a ransomware attack, a departing admin, a bad automation — and the reading happens all at once, in a meeting called at 22:00.

This post is the summary you should read before that meeting.

What "shared responsibility" actually splits

The shared responsibility model is a way of divvying up who is on the hook for what between a cloud vendor and their customer. In the SaaS world — Microsoft 365, Google Workspace, Slack, Atlassian Cloud — the split lands roughly here:

Your SaaS vendor is responsible for:

• The physical infrastructure and its security
• The platform being available (usually a 99.9% SLA)
• Patching, network defence, protecting other tenants from yours and vice versa
• Basic data durability against their own hardware failing

You are responsible for:

• The data you put in — its accuracy, its lifecycle, its recoverability from your mistakes
• Access control — who can create, edit and delete
• Compliance and retention beyond the vendor's short native windows
• Recovery from ransomware, malicious deletion, and departed users

This is not controversial or hidden. Microsoft's Services Agreement is explicit: "We recommend that you regularly back up Your Content and Data that you store on the Services…". Google says the same. Atlassian says the same. Slack says the same.

The gap that eats companies

Native SaaS retention is designed for the 90% case: someone deletes a file by accident and needs it back the next day. That's a recycle-bin problem, and every vendor solves it well.

The problems the recycle bin does not solve:

• Ransomware waiting out the window. Modern attacks are patient. They encrypt files, sit on the tenant for weeks, and only announce themselves once the 30-day trash window is safely behind them. Your files are still there — locked, unrecoverable, and past their native retention.
• A departing admin. When you deprovision a user, native retention on their content is short — measured in weeks, sometimes days. In practice, terminated staff often trigger their own data-loss event on the way out.
• A wrong automation. A misconfigured Jira workflow can rewrite thousands of issues in an hour. A rogue Power Automate can mail-merge itself into disaster. The changes are all legitimate — every one made by an authorised account. Native retention doesn't roll them back.
• A compliance auditor. GDPR subject-access, NIS2 recovery evidence, ISO 27001's A.12.3 control — all of these expect demonstrable, testable, auditable backup. A 30-day trash bin is not that.

What "your data is your problem" looks like per platform

Microsoft 365 — Retention is per workload, per policy, and quietly capable of not doing what you thought. See our full write-up on Microsoft 365 backup and ransomware recovery. Exchange keeps deleted items for 14 days by default. OneDrive holds files in the recycle bin for 30 days. SharePoint has its own timers. Teams chats are governed by a fourth policy. Ransomware doesn't care about any of them.

Google Workspace — 30 days in trash, then gone. Google is one of the clearest voices in the industry on this: they preserve platform integrity, not your specific data. Our page on Google Workspace backup and recovery walks through the specifics.

Slack — Retention is per-plan, per-channel, and easy to change. Free-tier workspaces lose access to messages older than 90 days. Every plan is one admin toggle away from silent loss. Our Slack backup and compliance page covers what a proper capture looks like.

Atlassian Cloud — A 30-day trash window for Jira and Confluence, plus a manual XML export you can run occasionally. That's it. See Atlassian Cloud backup and recovery for how third-party backup fills that gap.

What closes the gap

An independent, point-in-time backup that lives outside your tenant, with:

• Continuous, incremental capture — not a monthly export you have to remember to run
• Restore to any point in time, not just the last 30 days
• Restore granularity — individual mailboxes, files, channels, issues, pages — not just tenant-wide
• Ransomware anomaly detection so you notice the encryption event when it starts, not after retention lapses
• Audit-grade evidence so your ISO / NIS2 / GDPR conversations become boring

That's the gap we help you close — we help you choose and deploy an independent backup across Microsoft 365, Google Workspace, Slack and Atlassian, and get you onboarded, so the "your data is your problem" line in your SaaS contract stops being a problem. You own and run the solution; we help you pick the right fit and set it up.

The 30-second self-test

Ask your admin one question: "If Bob in accounting deleted every file in our Finance SharePoint site 45 days ago, and nobody noticed until today, what happens next?"

If the answer starts with "we'd have to open a Microsoft ticket and hope…", the shared responsibility line has already caught you. Best to fix that before the ransomware note beats you to it.

---

Want the 30-minute version? Book a free risk assessment — we'll walk your SaaS tenants and tell you exactly where the gaps are. No sales script, no pricing pitch. Just a plain list of what would happen if today went sideways.