What Is Disaster Recovery Testing and Why Do Businesses Skip It?

Most businesses have some version of a disaster recovery plan sitting in a folder somewhere. Far fewer have ever actually run it. That gap between having a plan and having tested one is one of the most common and most avoidable risks in business continuity.

This guide is for owners and operations leads at small and mid-sized Ontario businesses who already have backups, and maybe a written recovery plan, but aren’t sure recovery would work if a server failed, ransomware hit, or the office became unreachable. Testing is the part of business continuity and disaster recovery that turns those assumptions into facts, and it’s where ACT360 sees the widest gap between what businesses believe and what’s true.

The testing frequencies below are ACT360’s recommended cadence, anchored to published guidance from NIST and the Canadian Centre for Cyber Security. Where a point comes from our own testing work, we say so.

Disaster recovery testing means simulating a real failure, like a server outage, a ransomware event, or an office nobody can get into, and confirming the business could actually recover within the time it needs. It checks the people, the plan, and the technology together, instead of trusting a written plan that has never been run.

It isn’t the same as a backup test. A backup test confirms specific data can be restored. A disaster recovery test confirms the business can operate from what gets restored, in the right order, with the right people and access, inside the recovery time the plan promises. Our guide to how often to test your backups covers the first part. This article is about the second.

Businesses skip disaster recovery testing because it takes time, can feel disruptive to schedule, and doesn’t produce an obvious return. An untested plan also looks exactly like a tested one on paper, right up until the day it’s needed.

That’s what makes it easy to defer indefinitely, and exactly why it shouldn’t be. There’s also a quieter reason. Nobody enjoys finding out the plan doesn’t work, and a test is designed to do precisely that. The honest way to look at it is that a failed test during a scheduled exercise is the cheapest failure a business will ever have.

The 3 types are tabletop exercises, component tests, and full simulations. A tabletop is a discussion with no systems touched, a component test restores or fails over one piece of the environment, and a full simulation rebuilds critical systems and confirms the business can run from them.

• Tabletop exercise. The response team walks through a simulated scenario verbally, discussing who does what and in what order. NIST’s guide to test, training, and exercise programs describes tabletops as discussion-based exercises that don’t involve deploying equipment. They’re the fastest way to catch gaps in the plan itself, like unclear ownership or missing contact information.
• Component test. A specific piece of the plan gets tested directly, such as restoring a file server or a Microsoft 365 mailbox from backup, or failing over one system to a secondary environment. Where a workload runs in Azure, Microsoft’s Azure Site Recovery test failover is built for this kind of drill, and Microsoft notes it “doesn’t impact ongoing replication, or your production environment.”
• Full simulation. The most comprehensive test, and the most disruptive to schedule. Critical systems get rebuilt in a recovery environment, and the test confirms the business could genuinely operate from what got recovered, not just that the technical pieces came back online.

Recommended frequencies are ACT360’s cadence, explained in the next sections.

In ACT360’s testing work, the most common findings are recovery times that turn out longer than the plan estimated, dependencies between systems that nobody documented, and contact details or credentials that are out of date. None of them are visible on paper, which is why they survive until a real test.

The value of a real test isn’t confirming the plan works. It’s usually finding the specific ways it doesn’t, before that failure happens during an actual incident. These are patterns from our own work, not results from a published survey, and every environment will turn up its own version of them.

Undocumented problems tend to surface whenever an environment is pushed harder than usual. During an Ontario law firm’s move to Microsoft Azure, ACT360 found data bleed-through between client files and years of accumulated group policy causing instability, neither of which appeared in any documentation. That was a migration rather than a disaster recovery test, but the lesson is the same, and it’s covered in the law firm cloud migration case study. Our cloud migration checklist uses the same dependency mapping a good DR plan needs.

ACT360 recommends tabletop exercises at least twice a year, component tests quarterly for critical systems, and a full simulation annually or after any significant change to the environment. That’s our recommended cadence, built on published guidance rather than a legal requirement for private businesses.

The annual anchor comes from established guidance. NIST’s contingency planning guide, SP 800-34 states that plan recovery capabilities and personnel should be tested annually, and NIST’s exercise guidance recommends tabletops periodically and after organizational changes or plan updates. The Canadian Centre for Cyber Security advises businesses to test, revisit, and revise their incident response plan annually, and its baseline controls call for regularly verifying that backups can be restored. The quarterly component tests are ACT360’s addition, because critical systems change often enough that a once-a-year check leaves too long a gap.

Businesses with systems that change frequently, or that can tolerate very little downtime, should test more often than this baseline. A manufacturer running a production line has very different stakes than a professional services firm, even if their technical environments look similar on paper.

ACT360 schedules and documents disaster recovery testing as a standard part of the client relationship, not something clients have to remember to ask for. Tabletops, component tests, and full simulations are cadenced around what each business can actually tolerate in downtime.

Jeffrey Bowles, Partner and Director of IT Services at ACT360, explains the reasoning behind scheduling this proactively rather than waiting for a reason to test.

“I’d rather we catch this now, in a review, than have it show up as an incident in six months.”

Jeffrey Bowles, Partner & Director of IT Services, ACT360

Depending on the environment, testing covers Microsoft 365 data, on-premise file and application servers, line-of-business applications like accounting software, and test failovers where workloads run in Azure. Every test ends with a dated result and a list of what needs fixing before the next one. For manufacturers, ransomware is usually the scenario worth rehearsing first, and our look at why ransomware targets manufacturers in Canada explains why.

A disaster recovery plan earns its name the first time it’s actually tested. Before that, it’s a reasonable draft of what might work, and 3 habits close the gap.

1. Use all 3 levels of testing, because tabletops, component tests, and full simulations each catch different problems.
2. Put the tests on a calendar, and add one after every major change to the environment.
3. Treat every failed test as the result you were looking for, then fix it and re-test.

If you’re not sure when your plan was last tested, or whether it’s ever been tested at all, that’s the first thing to find out. ACT360’s IT Readiness Assessment is a free, no-obligation review that looks at your backups and recovery plan alongside the rest of your environment.

Call 705-739-2281 or email [email protected]