What the Survey Found
Every year, Disaster Recovery Journal and Forrester Research publish “The State of Disaster Recovery Preparedness,” a survey of organizations that already have formal DR programs in place — not companies winging it, but ones that sat down, wrote a plan, and assigned it real budget. The 2026 edition, based on data gathered in fall 2025, found something that should give every IT leader pause: only 40% of respondents said they regularly performed a partial or full failover to their DR site and actually ran production out of an alternate data center on some kind of recurring basis.
The other 60% split into two groups that are both worse than they sound. Thirty-three percent said they intended to test their failover but hadn’t gotten around to it. Twenty-seven percent said flatly that they didn’t test and had no plans to start. Combined, that’s a majority of organizations with a documented, presumably approved disaster recovery plan that has never been exercised against anything resembling a real failure.
The report also found that plan testing and plan maintenance are two separate problems running side by side. Fewer than one in five organizations reviewed or updated their DR plan twice a year or more often; most touched it once annually, at best. The authors also noted that even the minority who do test often only test individual components rather than a full scenario, which “doesn’t replicate actual failure scenarios when an entire datacenter may be affected at once” — meaning even some of the 40% who say they test are testing something narrower than what a real outage would actually demand of them.
The report ties this directly to real stakes, pointing to the October 2025 AWS US-East outage as exactly the kind of event that exposes these gaps: hidden dependencies, concentrated services, and technical debt that only surface once a region actually goes down. A DR plan that has never been run end-to-end is a plan that has never had the chance to reveal those dependencies before they matter.
Why This Matters If You’re Not a Big Company
These survey respondents are organizations formal enough to have a named DR program, and most of them still haven’t tested it. Most small and mid-size businesses don’t have a formal DR program at all — they have a backup vendor invoice and an assumption that “if something happens, we’ll restore from backup.” If companies with dedicated budget and staff are getting this wrong at a 60% rate, a business running IT as one part of someone’s job description should assume its own plan, if one exists, is untested until proven otherwise.
The gap matters because the difference between a tested and an untested plan only shows up at the worst possible moment. A backup that has never been restored might be missing files, might restore to the wrong version, might take fourteen hours when the business can only tolerate four. None of that is visible from a screenshot of a backup job that says “success.” Success just means the job ran — not that anyone could actually get back to work if the primary systems disappeared today.
What Actually Would Have Stopped This
A failover test doesn’t need to be an annual production-down fire drill to be worth something. Start with a restore test — actually recover a real file, a real mailbox, a real server image from backup on a schedule, and time how long it takes. That single habit catches the two most common failure points: backups that silently stopped completing successfully weeks ago, and recovery times nobody has actually measured against how long the business can survive without a system. From there, escalate to a documented tabletop exercise at least once a year where the people who’d actually execute the plan walk through it step by step, not just the people who wrote it.
The report’s finding about component-only testing is worth taking seriously too. Confirming that a single server restores cleanly is not the same as confirming the business can actually run from an alternate location when everything is down at once. Even a scaled-down version of that fuller test, run once, tells you things a document review never will.
Security Checklist for Your Business
Schedule real restore tests. Don’t just confirm the backup job succeeded — actually restore a file or server and time how long it takes.
Run a tabletop exercise annually. Walk the people who’d execute the plan through it step by step, not just the people who wrote it.
Review and update the DR plan twice a year. Staff, systems, and vendors change more often than most plans do.
Test full failover, not just components. A single server restoring cleanly doesn’t prove the business can run from an alternate site when everything goes down together.
A disaster recovery plan sitting in a shared drive, never rehearsed, isn’t protection — it’s a false sense of one. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.
Source: Disaster Recovery Journal / Forrester Research, “The State of Disaster Recovery Preparedness 2026”.
Thanks for this, the 60% untested figure is painful but familiar. In business continuity management we see the same thing: a "success" backup job gets treated as proof of recovery, while nobody has timed a real restore against the RTO. Your point about component tests versus full scenarios is spot on for operational resilience. Just subscribed, happy to follow along and would love it if you followed back.