Skip to main content

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Contingency Plan (CP)

Identifies activities, resources, procedures, and personnel to use during interruptions to operations

Contact: CISO Team | CISO@cms.hhs.gov

What is a Contingency Plan?

Contingency planning at the Center for Medicare and Medicaid Services (CMS) is essential for protecting the organization from potential risks and ensuring the continuity of its operations. A Contingency Plan is the cornerstone document of contingency planning, and every CMS system must have one in place. The Contingency Plan provides a framework for responding to and mitigating the effects of unexpected events, such as natural disasters, data breaches, and public health crises. 

Contingency Plans outline risk management strategies, such as crisis management protocols, data backup and recovery procedures, business continuity plans, and roles and responsibilities. 

The plans generally include one or more of the following approaches to restore disrupted services:

  • Restoring information systems using alternate equipment in case of an equipment failure
  • Alternate data processing means 
  • Alternate location(s) in case of a natural disaster 

Contingency planning also involves establishing clear communication channels between CMS and its stakeholders, such as healthcare providers, patients, and the general public. By being prepared for potential risks, CMS can ensure that its operations remain uninterrupted and that its stakeholders are kept informed of any changes.

Federal guidance for Contingency Plans

CMS utilizes guidance provided by the National Institute of Standards and Technology (NIST) SP 800-53 and the Federal Information Systems Management Act (FISMA) to inform its internal Contingency Planning process. FISMA defines three security objectives for information and information systems:

Confidentiality 

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Integrity 

Guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity. 

Availability 

Ensuring timely and reliable access to and use of information. 

CMS’s Information Security and Privacy Group (ISPG) has also identified all controls relevant to the Contingency Planning process for CMS systems in the CMS Risk Management Handbook Chapter 6: Contingency Planning (CP). You can use this document to inform your Contingency Planning efforts.

Read more about Contingency Plans

Get the specifics about the processes and policies that govern the Contingency Planning process in Chapter 6 of the Risk Management Handbook.

Take me to RMH Chapter 6

Contingency Plan prerequisites

System impact level

Before you start your Contingency Plan, it is critical that you review NIST’s guidance on Federal Information Processing Standards (FIPS) Publication 199 and understand the impact level of the system you are creating the plan for. There are three impact levels defined by NIST that relate directly to the security objectives outlined above for all FISMA systems

A low impact level occurs when the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: 

  • Cause an interruption to mission capability, but CMS is still able to perform its primary functions 
  • Effectiveness of functions is noticeably reduced
  • Result in minor damage to organizational assets
  • Result in minor financial loss
  • Result in minor harm to individuals

A moderate impact level occurs when the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: 

  • Cause a significant deterioration of mission capability, but CMS is still able to perform its primary functions 
  • Effectiveness of functions is noticeably reduced 
  • Result in significant damage to organizational assets
  • Result in significant financial loss
  • Result in significant harm to individuals that does not involve loss of life or serious life threatening injuries

A high impact level occurs when the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: 

  • Cause a severe degradation in or total loss of mission capability 
  • The organization is not able to perform one or more of its primary functions
  • Result in major damage to organizational assets
  • Result in major financial loss
  • Result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries

Business Impact Analysis

The Business Impact Analysis (BIA) is an essential part of the Contingency Planning process. It helps System/Business Owners identify preventative actions required to mitigate risk, and the resources available to keep systems safe. The ISSO coordinates with the System/Business Owner to identify key processes and determine how critical they are to overall system functionality. This effort will result in a completed BIA. 

BIAs serve as the primary requirement document for determining the key recovery metrics that are addressed in the Contingency Plan including: 

  • Recovery Point Objective (RPO)
  • Recovery Time Objective (RTO)
  • Maximum Tolerable Downtime (MTD)
  • Work Recovery Time (WRT)

The goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime (MTD). Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods. 

Who makes the Contingency Plan? 

Contingency Planning involves cooperation between every person on a system team including the System/Business Owner, the Information System Security Officer (ISSO), the system’s data center or hosting facility, and senior CMS leadership. 

Specifically, System/Business Owners and ISSOs play an integral role in the development and maintenance of Contingency Plans for FISMA systems at CMS.

  • Develop, distribute and maintain Contingency Plans for their systems 
  • Review all Contingency Plans at least once every 365 days and/or whenever there is a significant change to the system 
  • Ensure each plan is tested at least annually
  • Review and correct plan deficiencies in a timely manner
  • Ensure all personnel with recovery responsibilities are trained in recovery preparedness 
  • Ensure each contingency plan is distributed to all personnel
  • Ensure a copy of the most current CP is maintained at the alternate processing location
  • Should an event occur, contact recovery team members 
  • Escalate to senior management depending on the severity of the event 

  • Work with System/Business Owners to create a Business Impact Analysis (BIA)
  • Collaborate with System/Business Owners to review and update Contingency Plan annually
  • Document Contingency Plan testing results with System/Business Owner
  • Observe all exercises and document instances where appropriately trained personnel were unable to complete the necessary recovery procedures
  • Address any findings from Contingency Plan testing by creating a Plan of Action and Milestones (POA&M)

How to create your Contingency Plan

With your system impact level and BIA in hand, you can now begin the process of completing your Contingency Plan. 

NIST provides Contingency Plan templates that address the specific security controls for each of the three different FIPS 199 impact levels – low, moderate, or high. The templates serve as guides and can be customized to fit the system or organizational requirements for the Contingency Plan that you and your team are working on. 

Low template:

Use this template for your Contingency Plan if your system’s impact level is LOW. 

Take me to the low template

Moderate template:

Use this template for your Contingency Plan if your system’s impact level is MODERATE. 

Take me to the moderate template

High template:

Use this template for your Contingency Plan if your system’s impact level is HIGH. 

Take me to the high template

Steps to create your Contingency Plan

Here are the steps required to create your Contingency Plan:

  1. Create Contingency Plan document

    Select the Contingency Plan template that corresponds to your system’s impact level. Fill out the template, which will contain information specific to your system including:

    • Key recovery metrics for your system
    • Pre-defined descriptions of conditions that constitute a need for action
    • Pre-defined actions based on the severity of an identified incident
    • Key staff, contact information, and specific duties for each person
    • Item-level understanding of all of the system hardware and software
    • There should be no reference to other documents not included in your Contingency Plan (e.g. diagrams)
  2. System/Business Owner signs CP

    The Contingency Plan must be attested to (signed) by the FISMA System Owner annually.

  3. Get after action report

    After the test is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.  These deficiencies may be easily correctable, or may result in the creation of one or more Plan of Action and Milestones (POA&Ms). 

  4. Perform Contingency Plan testing

    The Contingency Plan must be tested at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one way to test the Contingency Plan. A test plan must be prepared and followed during the execution of the test. All staff who participate in an actual Contingency Plan event must be available for the test, and key staff members must be trained annually in their contingency responsibilities.

  5. Achieve Contingency Plan recertification

    After any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated Contingency Plan documents that they have access to (even away from the office or after hours). Destroy (or return) older copies.

  6. Plan for next year’s exercises

    It’s never too early to start planning for next year’s Contingency Plan exercises. Whether you’re engaging in a tabletop exercise or have chosen a different way to evaluate your plan, it’s important to leave plenty of time to complete the exercise so that your FISMA system remains compliant. If your FISMA system is involved in an outage that causes you to exercise the Contingency Plan, you should consider documenting the event as an exercise of your Contingency Plan. You can read more about exercising and testing your Contingency Plan in the CMS Contingency Plan Exercise Handbook.