"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 organizations 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 organization 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 organizations 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 organization and its recovery capabilities unprepared for an actual incident. Any organization 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 organization'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.
One only has to look at the amount of preparation, documentation updates and contract upgrades that occur in support of an exercise to see there's a significant divergence which can occur over a fairly short period of time. All these factors can negatively impact recovery results.
3. PROCEDURES NOT DETAILED
As much effort as is put into plan development, it's surprising how many companies do not have sufficient detail in their recovery procedures that will support the recovery of their key technologies. Even companies that test often abandon their plans and instead rely on the knowledge of their people, or use their plans but never add the detail they need. This may be worse than not testing at all, since it creates the perception the plan will support a recovery; however, if the primary team isn't available during the incident, recovery can be challenging without access to that intellectual knowledge base.
4. REQUIRED INFORMATION NOT CONSOLIDATED CONSOLIDATED IT
Organizations often have data relevant to recovery in a number of places – such as in their Configuration Management Data Base (CMDB), ticketing system and shared file space – and there is often a reluctance to consolidate that information and align it with the plan. Organizations need to find the balance between duplicating information or creating two potential sources of record to ensure that there is one cohesive, coherent view of the documentation/information needed to support a recovery (and access to that information immediately at time of need).
Organizations should use their plans to create the overall consolidated view of the recovery management process, including timeline, milestones, and detailed 'order of operations.' They should use that framework to point to other data sources needed - assuming they can be made available at time of need. If information or documents are needed immediately and won't be available, then they have to be incorporated in the plan.
5. ORGANIZATIONAL READINESS
"Plans are useless; Planning is everything" - Dwight Eisenhower.
It is the process of planning that creates value and enables organizational readiness, yet too often organizations ignore that and focus on the development of a document. The teams that must be there at time of need have to be deeply involved in developing the recovery strategy and plan. Furthermore, the need to continue the organizational learning through exercises and ongoing, continual engagement of the team is necessary for success.
Investing in a recovery capability means a long-term investment in not only technologies and the development and maintenance of the plan, but also - and mainly - the development and enhancement of an organization readily respond to a significant business disruption.
Related Business Solution: Find out more about IT disaster recovery
