If your files live in Microsoft 365 or Google Workspace, you probably do not have a backup. You have retention, which is a different thing, and the difference only becomes visible on the day you need to undo something.
This is the question we get asked most often by nonprofit and association leaders in Washington, DC, usually a week after somebody deleted a shared folder or a finance mailbox got compromised. What follows is the short version of what we tell them: what backup actually means once your data is in the cloud, what your provider does and does not do for you, and how to decide what to pay for.
Is Microsoft 365 backing up your data?
No, and Microsoft says so directly. Its shared responsibility model puts customer data, configurations, identities, and user accounts on the customer in every deployment model, software-as-a-service included. Microsoft runs the platform. What lives inside it is yours to protect.
What Microsoft 365 gives you by default is retention: version history, recycle bins, single-item recovery, and optional legal holds. Those are useful and they solve the everyday problem of one person deleting one file. They are not a backup, and Microsoft's own documentation explains why in plain terms:
- Disaster recovery copies hold the current state of your content, not historical versions from earlier points in time. If the current state is encrypted, so is the copy.
- Version history lets individual users roll back individual files, but it does not scale to the case where an administrator needs to orchestrate recovery across thousands of items. Versions can also be exhausted, depending on the version limit an admin has set.
- Legal holds retain data, but they are built for export through eDiscovery, not for mass restore.
There is also a clock most organizations do not know about. When data is actively deleted from a tenant with a live subscription, Microsoft's data handling standard retains it for at most 30 days. If the subscription itself ends, Microsoft keeps customer data in a limited-function account for 90 days so you can extract it, and deletes everything no later than 180 days after termination. A lapsed invoice is a data-loss event on a timer.
What is the 3-2-1 rule, and does it still apply in the cloud?
The rule is three copies of your data, on two different kinds of media, with one copy off site. It was written for tape and it still holds, but the words mean something different now.
Off site used to mean a different building. When your production data already lives in a Microsoft or Google datacenter, off site means a different failure domain and, more importantly, a different administrative boundary. A backup that a compromised global admin account can delete is not a third copy. It is the same copy with extra steps.
The practical translation for a cloud-first organization: production in Microsoft 365 or Google Workspace, a backup in a system with separate credentials and its own retention policy that your tenant admins cannot purge, and immutability on that backup so a ransomware operator with your password cannot shorten its life.
How often should backups run?
Work backwards from how much work you can afford to lose. That number is your recovery point objective, and it sets backup frequency rather than the other way around.
For most nonprofits and associations we work with, the answer for email and shared files is under an hour, because a morning of lost donor correspondence or grant edits is recoverable and a week is not. For a finance or membership database mid-audit, it is minutes.
As a reference point, Microsoft 365 Backup, Microsoft's own paid add-on, publishes a recovery point objective of 10 minutes for OneDrive, SharePoint, and Exchange Online across the trailing two weeks. Beyond two weeks you get weekly restore points out to 52 weeks. That is a reasonable bar to measure any alternative against. Two limits to check before you buy it: retention is a fixed one year and your tenant retention policies do not flow through to it, and data sitting only in those backups is not discoverable through eDiscovery.
How long should recovery take?
Recovery time objective is the other half, and it is the number organizations almost never test. How long can you be down before the consequence stops being inconvenience and starts being a missed payroll, a blown grant deadline, or a board conversation?
Write the number down per system, because it differs. Email might be four hours. The membership database might be one. An archive of old program photos might be a week, and that is fine. Once the numbers exist, they tell you where to spend money and where not to, which is the entire point of the exercise.
What does an untested backup actually cost you?
Everything, on the one day it matters. A backup job that reports success every night for two years and cannot produce a working mailbox is worse than no backup, because you planned around it.
Restore testing is the part of this discipline that gets skipped, and it is the only part that proves the rest works. Test by restoring something real to a scratch location and having the person who owns that data confirm it is intact. Not the IT team, the owner. Do it on a schedule you would be comfortable describing to your auditor.
Three failures we see repeatedly, all of which a single restore test would have caught: the backup covered mailboxes but not the SharePoint sites where the actual work lived; the backup covered files but not the permissions, so the restore arrived as an unusable flat pile; and the backup covered everything except the one system somebody stood up outside IT's knowledge.
What should a nonprofit actually back up?
Start from what would stop the mission rather than from a list of servers.
- Email and calendars, including shared and departmental mailboxes, which are routinely missed because nobody owns them.
- SharePoint, Teams, and OneDrive content, with permissions, because collaboration structure is data too.
- Your CRM or donor and membership database, which is often the single most expensive thing to reconstruct and often the only system still on someone's laptop.
- Financial systems and their supporting documentation, on a retention schedule that matches your audit and grant obligations rather than a default.
- Identity configuration. Rebuilding groups, conditional access rules, and app registrations from memory after a tenant compromise is its own outage.
- Any line-of-business system a program team adopted directly. Ask; do not assume.
How does ETTE handle backup and recovery?
Cloud backups for files and email are included in every ETTE managed plan, which start at $125 per user per month for remote-only support and $150 per user per month fully managed, with nonprofit rates available on both. Backup and disaster recovery are also part of co-managed engagements, which we scope to the responsibilities your internal team wants to keep.
What we think matters more than the tooling is the order of operations. Every ETTE engagement opens with a 30-day Smooth Start at no additional cost, and the first thing it produces is documentation of your actual environment: every device, account, application, and configuration. You cannot write a defensible recovery plan for systems nobody has inventoried, and in our experience the discovery phase is where the gaps surface. It is usually the departmental mailbox, the database on a program director's machine, or the file share that was supposed to be decommissioned two years ago.
From there the work is unglamorous and mostly consists of doing the things above on a schedule: recovery objectives written down per system, backups scoped to match them, restore tests that a data owner signs off on, and a recovery plan short enough that somebody could follow it during a bad week. Our help desk is staffed Monday through Friday, 7 AM to 7 PM ET, and works to published response objectives of 20 minutes for urgent issues and 60 minutes for high priority.
Where to start if you are not sure what you have
Ask three questions and see whether anyone can answer them without checking. If your email and files were encrypted this afternoon, what is the most recent point you could restore to? Who has the standing ability to delete your backups? When did somebody last restore something and confirm it worked?
If those answers are not immediate, that is the finding, and it is a more useful place to start than a product comparison. The readiness assessment walks through the same ground in a few minutes, and the cloud, productivity, and backup operations page covers what we run day to day.
Vendor details in this article were verified against Microsoft's shared responsibility documentation, the Microsoft 365 Backup FAQ, and Microsoft's data retention and deletion standard in August 2026. Microsoft changes these terms periodically; confirm current specifics before making a licensing decision.