Year 2000 Contingency Planning
Contingency planning integrates and acts on the results of business
impact analysis. The output of this process is a business continuity plan
consisting of a set of contingency plans -- with a single plan for each
core business process and infrastructure component. Each plan should provide
a description of the resources, staff roles, procedures, and timetables
needed for its implementation.
Key Processes
3.1 Assess the cost and benefits of identified alternatives and
select the best contingency
strategy for each core business process
3.2 Identify and document contingency plans and implementation modes
3.3 Define and document triggers for activating contingency plans
3.4 Establish a business resumption team for each core business
process
3.5 Develop and document “zero day” strategy and procedures
Assess benefits, costs, and risks of alternative contingency strategies.
Select a strategy that is practical, cost-effective, and appropriate to
the organization. In addition, the alternatives and strategies should provide
a high level of confidence in recovery capability.
Three important factors in the selection process are
-
functionality: the degree to which the replacement functionality supports
the production of a minimum acceptable level of output for a given core
business process,
-
deployment schedule: the time needed to acquire, test, and implement, and
-
cost: life-cycle cost, including acquisition, testing, training, and maintenance.
The goal is to maximize the functionality and speed of business resumption.
3.2 Identify and document contingency plans and implementation modes
Develop a contingency plan including strategies capable of meeting minimum
acceptable output requirements for each core business process. Consider
the following strategies:
-
quick fix,
-
partial replacement,
-
full redundancy or replacement, and
-
outsourcing to the private sector.
Consider three basic implementation modes for the quick fix, partial, and
full replacement of functionality provided by failed mission-critical systems:
-
manual replacement,
-
semi-automated replacement, and
-
automated replacement.
A manual alternative normally requires hiring and training of additional
staff. It can be used to replace all or part of a failed automated process.
A semi-automated alternative can implement “bare bones” functionality,
using a combination of compliant off-the-shelf applications, such as accounting
software or standard database products. Some core business processes may
be fully supported by compliant off-the-shelf application packages that
can be purchased and rapidly installed. However, even projects that rely
on off-the-shelf replacement packages may fall behind schedules. Finally,
redundant business services may be provided through outsourcing contracts.
3.3 Define and document triggers for activating contingency plans
Once the business continuity planning team selects the best contingency
alternative for each core business process, it must then define triggers
that would implement each plan. The information needed to define the implementation
triggers for contingency plans is derived from two key sources:
-
the deployment schedule for each contingency plan and
-
the implementation schedule for the renovated or replaced mission-critical
systems.
The deployment schedule establishes the date at which the contingency plan
must be implemented if is to be to be fully tested before December 31,
1999. For example, if the contingency plan calls for an 8-month deployment
schedule, the tentative implementation date should be set for April 30,
1999.
3.4 Establish a business resumption team for each core business process
Work with core business process owners to establish business resumption
teams. These teams would be responsible for managing the implementation
of contingency plans and would deal with a wide range of operational problems,
including the potential failures of systems thought to be renovated and
tested, and the potential failures of external systems and data exchanges.
3.5 Develop and document “zero day” strategy and procedures
Develop a risk-reduction strategy and procedures for the period between
Thursday, December 30, 1999, and Saturday, January 1, 2000. This strategy
may include an agencywide shutdown of all of its information systems on
Friday, December 31, 1999, and a phased power-up on Saturday, January 1,
2000. The agency may consider extending the shutdown to infrastructure
systems, including local area networks, elevators, and building management
systems.
Overview| |Initiation|
|Business Impact Analysis| |Contingency Planning|
|Testing
The Disaster Center Year 2000
Page| |The Disaster Center Index Page
Formated from text provided by: The United States General
Accounting Office Accounting and Information Management Division HTML format
Copyrighted by The Disaster Center 1998