The final flaw may be the most critical. A BIA typically is a static report whose data reflects the business’ needs at a specific point in time. Once the report is presented to management, it is usually put on the shelf to gather dust until the next refresh…two or three years from now. But gaining management’s commitment and prioritizing recovery requirements for planning purposes is possibly the least important use for this data.
Instead, this data must be kept evergreen and should be immediately available at-time–of-disaster to dynamically model cross-process dependencies to determine the ripple-effect of the event-specific impact; and, to “calculate” in real-time, the dynamic recovery plan to address the specific loss profile for the specific event given its specific damage and impact relative to the specific timing of the event while taking into account the then available tools and resources available for mitigation and recovery efforts. And, if you are unlucky enough to have another disaster on the next day, at a different location, with a different impact profile, you should be able to model a completely different plan for a completely different mitigation and recovery effort…once again in real-time.
The days of “all or nothing” plans and “smoking hole” disasters are long past. This dictates that the BIA must be a tool not a static report—regardless of how good that report might be. The tool must contain all of the recovery objectives, needs and resources correlated by location, department and process. It must be able to interactively illustrate the unique recovery priorities and sequences based on the actual loss from the specific event. It must be able to support decision making at time of disaster by clearly illustrating increasing impact relative to time and the corresponding degrading effectiveness of manual procedures. And it must be able to facilitate dynamic reassignment of recovery resources based on current needs and priorities.
It’s time to dump the traditional BIA!
