MUSC Information Security Standards: Contingency Plan

Author: Bill Rust
Version: 0.3
Date: 03 May 2005
Status: DRAFT


1. Purpose and Scope

The purpose of a contingency plan is to document the specific procedures and activities necessary to (a) reduce recovery and business continuity risks to acceptable levels, and (b) meet all legal, regulatory and policy requirements. These standards apply to all MUSC information systems for which contingency plans are required by applicable policies.

A contingency plan involves establishing and maintaining set of procedures and record keeping activities intended to ensure that information systems and their data are recoverable in the event of major system failure or disaster, and to safeguard the continuity of mission-critical business operations (including academic, patient care, administrative, financial, and infrastructure systems) during such events.

2. Applicable MUSC Policies

3. Standards

3.1. Who is responsible for a system's contingency plan?

The designated Owner of each information system in the MUSC enterprise is required to develop and maintain a contingency plan.

3.2. Are contingency plans required for all MUSC systems?

The Owner of every information system within the MUSC enterprise is required to ensure that contingency plans are implemented and maintained, to reduce risks to reasonable and appropriate levels, and to comply with MUSC's business continuity priorities, applicable laws, regulations, and policies.

3.3. Must all contingency plans be documented?

It would be unreasonably burdensome for MUSC to require documented contingency plans for every system within the MUSC enterprise, regardless of the size, purpose, or nature of the system, or the environment in which the system is used. MUSC requires a documented contingency plan for only those systems that meet one or both of the following criteria:

  • Protected information is stored by the system
  • The system has been formally designated as a critical system

Protected information is defined in the Information Security policy as “information that, because of its criticality, its sensitivity, and/or legal or regulatory requirements, requires special safeguards.” A documented contingency plans is required for any system that stores protected information. Certain other systems, even though they do not store any protected information, may nevertheless be designated as critical systems by the Office of the CIO; documented contingency plans are also required for these designated systems.


The Owner of a system that does not meet either of the above criteria is still expected to consider contingency planning and to document and implement appropriate procedures, but MUSC does not require formally documented contingency plans for such a system, and MUSC will not require the Owner of such a system to meet the documentation standards in this document (3.6. What needs to be documented in a contingency plan?, 3.7 Should contingency planning documents be shared or published? and 3.8 Is there a retention period for contingency plans?).

3.4. When do contingency plans need to be created and/or updated?

Contingency plans need to be developed and/or updated at different points in a system's life cycle:

  1. Pre-Implementation stages: Contingency plans need to be considered during both the planning (initiation and approval) stage, and the procurement and/or development stage. There needs to be consideration for appropriate system failover capability, and data protection, backup and recovery systems.
  2. Implementation stage: Completion of a contingency plan should be one of the deliverables in the project plan for implementing the system.
  3. Production stage: Periodic review is required whenever there are environmental, operational, policy or regulatory changes that substantially affect the system. Contingency planning is a process that is ongoing throughout the system’s life. It should be maintained such that it is current and will be effective in case of need.

3.5. Who should participate in contingency planning?

The System Owner must ensure that the contingency planning team has members whose collective knowledge of the (planned or production) system, whose knowledge of the organization, and whose understanding of applicable policies and regulations, are sufficient to enable the team to identify potential points of failure, assess risks associated with downtime, analyze potential countermeasures (fail-over, mirrored site, etc.), specify an optimal set of countermeasures if any, and communicate their recommendations to management.

A system's contingency plan must mesh with the contingency plans, business continuity plans, and disaster preparedness and recovery plans for the business unit(s) that the system supports. The System Owner must ensure that his contingency planning team has the organizational knowledge and the contacts needed to ensure coordination with these other planning efforts.

3.6. What needs to be documented in a contingency plan?

The following core information must be included in any documented contingency plan:

  • System Information – The name of the System and its designated Owner.
  • The effective date of the contingency plan, the names and roles of the participants in the plan creation/update, and the name(s) of the plan's principal author(s)
  • General Description – Describe the system, or host, and the service or function that it provides. Describe the purpose of the system in relation to MUSC's missions, and a concise description of the system's major function(s). Describe the departments or groups served by this system as applicable. Describe time frames and operational hours of the system.
  • System Administrator(s) Responsible - Identify the system administrator, his or her team if applicable, and his direct manager. Also list other personnel and management with significant roles in the administration and operation of the system.
  • Persons Responsible for maintaining the system contingency plan.
  • Classification of the system in terms of sensitivity and criticality.
  • Dependencies on other systems (excluding power and conditioned physical space) – Specify any dependencies that this system has for full and effective operation.

Additional documentation standards are listed below for each of the major procedural areas that should be addressed in a system contingency plan.

Beyond the core information given above, and the standard procedural areas given below, the specific business requirements of the system itself may require additional elements to be included in the system contingency plan.

3.6.1 System Recovery Procedure Requirements

The System Owner should include all necessary information on hardware, software, documentation, skill set, data recovery procedure, order of actions and other procedures necessary to recover from a disaster or other adverse event. This document should be reviewed by appropriately skilled staff to verify its completeness and understandability. Required System Specifications

The System Owner should fully document the specific resources required to restore or re-create the system in the event that it were completely destroyed or damaged beyond repair. Such documentation should include:

  • Skilled personnel required
  • Hardware
  • Software
  • Configuration specifications
  • Environmental specifications
  • Backup information
  • Other pertinent and necessary information for full recovery. Required System Recovery Approach

The System Owner should document the detail narrative instructions for accomplishing system recovery. These instructions should include details necessary for recovering from different scenarios as follows:

  • Level I - Target system affected but not the supporting infrastructure;
  • Level II - Localized building/room infrastructure affected (e.g. computer room damaged as well as target system);
  • Level III - Area affected (Charleston).

While it is not necessary to address these three levels specifically, it is necessary to include enough instruction to deal successfully with Levels I and II. Some mission-critical systems may be required to include a viable plan for a Level III disaster. Required Order of Actions / Steps of Recovery

The System Owner should document the procedural steps for recovering the system. Steps should contain enough detail so that given the personnel with the skills specified above, a successful system recovery can be accomplished.

3.6.2 Downtime Procedures

The System Owner should document the specific procedures to be followed and resources available in the case of system downtime. If there are alternate methods to meet the need of the end-user they should be specified in the downtime procedures. The plan should also specify the events, conditions and/or circumstances that will trigger the use of downtime procedures.

3.6.3 Communication Plan

The System Owner should document the plan for communicating system status and related information to the end-user community and management. This should include the plan for communication during downtime.

3.7 Should contingency planning documents be shared or published?

The System Owner must provide a copy of each documented system contingency plan to his organizational entity's Information Assurance Compliance Officer (IACO).

The System Owner must carefully control the distribution of all contingency planning documents. Because they contain sensitive information about the system they should be shared only with authorized personnel, and only on a need to know basis. Contingency plans should not be published except in the context of official MUSC contingency planning documentation.

3.8 Is there a retention period for contingency plans?

The System Owner must retain all documents and records related to system contingency plans for a minimum of six years.

3.9 Is testing of contingency plans required?

The System Owner is not required to test all aspects of the contingency plan since complete testing could be significantly disruptive to ongoing operations and/or prohibitively expensive. However, it is expected that reasonable measures will be taken to regularly test aspects of the plan to achieve acceptable levels of confidence that the plan is viable.