“If you fail to plan, plan to fail” goes the old adage. In the current age of hyper-connectivity and uber-accessibility, dependence on real-time technology and applications brings an even greater need for technology-centric disaster recovery and business continuity planning. Most organisations understand this, yet despite the increased awareness, IT disaster recovery plans continue to fail when needed most; during a disaster or disruption.
Here are five reasons why IT disaster recovery plans fail, and some tips for making sure that your organisation does not find itself with an ineffective DR plan.
1. Lack of "Testing"
A plan is just that without validating its achievability. Continual validation and exercising of the plans, services, and people that support technology recovery ensure that the recovery solution is in sync with production, documentation is up to date, and people are at an enhanced state of readiness to respond to an incident. There are myriad reasons organisations don’t test – including time, costs, undervaluing impact, and lack of processes seen in a mature program. The impacts of failing to test, however, are a significant erosion in the investment made in developing a technology recovery solution.
Failure to exercise plans and people, or only ‘testing’ once a year, leaves an organisation and its recovery capabilities unprepared for an actual incident. Any organisation that’s invested in a technology recovery capability should rigorously assess and validate that capability,
especially in the initial two-three years after implementation.
2. Divergence of recovery and production configurations
An organisation’s production environment continually changes. Whether that’s due to hardware or software updates, the addition or removal of systems, or configuration changes, the divergence from the recovery solution (technology, plans, procedures) grows wider and wider with each change, increasing the chance of the failure of the solution. The maintenance of the technology recovery solution – both plans and recovery configurations – should be kept in lock-step with the production environment.