Time for a Disaster Recovery Health Check

Disaster recovery is no longer a purely technical back-office concern. For CIOs and business leaders, the real question is whether recovery ownership matches where the business now runs: remote users, edge sites, cloud services and third-party platforms. If the operating model still assumes central IT will coordinate everything, recovery will fail at the point where speed and clarity matter most.

The management issue is decision rights. Who declares an incident, who authorises failover, who can approve service substitutions, and who owns communication to customers and regulators? Those answers need to be explicit for headquarters, branches, cloud vendors and country-specific environments. Otherwise, the organisation may recover technically while remaining commercially paralysed because no one can make timely trade-offs.

A health check should therefore test governance as much as technology. The practical next questions are: which services are truly critical, which dependencies sit outside direct control, and which recovery objectives are realistic for each site? Leaders should expect some uncomfortable outcomes: tighter recovery targets may require more cost, more standardisation or fewer local variations. But deferring that choice simply pushes risk into the next outage.

Vendor assurance also needs to become a portfolio criterion. Recovery testing, evidence of recent failover exercises and clear support obligations should be built into sourcing and renewal decisions, not treated as optional extras. The key trade-off is between speed of procurement and resilience discipline. For boards and executives, the right question is not whether DR exists, but whether it is exercised, funded and governed across the full business footprint.

The COVID-19 crisis increased the number of remote employees in the typical enterprise, and new edge and Internet of Things (IoT) technologies have been moving IT out of the data center and into the cloud. Think about this: Did your disaster recovery plans keep pace?

In most cases, companies are struggling to keep their DR and failover plans synchronized with the rate of IT change that has moved out to the edge. DR plans are still highly data center-centric, a mode of thought that for many years presumed that if you got the main, central systems back quickly, you could get by even if other more peripheral systems took longer to recover from an outage.

Unfortunately, data center-focused DR didn’t anticipate the rapid movement of IT to the edges of enterprises, and the movement of employees out of the corporate buildings and into their own home offices. Decentralized sites in retail, distribution, healthcare, finance, and manufacturing use their own systems and networks, too. They might even use different cloud resources and internet service providers than the headquarters.

These smaller sites have no dedicated IT person and may be far away from central IT, so there are no guarantees that nightly backups of systems and data are always made. If these sites are in different countries, vendor support — even for the same system — will vary from country to country. There might even be confusion as to whom is in charge of what when disaster strikes, and timely decisions must be made.

What happens if disaster strikes and this edge IT goes down?

There’s a lot to unpack for sure, and corporate IT departments must do this unpacking and re-planning in a context where they know that re-imagining (and rewriting) DR will likely be a background priority.

How do you address the robustness and currency of your current DR plan, and then make changes where needed, all when other high-stake projects are waiting?

Conduct a DR plan health check. The first step is assessing the robustness of your current DR and failover plan. How recently was the plan updated? Does it include DR plans for edge and remote sites as well as for the central data center? Are end users and IT sufficiently trained on the plan so they can execute it without hesitation if disaster strikes? Does the plan include failover routines for edge networks and clouds as well as for central systems?

Most companies will discover at least some holes in their DR plans, and those holes are most likely to be at the edges of the enterprise where technology has most recently been implemented. By conducting a DR plan health check, IT can find the holes, assess the risk, and describe the magnitude of that risk as part of the corporate risk management plan that gets presented to the board.

Explain the holes in the plan. By law, the board and C-level officers have the responsibility of executing due diligence and competence in the conduct of company operations and asset securement. They do not want to see gaping holes and exposures in corporate due diligence that are due to disaster recovery plans that fail to address new security threats or the presence of edge technology. This board awareness can give IT the leverage it needs to prioritize its DR plan update so the revised plan can cover a much broader IT footprint than just the central data center — and by doing so, address new risks.

A good way to present to the board and corporate officers a need to invest time and resources into a DR plan update is to present the need for an update along with the risks of not doing one. This can be accomplished by describing various disaster scenarios that have actually happened to other organizations and explain how they could plausibly happen to the company itself. By showing real life situations, the CIO can present the most likely disaster scenarios and consequences and what is needed in terms of plan revisions and investments to minimize those risks.

DR scenarios might involve new types of security breaches, malware, and ransomware attacks occurring in edge networks, along with the vulnerabilities of IoT edge devices and the risks of users entering into cloud or ISP services that haven’t been properly vetted. Also, outline the risk from employee malfeasance or negligence that can occur at remote locations.

Develop strong partnerships. An estimated 35% of companies work with over 1,000 different vendors , and many of these vendors provide IT.

IT vendors deliver cloud IaaS (infrastructure as a service), PaaS (platform as a service) and SaaS (software as a service) systems and applications. They also provide in-house application systems like ERP (enterprise resource planning); hardware; networks; IoT components and systems; along with many other IT assets.

Past IT disaster recovery plan efforts focused on those products and services that IT had direct control over, assets that primarily resided in the central data center. On-premises IT gave IT managers the ability to develop and perform DR and failover plans on their own. However, with more IT in the cloud or at the edge, IT is more dependent on its vendors for DR and failover. Yet, many IT departments still confine their DR plans to centralized and directly controllable IT assets and services.

By not including and actively practicing disaster recovery plans with its primary vendors, IT runs the risk of being unprepared if a cloud service with company data is compromised. This problem rapidly accelerates to becoming a problem not only with the vendor, but with concerned customers and stakeholders.

The takeaways are:

You must adjust your DR and business continuation plans to include and to test for resiliency in both on premises and off premises systems.
All RFPs being issued to IT vendors should include requirements for providing their DR and failover plans, along with a schedule of how often these plans are tested and what the results are.

Like IT itself, a business disaster recovery and failover plan goes beyond enterprise walls and into the ecosystem of everyone that the enterprise does business with. Gone are the days when a CEO could relegate IT DR’s to central data center backups and recovery. Instead, IT’s central, facilitating role in every aspect of the business makes it a prime risk-management category that should resonate in the minds of the CIO, the CEO, the board and all other stakeholders.

It’s up to the CIO to bring this thinking to the forefront.

As LinkedIn recently summed: “A BCP (business continuation plan) is not a static document that you can create once and forget. It needs to be reviewed and updated regularly to reflect the changing environment, risks, and needs of your organization.”

Original Post

Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.

Time for a Disaster Recovery Health Check

Like this:

Related