CMS Pub. 100-17, ch. 117_systems_security, § 5

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

With prior written approval of their sponsoring CMS Business Owner, business partners may use

the Internet for transmission of and/or receipt of health care transactions. Each request for using the

Internet to conduct CMS business functions will be considered individually and approval is not

automatic. However, any approval shall require that business partners meet CMS architectural,

security, data interchange, and privacy requirements for Internet-facing infrastructure. Further, an

independent (third-party) assessment of security controls of the new functionality prior to its release

into production is required and the assessment must include penetration testing. The assessment

must be conducted to validate compliance with the following specific architectural, security, data

interchange, and privacy requirements, as well as the MAC ARS. The existing requirement for an

annual penetration test of the contractor network shall include any approved Internet infrastructure

within the FISMA boundary. Compliance with existing MAC ARS requirements to conduct

vulnerability scans and penetration testing is still mandatory.

Briefly, architectural, security, data interchange and privacy requirements include the following:

1. Architecture:

• Explicit compliance with CMS system lifecycle standards, particularly the CMS Technical

Reference Architecture (TRA), as currently released, and all its appendices.

• Utilization of resources to leverage existing technology and solutions such as platform and

software developed by contractors and in compliance with CMS standards to meet the same

or similar business requirements. The technology and solutions would also have to align

with requirements for the Medicare Administrative Contractors, CMS Data Centers, and

Standard Front-End initiatives.

2. Security:

• Full compliance with the CMS Target Life Cycle Framework (Checkpoints, Deliverables,

and Activities including Security Authorization) when introducing the new functionality.

• Satisfactory systems test and evaluation of the Internet application to include evaluation of

all applicable controls in the MAC ARS.

• Compliance with DHHS and CMS standard configuration settings.

• Compliance with the current versions of NIST SP 800-41, Guidelines on Firewalls and

Firewall Policy; NIST SP 800-44, Guidelines on Securing Public Web Servers; NIST SP

800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) NIST 800-111, Guide

to Storage Encryption Technologies for End User Devices; NIST SP 800-113, Guide to SSL

VPNs; NIST SP 800-114, User's Guide to Securing External Devices for Telework and

Remote Access; NIST SP 800-115, Technical Guide to Information Security Testing and

Assessment; NIST SP 800-119, Guidelines for the Secure Development of IPv6; and NIST

SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing.

• Security Authorization dependent on compliance with security control requirements and

completion of documentation such as the ISRA, the security and privacy plan for the

infrastructure, platform, and applications supporting the Internet functionality, and a CP for

the supporting platform and application. Authentication details shall be documented in

accordance with CFACTS requirements. All security documentation must be developed to

the CMS methodologies and procedures provided at: https://security.cms.gov/.

3. Privacy: Update the Privacy Impact Assessment (PIA) as set forth in Section 208 of the E-

Government Act.

4. Data Interchange Standards:

• Utilization of HIPAA compliance standards for applicable transactions (i.e., claims,

remittances and inquiry/response for eligibility and claim status) to be enabled by the new

functionality.

• Enabling both batch file transfer and interactive screen presentation for the HIPAA

transactions.

• 508 compliance for interactive screen presentation.

• All Internet and non-Internet data exchange modes (i.e. Interactive Voice Recognition,

Direct Data Entry, and Computer to Computer) shall return consistent data.

• Compliance with Trading Partner authentication requirements including submitter/provider

relationship for the HIPAA transactions.

Application requirements include but are not limited to the following:

- A proof of concept/concept of operation paper describing the new application and functionality.

- Information that the Internet service shall be extended only to entities or providers enrolled in

the jurisdiction of the proposing business partner.

- If the applicant has had a similar private side application, they shall describe the experience and

how it relates to the Internet proposal.

Other application requirements may be imposed by the sponsoring CMS business component.

Additionally, business partners may also use the Internet for: 1) utilizing the IRS Filing Information

Returns Electronically (FIRE) system for Form 1099 submissions, and 2) utilizing e-mail to

transmit sensitive information via encrypted attachments in accordance with all applicable MAC

ARS controls. An application for these uses is not required. If not already in place, contractors must

install firewalls, filtering technology to screen incoming e-mail for high risk transmissions such as

executables, up to date virus protection software, and intrusion detection software to utilize the

Internet for these purposes.

References

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

In addition to this manual, the following documents may be referenced during the IT systems

contingency planning process:

• CMS Information Security Library - https://security.cms.gov/

• NIST Special Publication 800-34, Contingency Planning Guide for Information

Technology Systems, May 2010.

https://www.nist.gov/privacy-framework/nist-sp-800-34

• NIST Special Publication 800-12, An Introduction to Computer Security: The NIST

Handbook, Chapter 11.

http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf

• Federal Information System Controls Audit Manual (FISCAM), Exposure Draft, GAO-

08-1029G, Section 3.5.

https://www.gao.gov/products/gao-23-104975

• OMB Circular No. A-123, Management’s Responsibility for Internal Control, Revised,

https://www.whitehouse.gov/omb/information-for-agencies/circulars/

• Office of Management & Budget, Circular No. A-130, Appendix III, Security of Federal

Automated Information Resources, 8 February 1996.

https://www.whitehouse.gov/omb/information-for-agencies/circulars/

Appendix A:

Medicare Information Technology (IT)

Systems Contingency Planning

(Rev. 15)

Table of Contents

1 Introduction

2 Scope

3 Definition of an acceptable ITSCP

4 IT Systems Contingency Planning

4.1 Contingency Planning

4.2 Coordination with Other Business Partners

5 IT Systems Contingency Plan

6 Testing

6.1 Claims Processing Data Centers

6.2 Multiple Contractors

6.3 Test Types

6.3.1 Live vs. Walkthrough

6.3.2 End-to-End

6.4 Test Planning

7 Maximum Tolerable Downtime

8 Responsibilities

8.1 Business Partner Management

8.2 Systems Security Officer (SSO)

9 Changes

9.1 Attachments

1 Introduction

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

CMS business partners are required by the MAC ARS Contingency Planning family to

develop and maintain an ITSCP. Business partners are expected to develop and test

contingency plans that address key recovery scenarios that could occur as the result of a

disastrous situation. While a contingency plan cannot address all possible scenarios, the plan

should be structured to be useful in a variety of situations. When developing an ITSCP, the

business partners are required to address all of the MAC ARS controls. The ITSCP needs to

be developed in accordance with the CMS RMH Chapter 6 Contingency Planning document.

In addition, the current version of NIST Special Publication 800-34, Contingency Planning

Guide for Federal Information Systems, should be reviewed. NIST identifies different

components and plan types that should be documented and be incorporated in a robust ITSCP.

The purpose of this appendix is to supplement the CMS RMH manual and NIST publication

and to provide information to aid the business partner in planning for and responding to an

emergency or system disruption, and to recover from that emergency or disruption. It is to be

used by the CMS Medicare business partner management, IT systems management and staff,

and system security persons charged with preparing for continuing the operation of Medicare

systems and developing an ITSCP or updating an existing plan. In addition, the business

partner’s SSPP and ISRA should be used as a checkpoint to determine if appropriate

contingencies have been addressed in the ITSCP. Also, the ITSCP should be coordinated with

the Incident Response activities to address the restoration and recovery activities associated

with an incident.

It can be noted that an ITSCP can be out of date shortly after it is created and updated.

Automated tools exist to facilitate the development and maintenance of a plan. These tools

can significantly help keep a plan current, but they may not address all the areas required, and

they may not format the data in a manner that is consistent with CMS requirements. In these

situations, the business partner will need to supplement the tools with additional information

and cross references to ensure that all required information is documented.

2 Scope

(Rev. 15)

The business partner ITSCPs address organizations and sites where Medicare data is

processed, including claims processing locations, data centers, and other processing or

printing sites.

3 Definition of an Acceptable ITSCP

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

An ITSCP is a document that describes how to deal with an emergency or system disruption.

These situations could be caused by, but not be limited to, a power outage, hardware failure,

fire, or terrorist activity. An ITSCP is developed and maintained to ensure quick, appropriate,

effective, and efficient response in those situations for which a foreseen risk cannot be mitigated

or avoided.

Before developing an ITSCP, it is required to have or create a contingency policy. The

contingency policy is a high-level statement relative to what the management wants to do to

address a contingency and to recover from the emergency or system disruption.

The ITSCP shall be developed under the guidance of IT management and systems security

persons and all organizational components shall be actively involved in providing information

for developing the plan, for making plan related decisions, and for providing support to plan

testing.

It can be a subjective argument relative to what constitutes an acceptable ITSCP. In this

document, the description of an acceptable ITSCP is based on the results of the research,

analysis and review of various documents from Government and industry, and the review of

existing business partner ITSCPs and test reports.

The following summary statements define what constitutes an acceptable ITSCP. This is not

an all-inclusive list, and the topics are not in any order of importance or priority.

1. Considers the protection of human life as the paramount guiding principle.

2. The backup, recovery, and restoration of critical business functions, protecting

equipment and data, and preserving the business reputation for providing high-quality

service.

3. Is logical, reasonable, understandable, user friendly, and can be implemented

under adverse circumstances.

4. Considers risk assessment results.

5. Addresses possible and probable emergencies or system disruptions that would require

the implementation of the ITSCP.

6. Can be sufficiently tested on an established regular basis within recommended recovery

periods at reasonable cost.

7. Contains information that is needed and useful during an emergency or

system disruption.

8. Can, when implemented, produce a response and recovery, such that critical

business functions are continued.

9. Specifies the personnel necessary to implement the plan, and clearly defines

their responsibilities.

10. Clearly defines the resources necessary to implement the plan.

11. Reflects what can be done – is not a wish list.

12. Assumes people shall use sound judgment, but will need clearly stated guidance,

since they will be functioning in an unfamiliar environment, under possibly severe

conditions and pressure.

13. Addresses backup and alternate sites.

14. Addresses the use of manual operations, where appropriate and necessary.

15. Contains definitive “Call Lists” to use for contacting the appropriate persons in

the proper sequence. These lists would include vendor points of contact.

An acceptable ITSCP should be concise. It should not contain any more information than is

necessary to plan for and implement contingency actions. The users should not get bogged

down in detail as they read the plan to determine what to do, when to do it, what is needed to

do it, and who should do it. The ITSCP should serve as a “user’s manual” and be easy to

understand and use.

Because an ITSCP is designed to be used in a stressful situation, it shall be written with

that as a foremost thought in mind. The prime objective is to maximize the continuity of

critical operations.

Reviewing an ITSCP and testing it will help determine whether it remains an acceptable

plan. The review and testing shall not focus solely on content but shall also focus on ease of

use.

Careful thought should be given to the organization of the ITSCP. The organization should be

logical in terms of what will the user want to know or do first. If the first thing that should

happen in an emergency is that a call list shall be used to notify persons, then that call list, or a

pointer to it, should be placed very near the front of the ITSCP. Not every informational item to

be utilized during a contingency event will be in the ITSCP document. For example, the plan

may point to an attachment or to a separate procedure manual. It is imperative to assure that

any information provided in a separate procedure manual is readily available, easily obtainable

and searchable.

Contingency planning can provide a cost-effective way to ensure that critical IT capabilities

can be recovered quickly after an emergency. IT systems contingency planning shall embrace a

coordinated contingency policy of what will be done to fully recover and reconstitute all

operations.

4 IT Systems Contingency Planning

(Rev. 15)

The goal of IT systems contingency planning is to continue accomplishing critical IT systems

operations in an emergency or system disruption and to accomplish a rapid and smooth recovery

process.

4.1 Contingency Planning (CP)

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

Contingency planning is preparing for actions in the event of an emergency situation, and

giving some thought and planning to what your organization will do to respond and recover.

The IT systems contingency planning process shall address all the actions and resources needed

to ensure continuity of operation of critical IT systems and the means of implementing the

needed resources. IT management and staff shall be trained to handle emergency or system

disruption situations in data centers and other areas where data processing systems are located.

Contingency planning includes such training.

It is advisable to establish an IT systems contingency planning team. This team would be

responsible for defining critical IT systems, including applications software, data, processing

and communications capabilities, and other supporting resources. These would be the key

people in the implementation of the plan.

4.2 Coordination with Other Business Partners

(Rev. 15)

If a business partner’s data center or other data processing environment is linked to other

business partners for the transmission of Medicare data, then the contingency planning

shall address those links relative to receiving input, exchanging files, and distributing

output. If alternate/backup IT systems capabilities are to be utilized, then their functions

and data transmission links shall be considered in the planning.

Coordination with other business partners is essential to completing the IT systems

contingency planning process.

5 IT Systems Contingency Plan

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

The following required content, in conjunction with the format contained in the CMS RMH, may

be used in developing an IT Systems CP. The following checklist provides a means for

determining if a CP contains the appropriate information that can readily be used in handling an

emergency or system disruption. This list is not all-inclusive, but rather should serve as a thought

stimulus for evaluating CPs.

This checklist uses the same outline as the suggested CP format.

1. Introduction

Does the CP contain:

• Scope

Are the boundaries of the plan indicated? What organizations are involved, not

involved?

o Organizations

o Systems

o Boundaries

o External Interfaces

• IT Capabilities and Resources

Is the focus of the plan on IT systems, capabilities, and resources?

• CP Policy

o Priorities

 Are the CP steps ranked according to priority?

o Continuous Operation

 Are there functions, processes, or systems that are required to continue

without interruption?

o Recovery after Short Interruption

 Which functions, processes, or systems can be interrupted for a short time?

o Recovery Times?

 Are the recover times stated?

 What are the minimum recovery times?

o Standalone Units

 Does a CP exist for any standalone units? A CP shall address any standalone

units that are part of the critical operations environment. It shall state where

backup software and support data for these workstations is stored.

 Is the plan reviewed and approved by other key affected persons?

2. Assumptions

Are all the important assumptions listed? Have the assumptions been carefully reviewed by

the appropriate persons to ensure their validity?

3. Authority/References

• Who or what document is authorizing the creation of the CP?

• What are the key references that apply to the plan?

4. Definition of what the CP Addresses

• Organizations

To which organization(s) does the CP apply?

• Systems

Is there a general description of systems and/or processes?

• Boundaries

Are the system boundaries clearly defined?

• External Interfaces

Are external interfaces clearly defined?

5. Three phases defined

Does the plan address three phases of emergency or system disruption?

• Notification

o Is this phase adequately described so that it is understood what activities occur

therein?

o Are people, and their safety, considered?

o Is damage/impact assessment considered?

o Are the alerting and initial impact assessment procedures fully explained as well

as arrangements for continual review of their use and effectiveness?

• Recover

o Is this phase adequately described so that it is understood what activities occur

during this phase?

o Are effective recovery strategies in place for hardware, software, and data?

o Are hardware configuration and operating system requirements considered?

o Have interdependencies between internal and/or external systems considered?

• Restore/Reconstitute

o Is this phase adequately described so that it is understood what activities occur

during this phase?

o Has validation of data been documented?

o Has a clear path for validating system functionality and operational capabilities

been implemented?

6. Roles/Responsibilities Defined

• Has the necessary CP implementation organization been defined and the

responsibilities of all those involved clearly stated with no “gray

areas”?

• Will all who have a task to perform be aware of what is expected of them?

• Does the CP assign responsibilities for recovery? The responsibilities of key

management and staff persons shall be carefully described in the CP, so that there is

no question relative to the duties of these people during an emergency.

7. Definition of Critical Functions

• Does the CP address critical systems and processes?

• Have emergency processing priorities been established and approved by

management?

• Has a list of critical operations, data, and applications been created? In preparing the

CP, a list of current critical operations, data and applications shall be documented and

approved by management. This list shall contain the items needed to continue the

minimum critical business elements and functions until operations could be returned

to a normal mode.

8. Alternate Capabilities and Backup

• Have arrangements been made for alternate data processing and telecommunications

facilities? Part of contingency planning includes the completion of arrangements for

alternate data processing facilities and capabilities, and for alternate

telecommunications capabilities necessary to re-establish critical interfaces.

• Does the CP address issues relative to pre-planned alternate locations? The CP shall

address any potential issues relative to pre-planned alternate locations. These include:

o insurance

o equipment replacement

o phones

o utilities

o security

• Does contingency backup planning exist? Planning for appropriate backup of data

and processing capabilities shall include:

o prioritizing operations

o identifying key personnel and how to reach them

o listing backup systems and where they are located

o stocking critical forms, blank check stock, and supplies off-site

o developing reliable sources for replacing equipment on an emergency basis

• Is there an alternate information processing site; if so, is there a contract or

interagency agreement in place?

• Are the levels of equipment, materials and manpower sufficient to deal with the

anticipated emergency? If not, have back-up resources been identified and, where

necessary, have agreements for obtaining their use been established?

• Have temporary data storage sites and location of stored backups been identified?

• Is the frequency of file backup documented?

• Have the arrangements been made for ensuring continuing communications

capabilities?

• Are backup files created on a prescribed basis and rotated off-site often enough to

avoid disruption if current files are damaged?

• Are system, application, and other key documentation maintained at the off-site

location?

• Are the backup storage and alternate sites geographically removed from the primary

site and physically protected?

• Do data and program backup procedures exist? In order to be prepared for an

emergency, it is advisable to provide backups of critical data and software programs.

These are stored at off-site locations sufficiently distant from the primary site so as

not to be affected by the same emergency that would affect the primary site.

• Is the CP stored off-site at alternate/backup locations? Copies of the CP shall be stored

at several off-site locations, including key personnel homes, so that at least one copy is

readily available in time of emergency. Copies of the CP that are stored in a private

home shall be protected from inadvertent access.

9. Required Resources

• Are the following resources for supporting critical operations defined and available

for an emergency?

o Hardware

o Software

o Communications

o Data

o Documents

o Facilities

o People

o Supplies

o Basic essentials (water, food, shelter, transportation, etc.)

• Does the CP provide for backup personnel? As the CP is implemented, it is necessary to

have additional people available to support recovery operations. The CP shall specify

who these people are and when they would normally be called into action.

10. Training

• Are management and staff trained to respond to emergencies? Security training shall

include modules for management and staff relative to their roles for handling

emergency situations.

11. Testing the CP

• Is there a section in the CP that addresses testing of the plan?

• Testing of the CP shall address the following topics:

o Test Philosophy

o Test Plans

o Boundaries

o Live vs. Walkthrough vs. End-to-End Testing

o Test Reports

o Responsibilities

12. CP Maintenance

• Schedule

o Is the CP annually reviewed and tested within every 365 days? The CP shall be

reviewed and tested under conditions as close to an emergency as can be

reasonably and economically simulated.

o Is there a provision for updating the CP within every 365 days?

o Is the CP revised after testing, depending on test results? Are lessons learned

documented and incorporated into the revise CP?

13. Relationships/Interfaces

• Does the CP identify critical interfaces? Interfaces required to continue critical

business functions should be identified. Refer to the System Security and

Privacy Plans.

• Which outside (vendors, providers, banks, utilities, services, CMS) interfaces must be

considered?

• Is the plan compatible with plans of interacting organizations and systems?

• What internal interfaces must be considered?

• Which corporate interfaces must be considered?

• Are there special interfaces with corporate systems that must be addressed in the CP?

14. Attachments

Does the CP contain appropriate attachments, as listed below?

A. Actions for Each Phase

Are the actions to be taken in each phase (respond, recover, restore) of the contingency

clearly described and related to organizations and/or people?

B. Procedures

• Are there detailed instructions for:

o responding to emergencies?

o recovering operations?

o restoring operations?

• Do contingency backup agreements exist? Agreements with organizations or

companies which will provide service, equipment, personnel, or facilities during an

emergency shall be in place.

• Are there procedures for addressing the situation where the processing site is intact, but

people can’t get to it because of a natural disaster? Can the business be operated

remotely?

• Is there an implementation plan for working from home?

C. Call Trees

Are there call lists with names, addresses, and phone numbers with priority order relative to

whom to call first?

D. Hardware Inventory

Are there lists of all the hardware covered by the CP?

E. Software Inventory

Are there lists of all the software covered by the CP?

F. System Descriptions

Are all the systems covered by the CP defined, including appropriate diagrams?

G. Alternate/Backup Site Information

Is there sufficient detail to completely describe the alternate and/or backup sites,

including addresses, phone numbers, contacts, resources available at the sites, and

resources needed to be brought to the site?

H. Assets/Resources

Are there lists of all the needed resources for responding, recovery, and restoring

operations?

I. Risk Assessment Summary

Has there been a realistic assessment of the nature and size of the possible threat and of

the resources most at risk?

J. Agreements/Memo of Understanding

Are there agreements in place relative to the use of alternate/backup sites, special

resources, outside suppliers, extra people, alternate communications, etc.?

K. Manual Operations

Are manual operating procedures in place so that certain functions can continue manually if

automated support is not available soon enough?

Manual processing procedures shall exist in the backup phase until automated capabilities

can take over the information processing. Provisions shall be made to provide this manual

capability.

L. Supplies/Materials/Equipment

Is there information that describes how and where to obtain needed supplies, materials,

and equipment?

M. Floor Plans

Are the necessary floor plans available?

N. Maps

Are the necessary area and street maps available?

O. The CP shall provide for off-site storage:

• Backup software

• Data

• Appropriate documents (emergency telephone lists, memos of understanding, etc.)

• Copies of the CP

• Administrative supplies (forms, blank check stock, etc.)

6 Testing

(Rev. 15)

CMS requires testing of the CP annually under conditions that simulate an emergency or a

disaster. A CP shall also be tested after a substantive system change that necessitates a

revision to the CP.

CMS requires that the critical IT systems shall be tested within every 365 days and the CP

updated to accommodate any changes, including updated versions of software or critical data.

Critical systems are those whose failure to function, for even a short time, could have a severe

impact, or have a high potential for fraud, waste, or abuse.

6.1 Third Party Data Centers (TPDC)

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

Some contractors with which CMS has direct contracts do not have their own data centers. If a

business partner does not have its own data center, then it is the responsibility of the business

partner to inform the subcontractor that operates the data center that they shall have a CP that

addresses the requirements outlined in the Appendix.

6.2 Multiple Contractors

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

The TPDCs usually serve multiple contractors. Existing shared processing environments allow

for multiple contractors to process claims at a data center. There are several data centers

processing Part A and Part B claims for multiple Medicare contractors.

It is important to test a CP with a data center that serves multiple contractors. This provides an

opportunity for the business partner to validate that they can recover the connection with the

TPDCs to process claims.

6.3 Test Types

(Rev. 15)

CP test guidance suggests four types of testing:

• Walkthrough/Tabletop Test

• Checklists

• Simulation/modeling

• Live/Comprehensive Exercises

These are defined below:

• Walkthrough/Tabletop Test: A walkthrough test is accomplished by going through a

set of steps to accomplish a particular task or action initiated because of a contingency

event. The precursor to a walkthrough test is that the steps are documented so that they

can be logically followed. A “test team” might sit around a table and talk through each

step and then walk through” the various steps, and then discuss expected outcomes and

further actions to be taken. They may use a checklist to ensure that all features of a step

are addressed or that all resources necessary to accomplish the task or action are

considered. A walkthrough test does not involve accomplishing the actions being tested

in real time or using the live environment. A walkthrough test could be accomplished

by using a group of test people to act out what might happen if a real contingency event

occurred. They might go to the alternate site, but they would not actually start all

hardware, software, and communication operations in order to assume the function of

the primary site.

For those applications that are both hosted at CMS and not participating in a broader

recovery test to a CMS-approved recovery site during their annual test cycle, a tabletop

test is required. A tabletop test is discussion-based only and does not involve deploying

equipment or other resources. The discussion during the test can be based on a single

scenario or multiple scenarios. By simulating an emergency in an informal, stress- free

environment, this test method allows for the free exchange of ideas and provides

participants an opportunity to practice the steps to be followed in an actual event and to

identify areas in the CP for enhancement.

A successful tabletop test steps participants through real-life scenarios; captures its

results in a formal report; and incorporates the “lessons learned” into subsequent

versions of the CP and the tabletop test plan.

• Checklists: Checklists are used to clearly present a step-by-step logical sequence so

systems and sub-systems may be recovered in a logical manner. Checklists are intended

to provide a direct, simple coordinated listing of events that ensure that all necessary

steps are executed during the recovery process.

• Simulation/Modeling: Modeling involves creating a computer model of the process to

be tested. This allows easy testing of many variables without physically having to make

changes. For example, you can vary the number of servers that go down during a

disaster or the number of people that can get to an alternate site following a disaster.

Simulation involves taking physical actions, but not necessarily to the full extent of

what might actually happen during an emergency. For example, instead of actually

moving everyone to an alternate site to continue operations, a small team may

undertake a set of realistic preparatory actions at the prime site, and another team does

the same at the alternate site. Thus, many steps could be simulated by the two teams

and worthwhile results evaluated.

• Live/Comprehensive Exercises: This is the most complete and expensive test to

accomplish. It involves completing the physical steps that would actually be taken if an

emergency occurred. People and materials would be moved to an alternate site for the

test, and servers would actually be shut down to reduce capability. Power would be shut

off, and live conditions would be tested. A live test uses actual environments, people,

and components to accomplish the test in real time. It is the real thing, nothing artificial,

or made up, is substituted. If the test is to see if an alternate site capability can be

implemented, then in a live test, the hardware, software, data, communications, and

people at the alternate site would be set into action and begin functioning as the primary

site to support operations.

End-to-end refers to the scope of the testing (partial testing is less than end-to-end).

When conducting end-to-end testing, items to consider include:

• End-to-end testing can be completed as part of walkthrough or live test.

• Not testing end-to-end means that some links, processes, or subsystems are missed.

• What is the risk in not conducting end-to-end testing?

• Live end-to-end testing can be very expensive!

Considering risks and cost, management shall make a decision as to what type and scope

of testing is appropriate.

6.3.1 Live vs. Walkthrough

(Rev. 15)

• High-level testing can take the form of a walkthrough test.

• A walkthrough can be part of the overall testing process, but not the whole process.

• Lower-level testing can include a walkthrough, if live testing is not an option.

o Live testing shall be the first choice.

o Fall back to a simulation/model if live testing is not an option.

Cost, time, and interruption of normal operations are major considerations in doing

a live test.

o A walkthrough test should be the last resort.

• Consider what a walkthrough test would miss.

• Consider the risks of missing that part of the test.

• Remember that there is risk in not doing a live test—is the risk acceptable?

o Consider the criticality of functions, processes, and systems.

If critical to continuing essential business operations, then these are strong

candidates for live testing.

• Testing interfaces.

It is important to test the critical interfaces with internal and external systems. It is

difficult to test interfaces using a “walkthrough” method. Simulation or “live” testing is

preferred.

• Cost and complexity.

The decision as to how to test critical functions, processes, and systems must result from

careful consideration of complexity and cost. A complete “live” test of all elements of an

operation may prove to be extremely costly, in terms of both dollars and time. If that cost

outweighs the “cost” of the risk of not doing live testing, then “live” testing should

probably be ruled out.

6.3.2 End-to-End

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

This kind of testing aims to ensure that all software and hardware components associated with a

function, process, or system are tested from the front end through to the back end (input through

process through output). As with live testing, end-to-end testing can be expensive.

• End-to-end testing shall only be considered for critical functions, processes, or systems.

• End-to-end testing provides the best assurance that there are no problems.

• If the overall process to be tested can be sub-divided into critical and non-critical

components, then only the critical components need be considered for end-to-end testing.

• Examples of types of end-to-end tests:

o Claims receipt through to check generation

o Query of a database through to the response

o Medicare Secondary Payer (MSP) check request through to check issue and back

to MSP

• The decision on how to test critical functions, processes, and systems shall carefully

consider complexity and cost. A complete end-to-end test of all elements of an

operation may prove to be extremely costly, both in terms of dollars and time. If that

cost outweighs the cost of the risk of not doing end-to-end testing, then end-to-end

testing should probably be ruled out.

• Look at the criticality of functions, processes, and systems. If these are critical to

continuing essential business operations, then these are strong candidates for end-to-end

testing.

• If you cannot do end-to-end testing, then consider live testing of all possible

connections to help ensure minimum problems.

o Or do simulation/modeling

o Or do a walkthrough

Overall, end-to-end testing may combine walkthroughs, simulation/modeling, and live testing

of contingencies. Walkthroughs and simulations may be used for non-critical systems, whereas

critical systems shall be functionally tested under conditions that reproduce an emergency or a

disaster.

It is advisable that the testing of critical systems be done end-to-end, input through output, so

that no physical activity, automated process, or Medicare business partner system is left

untested. Critical interfaces internal and external to the systems shall be tested.

6.4 Test Planning

(Rev. 15)

An ITSCP test plan shall address at least the following:

• Test objectives

• Test approach

• Required equipment and resources

• Necessary personnel

• Schedules and locations

• Test procedures

• Test results

• Failed tests

• After Action Report

• Retest

• Approvals

It is advisable to establish test teams responsible for preparing and executing the ITSCP tests.

Responsibilities shall be assigned to test team members, including executives, observers, and

contractors.

Following testing, any corrections specified in an After Action Report shall be included in the

next ITSCP test. The process shall include:

• List of items that failed the previous test

• Corrections planned

• Retest detail

• Schedule

• Review responsibilities

Ensure that the lessons learned from ITSCP testing are formally discussed among senior

business partner management, operations, IT management and staff, and the SSO.

Documentation shall exist for:

• Test plans

• Test results

• After Action Report

• Retest plans

• Memos of Understanding/Formal Test Arrangements

• Lessons Learned

7 Maximum Tolerable Downtime (MTD)

(Rev. 15)

MTD is the time it takes to recover an operation, function, process, program, file, or whatever

has to be recovered as an operational entity. If claims processing operations must be

recovered within 72 hours, then that is the MTD to recover. Anything over that is

unacceptable.

• Recovery times may vary, depending on the criticality of the function involved.

• Times can be from a few minutes to days or weeks.

• A table/matrix can be constructed that lists the recovery times.

• There can be a separate table/matrix for each major function (e.g., claims processing,

medical review, check generation).

• Recovery times shall be clearly defined and must be achievable.

8 Responsibilities

(Rev. 15)

Following is a summary of responsibilities for key groups and persons involved with

developing business partner ITSCP.

8.1 Business Partner Management

(Rev. 15)

• Defines scope and purpose of IT systems contingency planning.

• Authorizes preliminary ITSCP planning.

• Ensures that appropriate ITSCPs are developed, periodically tested, and maintained.

• Ensures that all IT operations participate in the planning and development of

the ITSCP.

• Reviews the ITSCP and documented recommendations.

• Requests and/or allocates funds for plan development and approved recommendations.

• Assigns teams to accomplish development of test procedures, and for testing the ITSCP.

• Reviews test results and document an After Action Report.

• Ensures that the appropriate personnel have been delegated and notified about the

responsibility for effecting backup operations, and that the backup copies of critical data

are ready for use in the event of a disruption.

• Ensures that the business partner organization can demonstrate the ability to provide

continuity of critical IT systems operation in the event of an emergency.

• Business partner management shall approve:

o The ITSCP

o Changes to the ITSCP

o Test plans

o Test results

o Corrective action management processes

o Retest plans

o Memos of Understanding/Formal Arrangement Documents

o After Action Report

o Changes to storage and backup/alternate site facilities

8.2 Systems Security Officer (SSO)

(Rev. 15)

• Documents the scope and purpose of ITSCP

• Reconciles discrepancies and conflicts in the ITSCP

• Evaluates security of backup and alternate sites

• Leads the preparation of the ITSCP

• Submits the ITSCP and recommendations to Business Partner Management

• Monitors implementation of the ITSCP and reports status to Business Partner

Management

• Ensures all testing of the ITSCP is performed in accordance with CMS requirements

• Reviews test results

• Ensures that the ITSCP is updated based on test results

• Ensures lessons learned are discussed and formally documented in an After Action

Report

• Obtains approval from the CMS Business Owner

9 ITSCP Changes

(Rev. 15)

The ITSCP shall be reviewed/updated whenever one or more of the following events occurs:

• New systems or operations added

• Upgrade or replacement of Standard System software

• Hardware or software replacement

• Changed back up/alternate site

• Changed storage facilities

• Removal of existing systems or operations

9.1 ITSCP Attachments

(Rev. 15)

Materials that are too extensive to be included in the body of the Medicare ITSCP shall be

included as attachments. These shall be kept current and referenced in the ITSCP. All

attachments shall be available to appropriate ITSCP personnel. These shall also be a part of the

System Security Profile. The SSO shall ensure that the information to be attached is pertinent

and current, and that updated copies are routinely incorporated, particularly into offsite copies

of the ITSCP

Appendix B:

An Approach to Fraud Control

(Rev. 10, Issued: 07-17-09, Effective: 08-17-09, Implementation: 08-17-09)

Table of Contents

1 Introduction

2 Safeguards against Employee Fraud

3 Checklist for Medicare Fraud

1 Introduction

(Rev. 8, Issued: 04-06-07; Effective Date: 10-01-06; Implementation Date: 05-01- 07)

This document develops countermeasures relating to fraudulent acts and a

checklist to help Medicare contractors assess their vulnerability to fraud. Fraud

and embezzlement are skyrocketing, largely because basic safeguards are

neglected or lacking. Fraudulent acts are discussed in terms of the types of

safeguards in place and functioning.

2 Safeguards against Employee Fraud

(Rev. 15)

The following safeguards are specific countermeasures against fraudulent acts by

employees whose functions involve Medicare program funds. These safeguards are

consistent with the MAC ARS, and do not constitute wholly different or additional

minimum requirements. The following countermeasures should prove especially

effective against currently prevalent fraudulent activities and are discussed primarily

as they relate to prevention and detection of fraud.

A. Screen New Employees

Screen new employees for positions that involve program funds directly or

indirectly to address the applicant's past faithful and honest performance of duties

with other employers in addition to job performance and investigation of his/her

personal finances. New employees' statements concerning personal finances shall

be confirmed with former employers and with banking and credit institutions.

Phone calls to previous employers are essential, particularly to former supervisors

who should be advised of the nature of the position. Although former employers

will sometimes fail to prosecute employees associated with fraudulent activities,

they seldom delude a prospective employer asking about the applicant’s integrity.

Any blatant dishonesty in the application (such as claiming qualifications and

experience the applicant never had) shall remove the applicant from further

consideration. Check references and crosscheck them (one against the other) for

consistency as well as content. Evaluate references on the basis of the contact's

personal knowledge of the applicant's job-related qualifications and integrity.

Proper screening is preventive medicine at its best. Gaps in employment are flags

that call for third-party verification, not just a plausible explanation by the

applicant. Former employers may be able to shed light on the situation or be able

to relate the reason given them about gaps by the applicant.

Circumstances relating to termination of previous employment should be clearly

related by former employers. Resolve any inconsistencies or vagueness.

Ask former employers as well as the applicant, whether the employee was ever

bonded, or was ever refused bonding. Sensitive screening should not result in

violating an applicant's civil rights, while assuring you (and your bonding

company) that prudent concern is exercised in the hiring process.

B. Bonding

Bonding is also known as fidelity insurance and comes in all configurations; the

broader the coverage, the more expensive the premium. One of the most important

things you can do is analyze the extent and conditions of coverage in relation to

possible misappropriations of funds. Liability is invariably limited in some

respects. For example, coverage often does not extend to external fraud; to losses

not proven to have been caused by fraudulent acts by covered employees; to frauds

committed by employees known to have perpetrated dishonest acts previously; to

frauds whose circumstances are not properly investigated; or to frauds whose

alleged perpetrators are not brought to trial. Inherent in the analysis of bonding is

risk analysis of fraud in relation to specific components to develop a worst-case

fraud scenario in terms of dollar-loss before recovery through bonding.

C. Separation of Duties

Separate duties so that no one employee can defraud the company unaided. This is

the cardinal rule for fraud prevention, one that is well-understood in manual

operations. It is not as well understood in its application to computer processing

where a single automated system may combine functions ordinarily separated, such

as transactions and adjustments. Analyze all duties, including all stages of

computer programming and operations, in terms of defeating single-handed fraud

as well as in terms of effectiveness and efficiency, with fraud controls taking

precedence. Group review of programmer code before allowing new/upgraded

systems into production is the type of duty-separation (function vs. approval) that

serves both effectiveness and security.

D. Rotation of Duties

Rotate duties, particularly those involving authorization of a transaction.

Separation of duties makes it difficult for an employee to defraud your

organization unaided, so that embezzlement becomes a crime of collusion. As

more and more embezzlement involves more than one person, it becomes

necessary to ensure that the same person is not always involved in approving

another's functions. An employee is less likely to initiate a fraudulent

transaction if he/she is not certain that his/her accomplice will be the one to

approve or process that transaction. Moreover, the knowledge that from time-to-

time other employees will perform his/her function or work his/her cases is a

powerful deterrent to any fraudulent scheme, particularly embezzlement which

requires continual cover-up.

E. Manual Controls

Manual controls are differentiated from automatic controls because constant review

is necessary to see that they are in place and working. Moreover, they often

supplement or augment automatic controls; for example, the manual review of

claims rejected in computer processing. Review all manual controls to determine

the extent to which they would be effective against fraud in any operational area;

too often, controls are reviewed without fraud specifically in mind. Classic manual

controls are those associated with the tape/disk library, and these controls are

strongly associated with restricted access and separation of duties. It does little

good to separate programmer/operator duties if the programmer is allowed to sign

out production tapes or master files for any reason, especially live testing. Library

controls shall require specific authorization for tape removal for specific periods

for specific reasons known to, and sanctioned by, the approving authority. The

most important manual controls are those over blank-check stock and the automatic

check-signer. The employee in control of the check-signer shall not at the same

time control the check stock, although these duties may be rotated so that the

person controlling the check-signer one day may be assigned to control check stock

on the following day when a third person is responsible for the check-signer.

However, no one individual shall be allowed to “sign” a check he/she has issued.

Rotation of duties is proper only for subsequent operations where one's own

previous actions have already cleared.

F. Training

Training employees in their responsibilities relative to fraud in their operations is

basic to prudent management. This extends beyond the employee's own activities.

For example, Title 18, U.S. Code Section 4 requires anyone having knowledge of a

Federal crime to report it to the Federal Bureau of Investigation (FBI) or similar

authority, with penalties of up to $500 fine and 3 years in jail for failure to do so.

No employee should be ignorant of this responsibility. This responsibility can be

explained as a simple good citizenship requirement and not spying or snitching.

Discuss these things periodically in meetings, along with free give-and-take on

moral issues and management's position on every aspect of fraud, including

perpetration involving collusion with outsiders. Do not single out any employee or

function in these discussions, instead make management's position clear regarding

so-called “justification” for unauthorized “borrowing” and the fact that fraud can

and will be prosecuted. Explain that there can be no permissive attitude towards

dishonest acts because such an attitude is corrupting and makes it difficult for

employees to remain honest. Make it known that there are controls throughout the

organization to prevent and detect fraud, without being specific as to how they

work. Require employees to report apparent loopholes in security that might one

day (or already) be exploited for fraudulent purposes. Remind employees that

ethical conduct requires their full cooperation in the event of any fraud

investigation, and when interviewed they shall be called upon to explain why

security gaps or suspicious activities were not reported to the SSO. No security

program can be effective without the involvement and cooperation of employees,

and nowhere is this truer than with fraudulent activity.

G. Notices

Notices, both periodic and situational, are effective and necessary in the prevention

and control of fraud. It is not enough to formulate management policy or to conduct

employee training relative to fraudulent activity. It is possible to remind employees

of management's continuing concerns and to evaluate employee awareness through

simple reminders or announcements of what is happening relative to fraud controls

(of a general nature) and management's reliance on their cooperation and

understanding of their responsibilities. Without this evidence of sustained

management commitment, policy utterances tend to fade from memory or become

regarded as part of a new employee's orientation and not part of the scene. This is

true of minor abuses but is also true of abuses that escalate into fraud.

H. Automatic Controls

Automatic controls to prevent or detect fraudulent activities comprise the

first line of defense in computer operations. Such controls are often thought

of as ensuring data integrity but more in terms of accuracy than of honesty.

Evaluate automatic controls in terms of preventing payment to unauthorized

persons. Test automatic controls with fraudulent (invalid) input, under strict

control of courses, and with management's full cognizance and prior

approval.

I. Audit Routines

Audit routines are those programs where trained auditors test for fraud using

special routines to reveal computer processing that creates or diverts payments

to employees or their accomplices. Wrongdoers not only have to create bogus

payments, but also, they have to be able to lay their hands on the checks in

order to cash them. Devise audit routines to single-out payments being

directed to post office boxes or to repeat addresses (where such repeats would

be unreasonable), to the addresses of an employee or his family, or to a drop-off address that is not a real business but merely a place to collect mail.

3 Checklist for Medicare Fraud

(Rev. 10, Issued: 07-17-09, Effective: 08-17-09, Implementation: 08-17-09)

This checklist represents questions to address in analyzing the security of

Medicare fiscal operations.

1) Have Medicare operations been identified where fraud or complicity in fraud

may be possible (e.g., initiation/approval of payments)?

2) Have individuals been assigned fraud-protection responsibilities in such

components, including the responsibility for reporting possible fraud and

vulnerability to fraud?

3) Do individual employees at all levels understand that management policy relative

to fraud is dismissal and prosecution?

4) Are fiscal operations regularly audited relative to fraud vulnerability?

5) Are fraudulent acts specifically mentioned in the employee's code of ethical

conduct?

6) Is employee integrity specifically addressed during the hiring process, and do

background investigations elicit information that would uncover an applicant's past

fraudulent activity with other employers?

7) Are operations set up in such a way as to discourage both individual and

collusive fraudulent activity?

8) Are programs/systems tested by authorized individuals with “fraudulent” input?

9) Are audit trails generated that identify employees who create inputs or

make adjustments/corrections that would pinpoint responsibility for any

fraudulent act?

10) Is there an effective mechanism for detection/prevention of payments being

purposely misdirected to employees, relatives, or accomplices?

11) Are new or changed programs specifically reviewed for fraudulent code by those

responsible for production-run approval (persons empowered to review changes

but not to make changes themselves)?

12) Are controls designed to prevent fraud, especially in those operations where

large sums could be embezzled quickly?

13) Are all error-conditions checked for fraud potential?

14) Are balancing operations done creatively so that an embezzler could

not hide discrepancies?

15) Are the official activities of all employees, at all levels, subject to independent

review by different reviewers (i.e., not always by the same evaluator)?

16) Does management insist on integrity at all levels?

17) Has management announced that employee's work activities will be

reviewed (in unspecified ways) for both the fact and appearance of

integrity?

18) Do tape/disk library controls in fact prevent tampering with files/programs for

fraudulent purposes?

19) Are alternative fraud controls invoked during emergencies?

20) Are suspected frauds investigated promptly and properly and are they

thoroughly documented?

21) Are fraud audits conducted both periodically and randomly?

22) Are random samples taken of claims/bill inputs and checked back to their sources?

23) Does the Personnel Department check the applicant's background, employment

record, references, and possible criminal record before hiring?

24) Are badges, identification cards/numbers, and passwords promptly issued and

rescinded?

25) Is off-hours work supervised, monitored, or otherwise effectively controlled?

26) Are all employees required to take their vacations and are their replacements

required to check over the vacationers' past activities?

27) Are the credentials of outsiders, such as consultants and auditors, checked out?

28) Is temporary help bonded, hired from reputable agencies, and their activities

restricted to the tasks to be performed? (Same principle applies to employees

temporarily borrowed from non-Medicare components.)

29) Are written procedures controlled and restricted to employees currently

assigned the relevant duties?

30) Are special fraud controls specified for backup operations?

31) Are incoming checks, including returned checks, handled by two or more

individuals in the mailroom and are such teams switched around so that the same

people are not always working together?

32) Are blank checks and automatic check-signing equipment strictly controlled

with a tamper-proof numbering mechanism?

33) Is procedure/program documentation relative to the payment process treated as

highly sensitive data and safeguarded when superseded?

34) Are backup files current and securely stored off-site?

35) Are re-runs checked for the possibility of fraud, especially duplicate payments?