SaaS data protection: keeping people out is not getting data back

SaaS data protection is the set of controls that keep the data in your cloud applications confidential, available and recoverable. Most programmes buy the first two and assume the third comes with them. It does not. Keeping the wrong people out and getting your data back are different jobs, with different controls and opposite failure modes — an access policy that is working perfectly will not return a mailbox somebody emptied on Tuesday. This post separates the two, maps them onto a framework your auditors already recognise, and shows what each layer looks like in Microsoft 365, Google Workspace, Slack and Atlassian Cloud specifically.

What SaaS data protection covers

The term gets used for at least three different things: a security posture (who can reach the data), a privacy position (what you are lawfully allowed to do with it), and a recoverability guarantee (whether you can get it back). All three are legitimate, and conflating them is how organisations end up with a thorough access review, a signed data processing agreement, and no way to restore a Confluence space somebody deleted four months ago.

A useful working definition: SaaS data protection is everything that stands between a normal Tuesday and the permanent loss, exposure or unavailability of data your business runs on. Some of it is the vendor's job. Most of the interesting parts are not.

The two jobs people merge

Job one is prevention and containment. Multi-factor authentication, conditional access, least privilege, device posture, session controls, external sharing restrictions, data loss prevention. These reduce how often something bad reaches your data.

Job two is recoverability. Independent copies, chosen recovery points, granular restore, tested procedures. These reduce what a bad event costs once it happens anyway.

The reason they get merged is that vendors sell them under one banner, and the reason it matters is that job one has no effect on the most common causes of SaaS data loss. An authenticated user deleting the wrong shared drive is not an access-control failure — the access control worked. Ransomware that arrives through a legitimate sync client or a valid API token is not an authentication failure either. In both cases every preventive control does exactly what it was configured to do, and the data is still gone.

Map it onto a framework you already use

If you need to justify a SaaS data protection programme to a board or an auditor, borrow a structure rather than inventing one. NIST's Cybersecurity Framework 2.0 organises everything into six functions: Govern, Identify, Protect, Detect, Respond and Recover. The useful thing about that list, for this argument, is the shape of it — five functions describe knowing about and resisting an incident, and exactly one describes getting the business back. Most SaaS security spending lands in Protect and Detect.

Here is what each function looks like when the asset is SaaS data rather than a server.

Govern

Decide, in writing, who owns the data in each application, how long it must be retained, and how much of it you can afford to lose. That last number — expressed in hours or days, per workload — is the one that makes every later decision straightforward, and the one almost nobody writes down.

Identify

You cannot protect what you have not inventoried, and SaaS inventories rot faster than infrastructure ones because any team lead can create a workspace. At minimum, map which business processes depend on which application, where the data in each actually lives, and what the native recovery ceiling is for each workload. Those ceilings are not obvious: Teams data is scattered across group mailboxes, per-user mailboxes and SharePoint sites rather than sitting in a Teams database, as our Microsoft Teams backup post sets out.

Protect

This is where the vendor genuinely carries weight, and it is worth being fair about it. Microsoft, Google, Slack and Atlassian run infrastructure, encryption, patching and physical security far better than most of their customers could. Your side is the configuration and the identity layer: MFA everywhere, admin role hygiene, external sharing defaults, OAuth application review, offboarding that actually removes access. The split is covered properly in our post on the SaaS shared responsibility model.

Detect

For SaaS data, detection means noticing anomalous data behaviour, not just anomalous logins: mass deletion, bulk file renames or extension changes, a sudden spike in downloads, a permissions change across a whole site. This matters because every native recovery window is a countdown that starts at the deletion, not at the moment somebody notices. Detection does not prevent an attack. What it buys you is the days you need to act while the native windows are still open.

Respond

Know who declares an incident, who can authorise a restore, and how you communicate while a system is unavailable. Also know where your regulatory clocks start — under GDPR a loss of availability is itself a personal data breach, which is why the GDPR backup requirements bite even when nothing was exfiltrated.

Recover

This is the function backup belongs to, and the one your vendor has already made decisions about on your behalf. Every platform ships a native recovery ceiling — a trash window, an admin grace period, a retention rule — and each has a documented point past which the data is gone. Our SaaS backup post indexes those ceilings per workload.

Where SaaS data protection programmes actually fail

Three patterns turn up repeatedly.

Retention gets mistaken for recovery. A retention policy or a legal hold stops data being purged on schedule. Neither gives you a restore, and in several platforms the compliance control explicitly does not extend the recovery window.

Nobody tests a restore. An untested backup is a hypothesis. The first real test should not be during an incident, and "we can see the data in the console" is not a test — restoring a representative item into a usable state is.

The identity layer is unmapped. Licences lapse, accounts are deleted at offboarding, tenants get reorganised. In most SaaS platforms the data's survival is a property of an account, so an identity decision quietly becomes a data-retention decision.

Protection you cannot demonstrate does not count

There is a compliance dimension that changes what "protected" has to mean. GDPR asks for the ability to restore availability and access to personal data in a timely manner, and separately for a process to test and evaluate that ability. NIS2 pushes the same expectation into board-level accountability for in-scope organisations — see our NIS2 backup requirements post for the scope question.

The practical reading is that evidence is part of the control. Restore logs, test records and a documented recovery objective per workload are what turn a defensible position into a demonstrable one. If your only artefact is a vendor's uptime commitment, you have a service level, not a control.

Where to start

Do these three things in order, and most of the rest follows:

1. Write down the maximum tolerable data loss per workload, in hours or days. One line per application.
2. Compare each number to the platform's documented native ceiling. Where the ceiling is shorter than your tolerance, you have a gap that no security control will close.
3. Test one restore this quarter, on the workload that would hurt most, and keep the record.

We help you choose and deploy the right fit for your stack across Microsoft 365, Google Workspace, Slack and Atlassian Cloud, with guided setup and onboarding — you own and run it afterwards. Book a SaaS data protection assessment and we will work through your per-workload tolerances against what each platform actually guarantees.