As a major retailer with more than 1,700 outlets, Canadian Tire needs robust business processes that continue to operate seamlessly when adverse events strike. Although the company had disaster recovery plans in IT and an established business impact analysis discipline in its business units, these processes ran on Microsoft Excel, Word, and emails—and weren’t connected.

Perhaps the worst IT scenario an organization can face is an unexpected and forced suspension of all its operations. The downtime that’s experienced in such a situation can lead to financial damages that far exceed those from lost data or hits to reputation. While cyberattacks vary in intensity and approach, downtime and catastrophic loss of data come in many more forms and are equally, if not more, difficult to avoid.

Disaster recovery (DR) plans are not one-size-fits-all. There’s no silver bullet, and without a clear understanding and some level of customization, a DR plan done wrong will have detrimental effects on an organization’s operations and business. And let’s not forget the wrecking ball a bad DR plan delivers to the VAR or MSP who designed and executed it. Loss of business aside, there’s guilt, reputation damage, and potential lawsuits. It’s not a good day.

Around six years ago on a Wednesday morning, software professionals worldwide were startled by a tweet from GitLab stating that they had accidentally deleted their production data, causing their site to go offline. Unfortunately, at that point in time, the open-source code repository giant had no idea that it would take them another 36 hours to restore their systems only to learn that 5,000 projects and 700 new user accounts were affected while they were fixing the outage.