Y2K Site Map | Terms of Use | Problem | Steps | Certification | Briefings | Compliance | Solutions | BIOS | Test & Evaluation | Cost
The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
| Y2K Contingency Plan Guidelines |
Although everyone is working diligently to ensure that a high percentage of Year 2000 (Y2K) and related problems will be resolved before their respective Time Event Horizons, we must anticipate that some things will be overlooked, ignored, or not completed on time. We also realize that there are things beyond our control that could affect us in the year 2000. One important way to be sufficiently prepared is through the development and application of well-defined and executable contingency plans.
As a first step, you should become familiar with the minimal activities that need to be addressed in developing a contingency plan by reading through our Y2K Contingency Management Plan Outline. Then take a look at Sample Content of a Contingency Plan which details the types of information to be included in each section of your plan. With less than a year left before the turn of the century, the development of
these contingency plans must begin immediately, with proper training
soon to follow. The objective of this guidance is to ensure that the following minimum requirements are considered when developing a contingency plan.
There will not be enough time and/or money to fix everything.
As triage principles are applied, some low priority systems will not be fixed at all. Similarly, some medium priority systems may
not be thoroughly tested. Finally, some mission critical systems
may still have errors, even after thorough testing, just due to
complexities and oversights.
Also, some solutions may not be available or work in time because
they were overlooked, too complex, too costly, or implemented
incorrectly. Further, it is impossible to ensure that all other
organizations interfaced with externally have fixed their systems.
Consequently, an organization's systems may be "infected"
by bad data from other organizations and their systems.
Most organizations already have Contingency Plans for natural
disasters and other types of contingencies. However, the difference
for Year 2000 and related problems is that the potential widespread
and simultaneous nature of failures is such that traditional backup
or alternatives strategies may falter.
There are two types of contingencies to be addressed by each Contingency
Plan: Programmatic and Mission-oriented. See the figure below.
The first type would necessitate workarounds to be used in advance of the earliest Time Event Horizon, such as to overcome a perceived lack of time to complete remediation. This is the first type of contingency planning requested by OMB in their 15 November 1997 Progress on Year 2000 Conversion Report. See the third underlined item under the "Government-wide Issues" section,"Planning for Contingencies." The second type, also
requested, would necessitate steps to cope with the actual onset
of operational problems at some Time Event Horizon. Each corresponding
section of the Plan, Programmatic and Mission-oriented, has an
appropriate focus of risk management, and both are integrated
into a coherent, single Contingency Plan.
The Programmatic Section details the plans for system remediation
management, and is closely allied with what has been termed "triage"
management. This section is prepared by systems developers, operators,
and maintainers in consultation with users. It addresses the actions
to be performed by systems developers, operators, or maintainers
in advance of a foreseen Y2K related contingency. An example of
this sort of contingency is when, say in late 1998, it is discovered
that some previously overlooked code has serious problems and
there is no time left, given its priority, to fully remediate
all the problems.
On the other hand, the Mission-Oriented Section deals with operational
risk management. This functional section is prepared by systems
users in consultation with developers, operators, and maintainers.
It addresses the actions to be performed by the users immediately
before, during, and immediately after a Y2K related contingency.
Examples of this sort of contingencies include power outages,
system crashes, bad data, loss of communications, and the like.
The two sections must be closely coordinated. Relevant contingency
information should be exchanged with system managers of those
systems that interface with each system and also with all system
users.
In addition, it is understood that there could be higher-level contingency plans aimed at permitting an organization to carry out its assigned missions in spite of any evolving Y2K problems among its systems and means of communication. For guidance and samples of this type of Organizational Contingency Plan for Year 2000, please see the August 1998 Year 2000 Computing Crisis: Business Continuity and Contingency Planning [GAO/AIMD-10.1.19 in PDF], Best Practices Chapter VI - Contingency Planning, and SSA's Year 2000 Business Continuity and Contingency Plan.
The scope of the plans must be clearly stated, including expected
contingency duration, for both Programmatic and Mission-oriented
contingencies. Priorities must be carefully defined, established,
and agreed to by all parties concerned. Early on, costs estimates
to set up and implement the plans should be developed and considered
for possible trade-offs. The responsibilities for developing and
maintaining each Contingency Plan must be established, as well
as time period between major reviews. Continued Contingency Plan
maintenance will be tracked through each organization's validation
process. The existence of an approved Contingency Plan is a requirement
to be considered certified in many organizations. Finally, because
of their importance, Contingency Plans should be dated, signed
and promulgated at a high level within the organization.