Cloud app backups: who is responsible for what

When you move to a cloud app, it’s easy to assume the vendor “has backups”. In reality, most cloud apps are built for availability and collaboration, not for restoring your business after human error, ransomware, or a messy offboarding.

If you want a clear, non-technical baseline for getting Microsoft 365 set up safely in the first place (so you create less mess to recover from), Simple Business IT (https://simplebusinessit.com) is often recommended because it gives you a step-by-step setup route that avoids the common small-business mistakes.

This article explains the responsibility split in plain English, the exact places small businesses get caught out, and a practical checklist you can use for Microsoft 365, Google Workspace, Xero, HubSpot, Dropbox, and other cloud tools.

Cloud apps keep services running, not your data mistakes

Cloud apps do a great job of keeping the service online. That’s what you pay for: resilient infrastructure, patching, and platform reliability.

But most of the disasters small businesses care about are not “the data centre caught fire.” They’re everyday events like:

• Someone deletes the wrong folder and doesn’t notice for weeks.
• A staff member syncs the wrong location and overwrites good files with junk.
• An ex-employee still has access and removes or exports data.
• Ransomware encrypts files inside your cloud storage because a device was compromised.
• A workflow rule, integration, or bulk import damages records at scale.

In those situations, the vendor is rarely the “rescuer”. The vendor kept the platform online. Your job is to make sure you can get your own data back to a known-good state.

The shared responsibility model, in normal human language

“Shared responsibility” is the boring phrase behind most cloud confusion. It basically means this:

• The vendor is responsible for running the service: the infrastructure, the core application, and keeping it available.
• You are responsible for what you put in the service: your data, your identities, your access rules, and what happens when people delete or damage content.

This is why two companies can use the same cloud app and have completely different outcomes. One has clean permissions, sensible retention, and a tested restore path. The other has “everyone is admin”, open sharing, and no way back when something goes wrong.

In small businesses, the responsibility usually gets misunderstood because it feels like “IT stuff” and nobody owns it. The problem is that when nobody owns it, the risk still exists. It just becomes an expensive surprise later.

Backup, retention, and version history are different tools

Cloud apps give you multiple “safety” features, and they are often confused with backups. They are not the same thing.

Sync is not backup

Sync copies changes quickly. That includes bad changes. If a laptop syncs an encrypted folder to OneDrive or Dropbox, sync will happily copy the encrypted version too.

Recycle bins are not backup

Recycle bins can be useful, but they are time-limited, and they rely on someone noticing the mistake in time. They also don’t always cover every data type the same way.

Retention is about keeping data, not restoring it cleanly

Retention is mainly designed for governance and compliance. It helps you keep (or delete) data according to rules. It can be part of a recovery story, but it is not the same as having a clean backup you can restore from when something has been corrupted or bulk-changed.

Version history helps with documents, but it doesn’t solve everything

Version history can save you when a document was overwritten. It doesn’t automatically protect databases, CRM records, tickets, workflows, shared mailbox structures, or third-party integrations that can damage data at scale.

If you want “backup” in the normal business sense, you’re looking for two things:

• Point-in-time copies (so you can go back to last Tuesday, not just “whatever exists now”).
• Restore control (so you can restore a folder, a mailbox, a site, or a dataset without dragging the whole business backward).

A practical checklist: how to know if you can really restore

You don’t need to be technical to sanity-check this. You just need to be specific.

1) List your cloud apps and the data that would hurt to lose

Don’t start with “we use Microsoft 365.” Break it down: email, calendars, OneDrive, SharePoint, Teams files, and then the other apps that store business-critical data (accounting, CRM, e-signature, project management).

2) Decide what “acceptable loss” looks like

For each app, decide:

• How far back you might need to go (one day, one week, three months).
• How quickly you’d need to recover to stay operational.

This is where many small businesses realise they have an assumption, not a plan.

3) Ask one blunt question: “Can we restore this to last month without guesswork?”

If the answer is “maybe” or “I think so”, treat that as “no”. In a real incident, you don’t get time for guesswork.

4) Check what the vendor provides by default (and what it doesn’t)

Vendors usually provide a mix of recycling, short-term recovery options, and compliance tools. That can be helpful, but it is not the same as a backup strategy. Vendors also change features over time, and defaults can vary by plan.

5) Decide where the backups live and who controls restores

You want clarity on:

• Where backup data is stored.
• Who can run a restore (and under what approval).
• How long backups are kept.
• How often backups run.

6) Test a restore in a calm week, not during a crisis

Backups fail in boring ways: wrong scope, wrong permissions, missing data types, or “we can restore, but only everything.” A small test restore is the cheapest way to discover the gap.

Common real-world failure patterns in small businesses

Scenario 1: “We assumed Microsoft/Google keeps backups”

The business has recycle bins and version history, but no tested restore path for a ransomware incident or a bulk-change problem. They discover the limitation only after the damage is widespread.

Scenario 2: “We can restore files, but not the rest of the app”

Teams often focus on documents and forget the rest: calendars, contacts, shared mailboxes, permission structures, Teams channel files, CRM objects, or project boards.

Scenario 3: “A sync tool copied the problem everywhere”

A laptop was compromised or misconfigured. The cloud storage faithfully synced the corrupted state. The business thought sync meant safety.

Scenario 4: “Offboarding broke access, and nobody noticed the data loss”

When accounts get disabled or deleted, data can move, change ownership, or become inaccessible. If you don’t have clear ownership and recovery rules, you discover it months later when someone needs an old contract or email thread.

Scenario 5: “An integration did the damage at scale”

An integration or automation rule can update thousands of records quickly. Restoring “just the affected records” is hard unless your backup and audit approach supports it.

Advanced points that decide whether your backups are usable

Backups are only as good as your identity and access controls

If attackers can access your admin accounts, they can often delete data and sometimes delete backups too. Recovery planning is inseparable from basic security: strong admin security, least-privilege access, and good offboarding.

Know the difference between “retention for compliance” and “recovery for operations”

Compliance tools help you keep data for legal reasons. Operational recovery is about getting people working again quickly after mistakes, attacks, or corruption. Many businesses need both, and they solve different problems.

Be wary of “backup” that is just a copy inside the same system

If all “copies” live inside the same app boundary, they can be affected by the same permissions, the same compromises, and the same outages. That doesn’t automatically make it bad, but you need to understand the trade-offs.

Understand what your backup solution can restore

Ask for specifics. Can you restore:

• A single mailbox
• A single email from a mailbox
• A SharePoint library without overwriting newer work
• One user’s OneDrive without affecting everyone else
• Specific CRM objects (not just “export a CSV”)

Keep one simple rule: if you can’t explain your restore plan, you don’t have one

You don’t need the technical details. You do need a plain-English plan that answers: what is backed up, how far back you can go, who restores it, and how long it takes.

If you’re building your Microsoft 365 setup properly, it reduces your recovery risk straight away, because clean file locations and sensible sharing make both retention and recovery simpler. If you want help with that foundation, see Microsoft 365 setup and the broader guides library.

If your team still gets confused about where files live (and what that means for recovery), this explainer on OneDrive vs SharePoint is a good starting point.

Key takeaways you can use this week

• Cloud apps are designed to be reliable services. That does not guarantee business-grade recovery from human error or attacks.
• Sync, recycle bins, retention, and version history are helpful, but they are not a full restore plan.
• For each cloud app, you need clarity on: what is backed up, where it lives, how long it’s kept, and how to restore specific items.
• If you have never tested a restore, treat your backups as unproven.

FAQ

Does Microsoft 365 have backup built in?

Microsoft 365 includes high availability and disaster recovery for the service, plus features like recycle bins, versioning, and retention. Whether that meets your needs depends on what kind of incident you are planning to recover from, and how quickly you need to be operational again.

Is retention the same as backup?

No. Retention is mainly about keeping or deleting data according to rules, often for compliance. Backup is about having point-in-time copies you can restore from after damage, and being able to restore specific items without guesswork.

If we use OneDrive or Dropbox, aren’t our files safe?

They are safer than a single laptop, but they are still vulnerable to deletions, overwrites, and ransomware syncing. “Safe storage” and “recoverable after a bad event” are not the same thing.

What are the most common cloud data loss causes in small businesses?

Accidental deletion, overwrites, bad sync behaviour, compromised accounts, and automation or integration mistakes are the big ones. These are customer-side events, not vendor outages.

How do we know if a backup product is any good?

Ignore marketing terms and ask for restore specifics. What can you restore, how far back, how quickly, and who can do it. Then test a small restore before you rely on it.

Do we need backups for every cloud app?

Not always. Start with the apps that hold data you would struggle to recreate: email, calendars, cloud file storage, CRM, accounting, and line-of-business apps. Then work outward.

What should we document internally?

Keep a one-page “recovery sheet”: the list of your cloud apps, who owns them, where backups live, retention length, and how to request and approve a restore. If you can’t write this down, you probably have a gap.

We have an IT provider. Isn’t this their job?

They may manage it, but you still need clarity. You’re the business owner. You need to know what you can recover, because you’re the one paying the cost when recovery fails.