Contingency Planning Strategy

By G. Mark Katibah and Charles H. Ufen

A bank’s contingency planning effort has one main goal: to get back to “business as usual” as quickly as possible, ideally within two days after a disaster. Quick recovery of processing capability may now be more difficult and take longer than when your bank’s recovery strategies were first approved by the board of directors.
In this article, we will propose a shift in corporate contingency planning strategy which not only reflects appropriate support for current business objectives, but also allows for the interdependency of bank product lines. The argument is directed mainly toward companies that already have a contingency plan and may now consider it timely to review and update their mainframe backup strategies. The benefits to be derived from reviewing the present strategy include creating the opportunity to determine how much backup is currently needed and identifying ways of spending contingency planning dollars more efficiently.
One strategy that your board of directors may have adopted as part of its original contingency planning program is to “provide off-premises mainframe computer capability.” The primary focus of providing mainframe backup capability is to ensure that the bank will be able to accomodate customers and that its products and services will be available as advertised.
We’ll suggest how this strategy may be enhanced to provide greater protection for your bank’s product line.

MAINFRAME RECOVERY STRATEGY

The mainframe computer continues to be the most critical operations component of a bank’s ability to conduct business. It is currently crucial for survival, and it remains the central point for data storage and information processing. The more automated and integrated a bank’s operations are, the more difficult it is to substitute manual or semiautomated activities for mainframe computer processing. The conventional approach to mainframe backup strategy is to document and test procedures to restore the mainframe operations at a remote processing center. Each test includes restoration of the main software systems and processing of selected applications as of a predetermined “disaster date.”
The typical programming department has the major responsiblity of developing procedures for backing up the application systems. Installation of such procedures preserves the account information and positions the bank to respond quickly to a disaster. The programming department also maintains a prioritized list of applications which is used in selecting systems for testing.
In most banks, considerable progress has already been made in developing and testing the mainframe recovery strategy. We are not suggesting that companies scrap their present recovery plans. We do suggest that the sequential development of recovery plans could be strengthened by making some changes in procedure.
We will introduce three recommendations for refining existing disaster recovery plans.

I. STANDARDIZE AND TEST BACKUPS FOR CRITICAL APPLICATIONS

The crux of the disaster recovery issue for a bank lies in the ability to restore operations in a timely manner. The timeliness factor must be emphasized, since it impacts customer impression and satisfaction, management, information, legal and regulatory compliance, and ultimately, market share.
Your bank may improve its chances for surviving a disaster by “standardizing” and testing backups for the “critical” applications. Critical applications are defined as systems that will have a higher recovery priority after a disaster strikes. Of course, recovery of the remaining systems will be completed in an orderly sequence after the disaster is contained. Standardizing, as used here, means that the same standard will be used for creating all data file backups.
Recovery of the applications can be made more efficient by developing and adopting a procedure to back up all application systems at the same stage of processing. For example, either back up the volumes before the day’s processing is started, or create the backups after processing is completed. Recovery will be impeded if the various volumes are backed up at different stages of processing.
Standardization of backups will ensure that account information is synchronized. Inherent in this concept is the requirement for zero generation backup. If the data file backups are one or more generations old, additional processing of one or two days of transactions will be needed in order to restore the data files to the disaster day.
The immediate impact of such additional processing may be to increase the restoration period to three to four days, or even longer. In that additional interval, prompt service to the bank’s customers may be jeopardized. This delay will occur because the bank is unable to post current transactions and deliver accurate information until the additional processing and adjustments to synchronize the data can be completed.

II. IDENTIFY THE CRITICAL BUSINESS PRODUCTS

Assess the criticality of the business products to determine what level of mainframe backup is appropriate for your operations. Verify that this backup is adequate to support only the processing of production work. Plan in advance to suspend all development and testing activities until complete recovery from a disaster is effected.
Next, develop criteria for identifying the “critical” business products. Following the standardization of all critical applications, involve the user departments in assessing the bank’s product line exposure. The goal of this analysis should be to determine which application systems will be regularly tested at the remote recovery site.
The assessment and testing process establishes a more accurate definition of the necessary computer hardware, storage and item processing capacity your bank requires in order to cover whatever level of risk it is willing or able to accept. This process also benefits the bank in another way by closely linking the perceived backup requirements to the real cost of providing them.
It is imperative that you involve the bank’s business units in this evaluation project. Besides the more obvious factors that determine criticality (such as the negative dollar impact on the bank if it has an unsupported product or a product whose recovery is delayed), there are other exposures. Some issues the business units can help wrestle with include the following:
a) Criticality may also be dependent on the time of day, day of month, and month of year at which the disaster occurs. The business units should help determine how the timing of a disaster could impact their products.
b) The term “critical” as related to disaster recovery is also a dynamic condition because the criticality of applications or products increases each day the recovery is delayed. The analysis of the applications and products should also identify the point at which the applications are (or will become) critical. This kind of analysis helps determine whether a data file backup is essential for ensuring the product’s recovery.
Another factor to consider is that an application will assume a higher level of criticality because of its interdependence. As application systems evolve, they tend to become interdependent because the output of one system becomes input for other applications. A single application may eventually support multiple products. The programming department should help identify the level of application interdependence and assist in defining the bank’s major outstanding recovery issues.

III. TEST PRODUCTS RATHER THAN APPLICATIONS

Focus on product rather than application testing. The broad goal of a viable backup plan should be to emphasize the restoration of the business products. This approach differs from the procedure generally followed where the object is to test several applications independently of one another. The preferred approach is to perform an interactive test chaining together multiple applications supporting one product, as during normal operations.
This revised form of testing should validate the workability of all application system backups that support the business products and will strengthen your bank’s ability to protect the interests of its customers. When planned well, the new procedure should not increase the costs of testing.

CONCLUSION

The present status of contingency planning is one of completed groundwork. At the typical bank that has a formal contingency plan, the foundation for attempting a successful recovery from a disaster is already in place. The next phase of planning should emphasize shortening the estimated recovery period, and move toward a “critical products” driven planning objective while keeping cost containment goals clearly in view. Success in controlling contingency planning costs will ultimately also benefit the bank’s shareholders.
The reorientation in emphasis should help your company revise its contingency planning program. This should lead to revitalizing each strategy for protecting the customer’s interests. Finally, the reorientation should improve your company’s chances of surviving a major data processing disaster.

Written by G. Mark Katibah and Charles H. Ufen, Contingency Planning Manager and Contingency Planner, respectively, NCNB National Bank.

This article adapted from Vol. 3 No. 4, p. 12.

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.