We ask every organization we assess the same question, and it is not "do you have backups?" Everyone has backups. The question is: when did someone last restore something from them on purpose, and how long did it take?
The answer is usually a pause. Sometimes it's "the backup software says it's green." Occasionally it's "we restored a file once, I think last year, when someone deleted a folder."
That pause is the whole problem. Not because anyone was careless — the backups genuinely are running — but because running and working are different claims, and only one of them has been tested.
A backup that has never been restored is a theory.
What actually goes wrong
When a restore fails, it almost never fails for the reason people expect. The disk is fine. The job history is green. Here's what we actually find.
The backup covers the servers and misses the thing the business runs on. A file server gets backed up because it looks like data. The line-of-business application's database, the one sitting on a workstation in the corner because that's where it was installed in 2018, does not.
The restore works but the environment is gone. You can recover the data. You cannot recover the server it ran on, the licence key, the specific version of the software that reads that file format, or the person who knew the configuration. Data recovery is not service recovery.
Nobody has ever measured how long it takes. A full restore of a few terabytes over a business internet connection is not a fifteen-minute job. Organizations routinely discover this on the day it matters, having quietly assumed hours when the honest answer is days.
The credentials to run the restore are inside the thing that's down. Backup console passwords stored in the password manager that authenticates against the domain controller you're trying to rebuild. This one is common, and it is entirely invisible until the moment it isn't.
None of these show up in a status dashboard. All of them show up in a test.
The two numbers leadership actually owns
Backups get treated as an IT task. Recovery time is not an IT task — it's a business decision that IT then implements. There are two numbers, and both belong to leadership.
Recovery Time Objective (RTO): how long can you be down? Not how long you'd like to be down. How long can payroll, production, patient scheduling, or client billing stop before the consequences change in kind rather than degree. For some organizations that's three days. For a manufacturer mid-run it might be four hours.
Recovery Point Objective (RPO): how much work can you afford to redo? If backups run nightly at 2am and you fail at 4pm, you have lost a day of work. Everyone re-enters it, from memory and paper, while also handling the crisis. Sometimes that's acceptable. Sometimes it means a day of orders nobody can reconstruct.
You do not need to know the technology to set these two numbers. You need to know your business. And until someone writes them down, the technical decisions underneath them are being made by default — usually by whoever configured the software, using whatever the defaults were.
Backups are an IT task. Recovery time is a business decision.
Once those two numbers exist, everything else becomes checkable: does the current setup meet them, and how do we know?
Ransomware changed the math
Backups used to be about accidents — a deleted folder, a failed drive, a flood. Those still happen. But the threat that now drives most backup design is deliberate, and it specifically targets your recovery.
The 2025 Verizon Data Breach Investigations Report found ransomware present in 44% of all breaches. The split by organization size is the part worth sitting with: ransomware appeared in 88% of breaches at small and medium organizations, against 39% at large ones. Verizon defines small business broadly here — fewer than 1,000 employees — so this isn't a statement about 40-person companies specifically. But the direction is unambiguous, and it runs against the intuition that attackers chase the biggest targets. Verizon puts the median ransom paid at US$115,000.
Here's why it matters for backup specifically: modern ransomware operators look for backups before they encrypt anything. Deleting or encrypting the recovery path is what converts an incident into a payment.
CISA's guidance is direct about the countermeasure: "Maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario." And on why offline matters: "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups."
A backup your domain admin account can reach is a backup an attacker with your domain admin account can delete.
The practical shape of this is a copy that is offline, or immutable, or in a separate account with separate credentials — something that a full compromise of your environment cannot reach. If every copy of your data lives inside the environment being attacked, you have redundancy, not recovery.
The Microsoft 365 gap
This one deserves its own section because it is the single most common misunderstanding we encounter, in organizations of every size.
Your Microsoft 365 data — email, SharePoint, OneDrive, Teams — is probably not backed up in the way you assume. Microsoft runs the infrastructure and guarantees the service. You own the data. Under the shared responsibility model those are separate jobs, and the second one is yours.
Microsoft says so in its own Services Agreement, effective 30 September 2025, section 6.b: "We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services."
Retention policies, the recycle bin, and litigation hold are useful. They are not backups. They will not help you against a mailbox a departing employee cleared out ninety-five days ago, or a SharePoint site an attacker encrypted through a compromised account, or a tenant-level configuration mistake.
If nobody can tell you who owns Microsoft 365 backup by name, that's your answer. We wrote about this failure mode more generally in when co-managed IT makes sense — Backup & Recovery is the one area of the six that most often ends up owned by nobody, because both sides assume the other has it.
The Front Range part
Most disaster recovery content is written as if the only disaster is technical. In Colorado that's an incomplete picture.
On 30 December 2021 the Marshall Fire moved through Louisville, Superior and unincorporated Boulder County, destroying and damaging more than 1,000 homes and more than 30 commercial structures. It happened in an afternoon, in winter, in an area nobody had classified as high wildfire risk. Add the routine Front Range version — hail that takes a roof off, a water line above a server closet, a multi-day power event — and the scenario you need to plan for isn't only "our data is corrupted." It's "we cannot get into the building on Monday."
That's a different test. It asks whether your team can work from somewhere else, whether your phones follow you, whether the documentation needed to rebuild is stored somewhere other than the building, and whether anyone knows the plan without opening a file on the network share they can't reach.
The organizations that come through this well are not the ones with the most sophisticated technology. They're the ones where somebody wrote it down and then tried it.
What to ask for
Whoever handles this for you — us, your current provider, your internal team — ask to see these written down. Documents are more useful than answers here, because writing it down is what surfaces the assumptions.
- The last restore test, with a date and a result. Not "we test regularly." A date, what was restored, and how long it took.
- What is and isn't covered. An explicit list. Servers, workstations, Microsoft 365, the line-of-business application, and anything deliberately excluded — exclusions are fine, undocumented exclusions are not.
- Your RTO and RPO, in writing, and whether the current setup actually meets them. If nobody can produce these, they haven't been decided.
- Where the offline or immutable copy lives, and which credentials reach it. If the answer is the same credentials that run everything else, that's the finding.
- The recovery runbook — who does what, in what order, reachable without the network being up.
- Who owns Microsoft 365 backup, by name.
Six items. If you get six clean answers, you're in better shape than most organizations we assess. If you get four, you now know exactly where to spend the next month.
Why an IT company would tell you to do this yourself
Because this is the area where the gap between what people believe and what is true is widest, and because nothing on that list requires us. You can run every item with your existing team and your existing tools. Several of them will tell you that your current provider is doing the job properly, which is a genuinely good outcome and one we'd rather you find out from a test than from a bad week.
We'd also rather have the conversation before the incident than after. Everything above is yours to keep whether or not we ever speak again.
If you want it done for your specific environment, that's part of what our free IT risk review produces: a one-page findings report covering your security, backup and support gaps, plus an inventory of what you're actually running. Frequently it's the first complete one an organization has ever had.
We're a veteran-owned team in the Denver metro, working with organizations in the 15-to-70 person range — nonprofits, professional services, and manufacturers. Senior engineers only, month-to-month, no multi-year lock-in. If you want the longer view of how this fits into a managed IT relationship, we cover the structure in how much managed IT services cost, and the service itself is backup and disaster recovery.
So: if the building were unreachable tomorrow and the servers were encrypted, who runs the first hour — and have they ever done it before?
Book a free IT risk review or call us at 720-794-0400.
Sources, checked 11 August 2026
- Verizon, 2025 Data Breach Investigations Report and the 2025 DBIR SMB Snapshot — ransomware present in 44% of breaches; 88% of SMB breaches vs 39% at large organizations; median ransom paid US$115,000.
- CISA, #StopRansomware Guide — offline, encrypted backups and regular restore testing.
- Microsoft Services Agreement, effective 30 September 2025, section 6.b.
- Boulder County, Marshall Fire recovery information — 30 December 2021, more than 1,000 homes and more than 30 commercial structures destroyed or damaged.