When our customers ask me “What is the project that we should be doing?” they expect to hear something exciting from me. Given my well-known affinity for AWS and the innovation that their cloud tools make possible, customers expect me to suggest AI or IoT projects. While those types of projects are incredible and they’re driving business value for many companies, my answer is almost never that exiting. Nine times out of ten my answer is the same. Test your disaster recovery strategy.

This might seem like a boring answer, but the reality is that disaster recovery is one of the most critical and overlooked aspects of technology management. Many organizations invest heavily in cutting-edge solutions while neglecting their backup and recovery capabilities. Investing in new solutions and functionality only makes sense after you've secured your business continuity through disaster recovery trials.

The unfortunate reality is that a lot of companies don’t ever reevaluate their disaster recovery strategies, and they can atrophy. Technology landscapes are not static entities. They change over time, evolve with business need, and are often unrecognizable when compared to their state from a few years prior. A “set it and forget it” approach to DR is not sufficient in today’s fast moving technology ecosystem.

Disaster recovery strategies ought to be continually updated and validated to confirm that they’re still fit for purpose. Are the stated Recovery Point Objective (RPO) and Recovery Time Objective (RTO) still accurate? If your database has tripled in size, it will likely take longer to recover and either the RTO needs to be adjusted, or the approach needs to be sped up. Does your team still have the proper skillset to recover the system? If there has been turnover in the incident response team, or if the last disaster recovery run was years ago, the team will be getting themselves up to speed while the system is compromised, which is not ideal. Has new functionality been added to your landscape that is business critical? It may not be recovered or reachable when following a DR process that was designed before it was added.

This all sounds like doom and gloom, but it’s not. The solution is simple, cost effective, and it can even be fun! Simulate a disaster and recover your system. Test your assumptions. Run it as a "game day" exercise where your team can practice their incident response in a low-stakes environment. Document the process, identify gaps, use the experience to improve your procedures and schedule your next DR trial. This not only validates your recovery capabilities but also builds confidence in your team's ability to handle real emergencies.

Once you've established a routine practice of updating and validating your disaster recovery strategy, your foundation becomes solid. You'll be confident in your ability to recover from ransomware attacks, hardware failures, and even human errors, because you've seen it work firsthand. While innovation is important, without strong business continuity practices in place, you can't be certain that what you build will survive a disaster.