There are many factors that account for a lukewarm approach to confronting the risks that may potentially compromise a business organization. The tendency is to consider the likelihood of a September 11 disaster, but there are many other and more likely sources of disruption that may no be as devastating but that can just as easily compromise your business operations.

We cannot suggest a good way to deal with the loss of life, such as occurred on September 11. The goal of Business Continuity Planning is to help your company survive for the benefit of survivors of a disaster event. Otherwise, people may survive a disaster as unemployed ex-employees, which is not the goal of running a business, and it also does not consider the ripple effect this might have on other businesses that you interact with. We performed BCP analyses in the expectation that risks were limited, but we have learned how vulnerable businesses can be in one horrific act of terror. For example, earthquakes are rare here in Ontario, but it may give you pause to learn that a Nuclear Generating Station was constructed right on top of a fault line. We now know what happens if the power goes off for a couple of days.

We developed a methodology called "BIRP" (Business Interruption Response Planning) that emphasizes actions required at specific times following different classes of incidents. It also considers preventive opportunities (what you can do to lower the risk and/or to lower the consequences) that should be considered as part of new application software development. Like any other methodology, BIRP is meant to be a guideline to direct the process of BCP risk analysis and BCP contingency plan preparation, and it recognizes that different companies need different variations of a basic need for Business Continuity Planning.

Account for risk exposures and company projected losses that may result if a risk materializes. Some companies have more at stake than others, some have more exposure to risks than others, and some have more opportunity to mitigate risks than others. Since September 11 we are acutely aware that some risks have become less random, because that disaster was triggered not due to natural causes but due to a sick ideology. Terror can be directed at a company accused of somehow frustrating some faction. It will also affect other companies that share the same space, or companies that occupy a building next door. Terror can be directed geographically, with some areas more vulnerable than others, and it has made the whole notion of business continuity more complex. We collected a library of possible causes of disasters and their likely consequences in general as a checklist to evaluate potential risk exposures of a company. Some risks you learn to live with, such as hurricane exposure on the Gulf coast, or heavy snowfall in Canada. Other risks are so devastating that no matter what you tried the company would not recover.

We use the level of probability, the level of consequences, and the level of affordable prevention, as keys to the feasibility of the appropriate response strategy. In most IT projects there is proper mitigation of most risks by providing sufficient offsite backup copies of critical data, and a proper process for the rollout of a backup system in a short time following the disaster. More complex are the issues of how you deal with the human aspects of accessing and working with systems that are operating in a backup mode, possibly for the duration of a lengthy reconstruction of the original operating premises.

We learn to identify different levels of "disaster" that require different levels of response in order to enable the company to recover. There is a minimum level of "disaster" below which the company is best advised to go with the flow. A power failure, that you can expect to be repaired soon, is one such example where most companies simply wait for the power to be restored. If you have lots of inventory in freezers you have only a few hours before the loss of power becomes costly, and some form of backup power would be good to have (as many grocery stores can tell you). We studied BCP analyses and developed a methodology to establish plans and checklists to be invoked for this and other such incidents. There are software tools that help you manage a contingency plan crisis.

We believe that the major contributor to a costly recovery is confusion at the time the disaster is first recognized. Documenting "who does what and when" is critical in order to invoke the right initiatives to mitigate the impact of the problem. It is important to express the plans generically, because people change roles, or they leave the company, and it may not be obvious who fills specific BCP roles after a reorganization of the different departments. Action plans include "rescue", "recovery", "restoration", and "resumption" scenarios that reflect a number of different disaster severity assumptions. The contingency may result in collocating a business process with other business processes to resume processing as soon as possible by using an alternate venue. In most cases, a lot of things have to happen to make it possible to do that, things that must be pre-planned and pre-approved for just such an emergency. Operating management must then be empowered to initiate the contingency operations in time to mitigate the problems and to return to near normal operating conditions.