Resource
Backup is not recovery.
Having backups is not the same as knowing the business can actually recover. The gap between the two is where most disasters live.
Backup is a product. Recovery is a plan.
Most environments have backup software running. Far fewer can answer the question that actually matters: if a critical system went down tonight, how long would it take to be back in business, and what data would be lost?
That question has a name in IT. Recovery time objective and recovery point objective. How long can the business be down before the cost becomes serious. How far back can the data go before the loss becomes unacceptable. Most businesses have never had that conversation with their IT provider. Most IT providers have never asked.
Recovery is the planning conversation behind the software. What gets restored first. In what order. By whom. With which vendors. How leadership gets kept informed. A backup that runs every night but has never been tested against those questions is not a recovery plan. It's a file somewhere that someone hopes will work when it's needed.
The ransomware problem most businesses don't know about.
Ransomware doesn't just encrypt your files. It looks for your backups and encrypts those too.
A backup connected to the same network as the systems it protects can be reached by the same attack. When that happens, the backup that was supposed to be the recovery path is part of the problem. The business is left with encrypted production data and an encrypted backup. And the only options are paying the ransom or starting over.
This is why backup architecture matters as much as backup frequency. An immutable backup, one that cannot be altered, deleted, or encrypted by any process once it's written, survives the attack even when everything else doesn't. An air-gapped backup, stored separately from the systems it protects, can't be reached by an attack on the main environment.
Most businesses don't know whether their backup is immutable. Most don't know whether it's air-gapped. Most have never asked their IT provider. The answers to those questions determine whether the backup is a recovery path or a false sense of security.
What Microsoft 365 does and doesn't do for your data.
Most businesses assume Microsoft is backing up their email, files, and Teams data. Microsoft isn't.
Microsoft operates under a shared responsibility model. Microsoft keeps the platform running. The customer is responsible for their own data recovery. Microsoft's own services agreement recommends that customers regularly back up their content using third-party applications.
What this means practically: if an employee accidentally deletes a mailbox, if data gets corrupted, if a ransomware attack hits the Microsoft 365 environment, Microsoft's retention policies have limits. Data deleted beyond the retention window is gone. Data that needs to be recovered months after an incident may not be recoverable from Microsoft's tools alone.
Microsoft 365 should be backed up independently of the platform, email, SharePoint, OneDrive, Teams, with a third-party solution that creates a separate, recoverable copy the business actually controls. If your current provider hasn't mentioned this, ask them directly whether your Microsoft 365 data is independently backed up and what the recovery window actually is.
What real backup discipline looks like.
Coverage of every system the business depends on. Not just the server, not just the file share, but the line-of-business applications, the email environment, the cloud platforms. A backup that covers 80 percent of the environment leaves 20 percent unprotected and that's usually where the most important data lives.
Monitoring that gets acted on by people. A backup job that fails and gets flagged in a dashboard nobody checks is not monitored backup. Someone has to be looking at the results and responding when something goes wrong before the failure compounds.
Restores tested on a real cadence. Not assumed. Not hoped. Tested. A restore test puts data back into a real environment and confirms it works. The timing gets documented. The gaps get identified before an incident makes them urgent.
Backups protected from the same attack that could hit the systems they protect. Immutable storage. Off-site or air-gapped copies. Architecture that assumes the worst-case scenario and builds around it.
A written recovery plan agreed with leadership in advance. Who gets called. In what order. What gets restored first. How long each step takes. What the communication plan is for staff and clients while recovery is underway. This conversation should happen before the incident, not during it.
Microsoft 365 backed up independently of the platform. A separate, third-party solution that creates a recoverable copy the business controls. Not a reliance on Microsoft's retention policies to serve as a backup strategy.
Each piece is achievable. Together they turn the worst day from a guess into a plan, and each one lives inside the standards baseline every environment we manage is held to.
The questions worth asking your current IT provider.
These questions don't require technical knowledge to ask. The answers will tell you what you need to know.
When was the last time a restore was actually tested. Not monitored, tested? If the answer is vague or involves a date more than six months ago, the backup hasn't been validated recently enough.
Is the backup immutable? Can it be encrypted or deleted by a ransomware attack that reaches the network? If the provider can't answer this clearly, the architecture may not be protecting against the most common attack vector.
Is Microsoft 365 backed up independently of the platform? What is the recovery window if data needs to be restored from six months ago?
What gets restored first in a recovery scenario, and how long does each step take? If there's no written answer to this question, there's no recovery plan. There's a backup and a hope.
Who is accountable for monitoring backup jobs and responding when one fails? Not the company. The person.
What changes when backup is actually managed.
The answer to how long recovery takes exists before an incident makes it urgent. Leadership has been part of the recovery planning conversation. The backup has been tested against a real scenario, not just monitored. The Microsoft 365 environment has an independent recovery path. The architecture protects against ransomware reaching the backup the same way it reaches production.
When something goes wrong, and something will eventually, the response is practiced, not improvised. The difference between a business that recovers in hours and one that recovers in weeks is almost always whether the planning happened before the incident.
If none of this is in place, the plan doesn't exist until the incident forces one. A backup that was never tested fails when production is down. A Microsoft 365 mailbox that wasn't independently backed up isn't recoverable six months later. A ransomware attack reaches the connected backup and both are gone. The gap between having a backup and being able to recover stays invisible until something makes it visible. And by then the cost of finding out is already being paid.
If you don't know the answers to the questions above, that's exactly what an IT Environment Review is for. We look at what backup actually covers, how it's protected, whether it's been tested, and what a real recovery scenario would look like for your business.
Common questions
Questions leadership usually asks first.
Continue reading
Related work and reading.
Backup & Recovery
The service that turns backup software into a tested recovery plan, including Microsoft 365.
Read more: Backup & RecoveryStandards & Security Baseline
Where immutable backups, restore testing, and recovery documentation live as non-negotiable controls.
Read more: Standards & Security BaselineIT Environment Review
Find out what your current backup actually covers, and whether a real recovery would work.
Read more: IT Environment ReviewNext step
Get a clearer view of your IT environment.
Find out what is working, where the risks are, and what needs attention next.