Backup vs. Tested Recovery: The Green Dashboard Trap

Backup software reports on the job it was told to run. It confirms data left the source and landed somewhere. It does not confirm that the somewhere is reachable during an incident, that the data is restorable in the order your applications need, or that your team remembers how to do any of it under pressure. A green dashboard is a status report on step one of a ten-step process, and most businesses only ever test step one.

The financial stakes are not abstract. Sophos puts the median cost of ransomware recovery, not counting any ransom paid, at $375,000, with a mean closer to $1.7 million once you include the long tail of businesses that got hit hardest (Sophos, State of Ransomware 2026). That gap between median and mean is mostly businesses whose recovery process didn't work the way they assumed it would. The same report found 69% of victims did not pay the ransom, up from 65% the year before (Sophos, State of Ransomware 2026) — which sounds like good news until you realize that choice only works if your backups actually restore. Refusing to pay a ransom you can't afford is a strategy. Refusing to pay because you have a working alternative is a plan.

Testing a recovery plan is not opening a file from last night's backup to confirm it's not blank. That proves almost nothing. A real test answers harder questions:

• Can you restore a full server, not just a folder, to functioning hardware or a cloud instance within your stated recovery time objective?
• Do your backups survive if the attacker already has domain admin credentials, since Verizon's 2026 DBIR found credential abuse shows up at some point in 39% of breaches — meaning the same account that lets someone into your network can often reach your backup console too?
• Is at least one copy offline, immutable, or air-gapped in a way ransomware encryption routines can't touch?
• Does the person who knows the restore process actually still work there, and is the process written down somewhere other than their head?
• How long does it take to bring back email, your line-of-business application, and your phone system in the order your business actually needs them, not alphabetical order?

Most companies we assess have never answered more than one of those. That's not a judgment, it's just where priorities land when nothing has broken yet. Locking down who can reach backup infrastructure in the first place, through privileged access management, closes one of the biggest gaps between "we have backups" and "the backups survived the attack."

Texas businesses got a real incentive to formalize this in 2025. SB 2610, effective September 1, gives companies with 20 to 99 employees protection from exemplary damages in a breach lawsuit if they've implemented the CIS Controls Implementation Group 1 safeguards — 56 specific controls, backup and recovery testing among them (Texas SB 2610). It doesn't bar lawsuits and it doesn't create a new right to sue; it only takes exemplary damages off the table for companies that can show they did the work. "The backup job showed green" is not evidence of diligence. A documented test, with dates, results, and remediation of whatever broke, is.

If your business handles health records or financial data, this sits on top of existing obligations under HIPAA or the FTC Safeguards Rule, both of which expect a tested, documented recovery capability, not just a backup subscription.

Start by splitting your systems into tiers. Email and your core line-of-business app are tier one; archived project files from 2019 are not. Set a recovery time objective and recovery point objective for each tier, then actually test against them on a schedule, quarterly for tier one, annually for everything else at minimum.

Run the test like a drill, not a demo. Pick a system, restore it to isolated infrastructure, time it, and document every manual step someone had to improvise. Those improvised steps are the real plan. Write them down and fix the ones that took too long.

Make sure your backup architecture itself doesn't share credentials or network paths with your production domain. If an attacker with domain admin can also log into the backup console, you don't have a backup, you have a second copy of the same problem. This is usually where cloud-based backup and recovery architecture earns its cost, since isolation and immutability are built in rather than bolted on.

Finally, put someone's name on it. A plan with no owner drifts. A plan with an owner who has to present test results every quarter gets maintained.

Verizon's 2026 DBIR found the median time to fully remediate a known-exploited vulnerability, from scanner detection to patch, is now 43 days, up from 32 the year before (Verizon 2026 DBIR, Fig. 13). That's a window measured in weeks where a known hole in your network sits open. Pair that with an untested recovery plan and you're betting your business on nothing going wrong in a six-week gap, every single time a new vulnerability surfaces. That's not a bet most Texas business owners would take if they saw the numbers laid out this plainly.

We've rebuilt disaster recovery plans for companies around The Woodlands and across the Houston area after they found out the hard way that their old provider had never actually tested a restore. If you're switching providers because of something like this, our guide on switching IT providers walks through how to do it without losing continuity mid-transition.

How often should we actually test a restore?

Quarterly for the systems your business can't run without — email, your core application, your phone system. Annually at minimum for everything else. If you've never tested, do it this month, not next quarter.

Is cloud backup automatically safer than on-premises?

Not automatically. Cloud backup removes some physical risk but can still be compromised if it shares credentials with your production network. The protection comes from isolation and immutability, not from the word "cloud" by itself.

Does SB 2610 mean we're covered if we get breached?

No. It only removes exemplary damages in a lawsuit, and only if you've implemented the CIS IG1 safeguards before the incident. It doesn't block a lawsuit and it doesn't create new legal rights for either side. You still need an incident response plan and a working recovery process.

What's the difference between a backup plan and a disaster recovery plan?

A backup plan describes how data gets copied and retained. A disaster recovery plan describes how your business keeps operating, including restore order, timelines, roles, and communication, when something takes systems down. You need both, and the second one is the one almost nobody tests.

If you're not sure your backups would actually get you back online, that's worth finding out before an attacker tells you. Our managed IT services team can run a real recovery test alongside a broader cybersecurity review and show you exactly where the gaps are. Start with a free IT assessment or contact us to schedule one.