CMS Information System Contingency Plan (ISCP) Handbook

What is an Information System 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. An Information System Contingency Plan (ISCP) is the cornerstone document of contingency planning, and every CMS system must have one in place. The ISCP provides a framework for responding to and mitigating the effects of unexpected events, such as natural disasters, data breaches, and public health crises. 

The ISCP outlines risk management strategies, such as crisis management protocols, data backup and recovery procedures, business continuity plans, and roles and responsibilities. 

The plan generally includes 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 planning

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 Acceptable Risk Safeguards. You can use this document to inform your contingency planning efforts.

Roles and responsibilities 

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 Information System Contingency Plans for FISMA systems at CMS. For specific responsibilities of various roles, refer to the CMS Information Systems Security and Privacy Policy (IS2P2).

ISCP prerequisite: BIA

Before you start creating or updating your Information System Contingency Plan, you need to complete a Business Impact Analysis (BIA). Without this crucial document included as an appendix, your ISCP will be incomplete.

What is a Business Impact Analysis (BIA)?

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 ISCP 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. 

The following information should be used to create the system BIA. Once the BIA is completed, it must be included as an appendix to the ISCP and reviewed annually. When it’s time to review and recertify your ISCP, you must attach the BIA as an appendix again, even if the BIA hasn’t changed from the previous year.

BIA template

Use this sample template to perform your Business Impact Analysis (BIA) and create a BIA document as part of your contingency planning process. This template is meant to be a guide that can be adjusted to best meet the needs of your system. 

In this template, words in italics are instructional and are meant to be deleted from the final document. Words in regular (non-italic) text are intended to remain. Copy and paste the BIA instructions and template below into a document to begin your BIA process. 

Overview

This Business Impact Analysis (BIA) is developed as part of the contingency planning process for the {system name (system acronym)}. It was prepared on {insert BIA completion date}.

Purpose

The purpose of this BIA is to identify and prioritize system components by correlating them to the mission / business processes the system supports, and using this information to characterize the impact on the processes if the system were unavailable.

The BIA is composed of the following three steps:

1. Determine mission / business processes and recovery criticality. Mission / business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum that an organization can tolerate while still maintaining the mission.
2. Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission / business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
3. Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can more clearly be linked to critical mission / business processes. Priority levels can be established for sequencing recovery activities and resources.

This document is used to build the {system name} Information System Contingency Plan (ISCP) and is included as a key component of the ISCP. It also may be used to support the development of other contingency plans associated with the system, including the Disaster Recovery Plan (DRP) or Cyber Incident Response Plan.

System Description

Provide a general description of system architecture and functionality. Indicate the operating environment, physical location, general location of users, and partnerships with external organizations/systems. Include information regarding any other technical considerations that are important for recovery purposes, such as backup procedures. 

Diagrams of architecture, inputs / outputs, and telecommunications are not required as part of the BIA. Those are provided in Appendix G for ISCPs at CMS.

Mission and business processes

To complete this section, you will work with input from users, managers, mission/business process owners, and other internal or external points of contact (POC), to identify the specific mission/business processes that depend on or support the information system. To collect all this information, you can use interviews with individuals or groups, workshops, email, questionnaires, or any combination of those methods.

In later sections, you will also identify the criticality of those processes.

An example of a mission/business process and description is below. Create your own list for the system that needs the BIA.

Sample Mission/Business Process: Pay vendor invoice

Sample Description: Process of obligating funds, issuing check or electronic payment, and acknowledging receipt

The following list outlines the mission / business processes for {system name}.

Mission/Business Process:

Description:

(add more as needed)

Outage Impacts

This section identifies and characterizes the types of impact categories that a system disruption is likely to create in addition to those identified by the FIPS 199 impact level, as well as the estimated downtime that the organization can tolerate for a given process. 

Impact categories should be created and values assigned to these categories in order to measure the level or type of impact a disruption may cause. An example of cost as an impact category has been provided below. Organizations should consider other categories like harm to individuals and ability to perform mission. Create as many categories as you need to reflect what is appropriate for your organization.

The following impact categories represent important areas for consideration in the event of a disruption or impact.

Sample impact category: Cost

Sample values for assessing category impact:

• Severe = Temp staffing, overtime, fees greater than $1 million
• Moderate = fines, penalties, liabilities potential $550K
• Minimal = new contracts, supplies $75K

Impact category: {insert category name}

Impact values for assessing category impact:

• Severe = {insert value}
• Moderate = {insert value}
• Minimal = {insert value}  

(add more categories and their values as needed)

The table below summarizes the impact on each mission/business process if {system name} were unavailable, based on the following criteria:

Estimated downtime 

Working directly with mission/business process owners, departmental staff, managers, and other stakeholders, estimate the downtime factors for consideration as a result of a disruptive event.

The following are the downtime factors considered in the result of a disruptive event for {system name}.

• Maximum Tolerable Downtime (MTD).  The MTD represents the total amount of time leaders/managers are willing to accept for a mission/business process outage or disruption and includes all impact considerations.  Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content. 
• Recovery Time Objective (RTO).  RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD.  Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.
• Recovery Point Objective (RPO).  The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data must be recovered (given the most recent backup copy of the data) after an outage.   

The list below identifies the MTD, RTO, and RPO (as applicable) for the organizational mission/business processes that rely on {system name}.

Values for MTDs and RPOs are expected to be specific time frames, identified in hourly increments (e.g., 8 hours, 36 hours, etc.)

Sample Mission/Business Process: Pay vendor invoice

• MTD: 72 hours
• RTO: 48 hours
• RPO: 12 hours (last backup)

Drivers for MTD, RTO, and RPO: For each Mission/Business Process, include a description of the drivers for the MTD, RTO, and RPO (e.g., mandate, workload, performance measure, etc.). Include a description of any alternate means (secondary processing or manual workaround) for recovering the Mission/Business Processes that rely on the system. If none exist, so state.

Mission/Business Process:

• MTD:
• RTO:
• RPO:

Drivers for MTD, RTO, and RPO:

Resource Requirements

The following list identifies the resources that compose {system name} including hardware, software, and other resources such as data files. It is assumed that all identified resources support the Mission/Business Processes identified above unless otherwise stated.

Sample System Resource/Component: Web Server 1

• Platform/OS/Version: Optiplex GX280
• Description: Website host

System Resource/Component:

• Platform/OS/Version:
• Description:

Recovery priorities for system resources

The list below shows the order of recovery for {system name} resources. The highest priority resources are listed first. The list also identifies the expected time for recovering the resource (RTO) following a “worst case” (complete rebuild/repair or replacement) disruption.

Sample Priority Resource: Web Server 1

• System Platform/Component: Optiplex GX280
• Recovery Time Objective (RTO): 24 hours to rebuild or replace

Priority Resource:

• System Platform/Component:
• Recovery Time Objective (RTO):

ISCP steps

With your BIA complete (and ONLY when it’s complete!), you can begin the process of creating or updating your Information System Contingency Plan. If you already have a completed BIA from the previous year, review it for accuracy and update if needed. Attach it as an appendix to the ISCP regardless of whether updates were made.

Guidance for each step is listed below.

1. Create or update ISCP document

To create your ISCP document, use the ISCP template provided for use by all CMS FISMA systems. This template is adapted from the NIST ISCP template for High risk level systems. This ensures that all ISCPs for CMS systems meet or exceed compliance requirements for contingency planning.

Using the template to create your own ISCP document, you will be capturing 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
• If your ISCP references other documents (such as diagrams), they must be included in the ISCP as appendices

2. System/Business Owner signs ISCP

Once completed, the ISCP must be attested to (signed) by the FISMA System Owner. The signature process is repeated annually when the ISCP is reviewed and / or updated.

3. Exercise (test) the ISCP

The Information System Contingency Plan must be tested at least once every 365 days to ensure that everyone knows their part in the process of recovering CMS systems in case of an incident. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one way to test the ISCP. 

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.

Learn how to plan and conduct an ISCP exercise here.

4. Create the After Action Report (AAR)

After the test is conducted, an After Action Report (AAR) 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). 

Here is the template for making your After Action Report.

5. Achieve ISCP recertification

For ISPCs that are being reviewed and updated, the updated ISCP must be re-certified by the System/Business Owner. Make sure that all key staff members receive updated ISCP 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 ISCP 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 ISCP, you should consider documenting the event as an exercise of your plan.

ISCP template

The following template provides placeholder content for an ISCP that you can copy and paste into a document. Add information specific to your system to create your ISCP. In this template, words in italics are instructional and are meant to be deleted from the final document.

Introduction

Information systems are vital to {insert CMS Center or Office} mission/business processes; therefore, it is critical that services provided by {system name} are able to operate effectively without excessive interruption. This Information System Contingency Plan (ISCP) establishes comprehensive procedures to recover {system name} quickly and effectively following a service disruption. 

Concept of operations

The Concept of Operations section provides details about your system, and a description of roles and responsibilities of your Center or Office personnel during a contingency activation. Start with the text below, and then continue with as much detail as needed to describe your system's specific operations.

This section provides details about {system name}, and a description of roles and responsibilities of {insert CMS Center or Office} personnel during a contingency activation.

System description

Information to populate the system description section can be found in the General tab in CFACTS.  Ensure the information is correct and use it for this section. Make any updates to the CFACTS record for consistency.

Roles and responsibilities

The ISCP establishes several roles for {system name} recovery and reconstitution support.  Persons or teams assigned ISCP roles have been trained to respond to a contingency event affecting {system name}.

Describe each team and role responsible for executing or supporting system recovery and reconstitution.  Include responsibilities for each team/role, leadership roles, and coordination with other recovery and reconstitution teams, as applicable. At a minimum, a role should be established for a system owner or business unit point of contact, a recovery coordinator, and a technical recovery point of contact. Example format below.

Team or individual name: {insert name}

Role: {insert role / title}

Responsibilities: {list responsibilities}

Contact information: {insert contact information}

Add more teams or individuals, along with additional details, as needed.

Activation and notification

The Activation and Notification Phase defines initial actions taken once a disruption to {system name} has been detected or appears to be imminent. This phase includes activities to notify recovery personnel, conduct an outage assessment, and activate the ISCP. At the completion of the Activation and Notification Phase, {system name} ISCP staff will be prepared to perform recovery measures. 

Activation criteria and procedure

The {system name} ISCP may be activated if one or more of the following criteria are met:

• The type of outage indicates {system name} will be down for more than {RTO hours (copy the RTO from the BIA)}
• The facility housing {system name} is damaged and may not be available within {RTO hours (copy the RTO from the BIA)}
• Other criteria, as appropriate

The following persons or roles may activate the ISCP if one or more of the above criteria are met:

• List people or roles from the Roles and responsibilities section above

Notification 

The first step upon activation of the ISCP for {system name} is notification of appropriate business and system support personnel. Contact information for appropriate POCs is included in Appendix A: Personnel Contact List. 

For {system name}, the following method and procedure for notifications are used:

Describe established notification procedures.  Notification procedures should include who makes the initial notifications, the sequence in which personnel are notified (e.g., system owner, technical POC, ISCP Coordinator, business unit or user unit POC, and recovery team POC), and the method of notification (e.g., email blast, call tree, automated notification system, etc.).

Outage assessment

Following notification, a thorough outage assessment is necessary to determine the extent of the disruption, any damage, and expected recovery time.  This outage assessment is conducted by the system team. Assessment results are provided to the ISCP Coordinator to assist in the coordination of the recovery of {system name}.

Outline detailed procedures to include how to determine the cause of the outage; identification of potential for additional disruption or damage; assessment of affected physical area(s); and determination of the physical infrastructure status, IS equipment functionality, and inventory.  Procedures should include notation of items that will need to be replaced and estimated time to restore service to normal operations.

Recovery

The Recovery Phase provides formal recovery operations that begin after the ISCP has been activated, outage assessments have been completed (if possible), personnel have been notified, and appropriate teams have been mobilized. Recovery Phase activities focus on implementing recovery strategies to restore system capabilities, repair damage, and resume operational capabilities at the original or an alternate location. At the completion of the Recovery Phase, {system name} will be functional and capable of performing the functions identified. 

Sequence of recovery activities

The following activities occur during recovery of {system name}:

Modify the following list as appropriate for the selected system recovery strategy.

• Identify recovery location (if not at original location)
• Identify required resources to perform recovery procedures
• Retrieve backup and system installation media
• Recover hardware and operating system (if required)
• Recover system from backup and system installation media

Recovery procedures

The following procedures are provided for recovery of {system name} at the original or established alternate location. Recovery procedures are outlined per team and should be executed in the sequence presented to maintain an efficient recovery effort.

Provide general procedures for the recovery of the system from backup media. Specific keystroke-level procedures may be provided in an appendix. If specific procedures are provided in an appendix, a reference to that appendix should be included in this section.  Teams or persons responsible for each procedure should be identified.

Recovery escalation notices / awareness

Provide appropriate procedures for escalation notices during recovery efforts.  Notifications during recovery include problem escalation to leadership and status awareness to system owners and users. Teams or persons responsible for each escalation and awareness procedure should be identified.

Reconstitution

Reconstitution is the process by which recovery activities are completed and normal system operations are resumed.  If the original facility is unrecoverable, the activities in this phase can also be applied to preparing a new permanent location to support system processing requirements. A determination must be made on whether the system has undergone significant change and will require reassessment and reauthorization. The phase consists of two major activities: validating successful reconstitution and deactivation of the ISCP plan.

Concurrent Processing 

Concurrent Processing (in which a system operates at two separate locations concurrently for a time period) is not required. If concurrent processing does occur for the system prior to making it operational, procedures should be inserted here.  Procedures should include length of time for concurrent processing, processing information on both concurrent systems, and validating information on the new permanent system.

For systems that will not require concurrent processing, this section may either be removed, or the following may be used:

In concurrent processing, a system operates at two separate locations concurrently until there is a level of assurance that the recovered system is operating correctly.  {system name} does not have concurrent processing as part of validation. Once the system has been tested and validated, it will be placed into normal operations.

Validation Data Testing

Validation data testing is the process of testing and validating recovered data to ensure that data files or databases have been recovered completely. The following procedures will be used to determine that the recovered data is complete and current to the last available backup: 

Provide procedures for testing or validation of recovered data to ensure that data is correct and up to date. This section may be combined with the Functionality Testing section if procedures test both the functionality and data validity. Teams or persons responsible for each procedure should be identified. An example of a validation data test for a system would be to log into the system database and check the audit logs to determine that all transactions and updates are current. Detailed data test procedures may be provided in an appendix titled System Validation Test Plan.

Validation Functionality Testing

Validation functionality testing is the process of verifying that functionality for {system name} has been tested, and the system is ready to return to normal operations.

Provide system functionality testing and validation procedures to ensure that the system is operating correctly. This section may be combined with the Data Testing section if procedures test both the functionality and data validity. Teams or persons responsible for each procedure should be identified. An example of a functional test for a system may be logging into the system and running a series of operations as a test or real user to ensure that all parts of the system are operating correctly. Detailed functionality test procedures may be provided in an appendix titled, System Validation Test Plan.

Recovery Declaration

Upon successfully completing testing and validation, the System/Business Owner will formally declare recovery efforts complete, and that {system name} is in normal operations.  {system name} business and technical POCs will be notified of the declaration by the ISCP Coordinator.

Notification to system users

Upon return to normal system operations, {system name} users will be notified by the {role of individual in charge of notification} using predetermined notification procedures (e.g., email, broadcast message, phone calls, etc.).

Cleanup

Cleanup is the process of cleaning up or dismantling any temporary recovery locations, restocking supplies used, returning manuals or other documentation to their original locations, and readying the system for a possible future contingency event.

Provide any specific cleanup procedures for the system, including preferred locations for manuals and documents and returning backup or installation media to its original location.

Offsite Data Storage

It is important that all backup and installation media used during recovery be returned to the offsite data storage location. The following procedures should be followed to return backup and installation media to its offsite data storage location.

Provide procedures for returning retrieved backup or installation media to its offsite data storage location. This may include proper logging and packaging of backup and installation media, preparing for transportation, and validating that media is securely stored at the offsite location.

Data Backup

As soon as reasonably possible following recovery, the system should be fully backed up and a new copy of the current operational system stored for future recovery efforts. This full backup is then kept with other system backups. The procedures for conducting a full system backup are:

Provide appropriate procedures for ensuring that a full system backup is conducted within a reasonable time frame, ideally at the next scheduled backup period. This backup should go offsite with the other media in Offsite Data Storage.

Event documentation

It is important that all recovery events be well-documented, including actions taken and problems encountered during the recovery and reconstitution effort, and lessons learned for inclusion and update to this ISCP. It is the responsibility of each ISCP team or person to document their actions during the recovery and reconstitution effort, and to provide that documentation to the ISCP Coordinator.

Provide details about the types of information each ISCP team member is required to provide or collect for updating the ISCP with lessons learned. Types of documentation that should be generated and collected after a contingency activation include:

• Activity logs (including recovery steps performed and by whom, the time the steps were initiated and completed, and any problems or concerns encountered while executing activities)
• Functionality and data testing results
• Lessons learned documentation 
• After Action Report

Event documentation procedures should detail responsibilities for development, collection, approval, and maintenance.

Deactivation of ISCP

Once all activities have been completed and documentation has been updated, the System/Business Owner will formally deactivate the ISCP recovery and reconstitution effort. Notification of this declaration will be provided to all business and technical POCs.

Document change and approval

Modifications made to this plan since the last update are as follows:

Appendix A: Personnel Contact List

Provide contact information for each person with a role or responsibility for activation or implementation of the ISCP, or coordination with the ISCP. For each person listed, at least one office and one non-office contact number is recommended. Note: Information may contain personally identifiable information (PII) and should be protected.

ISCP Director

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

ISCP Director (Alternate)

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

ISCP Coordinator

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

ISCP Coordinator (Alternate)

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

ISCP Team Lead

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

ISCP Team Members

Name and title:

Address (street, city, state, zip code):

Email:

Phone (home):

Phone (cell):

Phone (work):

List additional team members as needed

Appendix B: Vendor contact list

Contact information for all key maintenance or support vendors should be included in this appendix. Contact information, such as emergency phone numbers, contact names, contract numbers, and contractual response and onsite times should be included.

Appendix C: Detailed recovery procedures

To create this appendix, describe the detailed recovery procedures for the system, which may include items such as:

• Keystroke-level recovery steps
• System installation instructions from tape, CD, or other media
• Required configuration settings or changes
• Recovery of data from tape and audit logs
• Other system recovery procedures, as appropriate

If the system relies totally on another group or system for its recovery and reconstitution (such as a mainframe system), information provided should include contact information and locations of detailed recovery and reconstitution procedures for that supporting system.

Appendix D: Alternate processing procedures 

This section should identify any alternate manual or technical processing procedures available that allow the business unit to continue some processing of information that would normally be done by the affected system. Examples of alternate processes include manual forms processing, input into workstations to store data until it can be uploaded and processed, or queuing of data input.

Appendix E: System validation test plan

To create this appendix, describe system acceptance procedures that are performed after the system has been recovered and prior to putting the system into full operation and returned to users. The system validation test plan may include the regression or functionality testing conducted prior to implementation of a system upgrade or change.

An example of a system validation test plan is below. Create your own test plan using steps that will validate the functionality of your system.

Once the system has been recovered, the following steps will be performed to validate system data and functionality:

Appendix F: Alternate storage, site, and telecommunications

This appendix provides information for alternate storage, alternate processing site, and alternate telecommunications for the system. 

Alternate storage, site, and telecommunications information is required for high-impact systems, per NIST SP 800-53 Rev. 5.  Refer to NIST SP 800-53 Rev. 5, for details on control specifics. (Moderate or Low systems may not have the same control specifics for this item.)

Information that should be provided for each area includes:

Alternate Storage

• City and state of alternate storage facility, and distance from primary facility;
• Whether the alternate storage facility is owned by the organization or is a third-party storage provider
• Name and points of contact for the alternate storage facility
• Delivery schedule and procedures for packaging media to go to alternate storage facility
• Procedures for retrieving media from the alternate storage facility
• Names and contact information for those persons authorized to retrieve media
• Alternate storage configuration features that facilitate recovery operations (such as keyed or card reader access by authorized retrieval personnel)
• Any potential accessibility problems to the alternate storage site in the event of a widespread disruption or disaster 
• Mitigation steps to access alternate storage site in the event of a widespread disruption or disaster
• Types of data located at alternate storage site, including databases, application software, operating systems, and other critical information system software
• Other information as appropriate

Alternate Processing Site

• City and state of alternate processing site, and distance from primary facility
• Whether the alternate processing site is owned by the organization or is a third-party site provider
• Name and points of contact for the alternate processing site
• Procedures for accessing and using the alternate  processing site, and access security features of alternate processing site
• Names and contact information for those persons authorized to go to alternate processing site
• Type of alternate processing site, and equipment available at site
• Alternate processing site configuration information (such as available power, floor space, office space, telecommunications availability, etc.)
• Any potential accessibility problems to the alternate processing site in the event of a widespread disruption or disaster
• Mitigation steps to access alternate processing site in the event of a widespread disruption or disaster
• SLAs or other agreements of use of alternate processing site, available office/support space, setup times, etc.
• Other information as appropriate

Alternate Telecommunications

• Name and contact information of alternate telecommunications vendors
• Geographic locations of alternate telecommunications vendors facilities (such as central offices, switch centers, etc.)
• Contracted capacity of alternate telecommunications
• SLAs or other agreements for implementation of alternate telecommunications capacity
• Information on alternate telecommunications vendor contingency plans
• Names and contact information for those persons authorized to implement or use alternate telecommunications capacity
• Other information as appropriate

Appendix G: Diagrams

Information for this section should be available from the system’s System Security and Privacy Plan (SSPP) and can be copied from the SSPP, or reference the applicable section in the SSPP and attach the latest version of the SSPP to this ISCP. Include any system architecture, input/output, or other technical or logical diagrams that may be useful in recovering the system. Diagrams may also identify information about interconnection with other systems.

Appendix H: Test and maintenance schedule

All ISCPs should be reviewed and tested at the organization defined frequency (e.g. yearly) or whenever there is a significant change to the system. Provide information and a schedule for the testing of the system. The ISCP test should include all ISCP points of contact and be facilitated by an outside or impartial observer.  A formal test plan is developed prior to the functional test, and test procedures are developed to include key sections of the ISCP, including the following:

• Notification procedures
• System recovery on an alternate platform from backup media
• Internal and external connectivity
• Reconstitution procedures

Results of the test are documented in an After Action Report (AAR), and Lessons Learned are developed for updating information in the ISCP.

NOTE: Full functional tests of systems normally are failover tests to the alternate locations, and may be very disruptive to system operations if not planned well. Other systems located in the same physical location may be affected by or included in the full functional test. It is highly recommended that several functional tests be conducted and evaluated prior to conducting a full functional (failover) test.

Examples of functional tests that may be performed prior to a full functional test include:

• Full notification and response of key personnel to recovery location
• Recovery of a server or database from backup media
• Setup and processing from a server at an alternate location

Not all systems are required to perform a full functional test as part of ISCP testing. Moderate or low systems may have different requirements. Check the CMS Acceptable Risk Safeguards (ARS) to find out specific requirements for your system.

The following is a sample of a yearly test and maintenance schedule for a high-impact system:

Appendix I: Associated plans and procedures

Information for this section should be available from the system’s System Security and Privacy Plan (SSPP) and can be copied from the SSPP or reference the applicable section in the SSPP and attach the latest version of the SSPP to this ISCP. ISCPs for other systems that either interconnect or support the system should be identified in this appendix. The most current version of the ISCP, location of ISCP, and primary point of contact (such as the ISCP Coordinator) should be noted. 

Appendix J: Business Impact Analysis

Include the Business Impact Analysis (BIA) that was completed prior to populating this Information System Contingency Plan.