Protecting the Enterprise: Seven Steps to Safety

Every organization that depends upon its computers lives in fear (or should) of losing its systems and data. What would happen if the purchasing system could not purchase just when you needed to buy critical supplies? What if the email system went down just as you were about to deliver critical documents to a customer? What if the PC that collects time sheet data and transmitted them to a payroll service crashed just as you were about to transmit? And what if your proposal system with its cost basis was lost the long, last night before delivery.

Any one of these would be a disaster - unless steps were put into place before the disaster to provide quick recovery in time to meet deadlines. This column is about those steps you need to take to protect yourself. There are seven steps to achieving a plan that protects you in case failures or other disasters strike.

These seven steps help you determine what to protect, what could make things fail, how do you recover the things you want to protect, how you make certain your plan will work, and how you keep the plan current. In our seminars, we spend a full day discussing these steps in detail (our next seminar in Raleigh, NC, is on May 28, 1997). In this column, I present some basic thoughts on how to accomplish these goals.

Step 1: Perform a Business Impact Analysis

The purpose of a Disaster Recovery Plan is to protect operating capabilities in case of a disaster. The first step is to determine which operating capabilities are most important and need fast recovery and which are less time sensitive and can wait a few days or weeks.

Traditional methodologies use complex algorithms and models to assess which functions are more critical and time sensitive than others. For most of us, these models take too long and are too cumbersome to use. The Miora Cost Consequence™ Model (described here in September 1996) uses a simplified set of measures for a fast, decisive analysis that quickly ranks the functions.

Step 2: Build a Threat/Risk Analysis

Many traditional planners develop threat and risk models. These models establishe that probabilities that certain events will occus within established time frames with expected results. We believe this is unnecessarily complicated. Instead, we investigate disaster and failure based on their effects rather than their types and probabilities. A quick analysis will show what consequences can be expected - those consequences become the threats against which we protect. This simple approach can save weeks or months of analysis paralysis.

Step 3: Develop a Recovery Strategy

With a set of threats against which to protect specified functions at our fingertips, we can now develop recovery objectives and identify emergency measures to put in place. We focus on key functions first and find ways to use small computers to do big jobs for short durations. This is the Reserve System concept we pioneered to lower costs by minimizing hot site requirements.

In many plans, hot sites are specified for recovery of mainframes, midrange computers and even LANs. While these sites are clearly necessary for disasters with long lasting effects, we can often minimize hot site needs for the short term. Therefore, even if the disaster has longer lasting effects, the hot site timeline can be stretched and the associated costs drastically reduced. Cost savings of more than 50% are common.

Steps 4 and 5: Identify Recovery Activities and Build Procedures

In these two steps, we define the disaster scenarios and determine the required activities required to achieve temporary operational capabilities. Then we translate those activities into specific procedures to be used by members of the disaster recovery teams. During this process we can often discover preventive measures for records, systems, and operating capabilities so we minimize susceptibility to outages.

Steps 6 and 7: Test and Maintain the Plan

Once the plan is in place, we must test the plan. However, unlike automobile crash tests that use test vehicles or software development efforts that use test systems, our operational systems make poor guinea pigs. Test the plan on the operational systems and a failure can have repercussions as great as a disaster itself. There are special ways to conduct tests so that normal operations will not be affected regardless of the test's outcome. These include walk-throughs, table top exercises, drills and rehearsals. Each has its own goals and benefits.

Conclusion

Protecting your organization is important, and modern tools and techniques make it affordable. You can find ways to protect yourself even if you are a small company - or a big company with a small budget.