While IT disaster recovery is technically part of a larger, overall business continuity plan, the two things can sometimes drift apart. One reason for this is that disaster recovery (DR) is often seen as the responsibility and fiefdom of the IT department. This can lead to DR in “glorious isolation” and not necessarily in a way that immediately contributes to getting an enterprise fully operational again.
For example, confirming that business-critical systems are running again is not the same as verifying that end-users are once again being productive by using those systems. What’s the answer?
A starting point for making sure that disaster recovery is “connected” to, and has a direct positive impact on business continuity is to make sure that at a systems level, DR and BC work together. Having one overall system across the enterprise with a single source of data and common recovery/continuity goals can help integrate DR effectively into BC.
Automation of recovery processes and orchestration of these processes as part of the overall business continuity plan helps make sure that systems are not only recovered individually, but that they also work properly together and contribute to business goals, rather than stopping short at RTO, RPO, or any other lower-level metric.
Integration and harmonisation between disaster recovery and business continuity works both ways too. BC planning can identify the business criticality of each process so that DR planning can put the right recovery procedures in place for the systems that power those processes.
IT disaster recovery planning can in turn extend to an enterprise-wide configuration management database (CMDB) and IT-driven tools for mass notification of system availability. The classic metrics of RTO and RPO can be automatically linked to user requirements to flag any gap between what the IT department is providing and what the business needs. Thus, DR can become truly part of BC, making the enterprise better off too.