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

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

Key Requirements

All security incidents shall be reported to CMS in accordance with the requirements

listed in the CMS Risk Management Handbook (RMH) Chapter 8. Incidents shall be

reported to the IT Service Desk. A security incident is a Personally Identifiable

Information (PII) or Protected Health Information (PHI) breach, a ransomware event, or

an event that impacts the confidentiality, integrity or availability of Medicare data.

Final reports for all incidents shall be submitted timely but no later than 40 days after the

initial reporting of an incident.

MACs shall also email each incident report to mailto:Security_Incident@cms.hhs.gov.

NIST Special Publication 800-61 defines a computer/cybersecurity incident as an occurrence that

actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or

availability of information or an information system; or constitutes a violation or imminent threat

of violation of law, security policies, security procedures, or acceptable use policies. Examples of

incidents are:

• An attacker commands a botnet to send high volumes of connection requests to a web server,

causing it to crash.

• Users are tricked into opening a “quarterly report” sent via email that is actually malware;

running the tool has infected their computers and established connections with an external host.

• An attacker obtains sensitive data and threatens that the details will be released publicly if the

organization does not pay a designated sum of money.

• A user provides or exposes sensitive information to others through peer-to-peer file sharing

services.

An “imminent threat of violation” refers to a situation in which the organization has a factual basis

for believing that a specific incident is about to occur. For example, the antivirus software

maintainers may receive a bulletin from the software vendor, warning them of new malware that is

rapidly spreading across the Internet.

The business partner shall use its security policy and procedures to determine whether a non-reportable event or a reportable security incident has occurred. Examples of non-reportable events

include a user connecting to a file share, a server receiving a request for a web page, a user sending

email or a firewall blocking a connection attempt. Upon receiving notification of an IT systems

security incident or a suspected incident, the SSO or another identified individual shall immediately

perform an analysis to determine if an incident actually occurred. The incident should be evaluated

to determine if it impacts the processing of Medicare data or the confidentiality, integrity and

availability of Medicare data.

All suspected security incidents or events shall be reported to the business partner’s IT service desk

(or equivalent business partner function) as soon as an incident comes to the attention of an

information system user. All security incidents and events shall be reported to the CMS IT Service

Desk in accordance with the procedures set forth in the CMS RMH Chapter 8 Incident Response.

This document is available on the CMS Information Security Web site at https://security.cms.gov/.

The CMS IT Service Desk can be contacted by telephone at 800-562-1963 or 410-786-2580, or by

e-mail at: mailto:CMS_IT_Service_Desk@cms.hhs.gov. Contacting the CMS IT Service Desk by

telephone is highly recommended if immediate action by CMS is required. In addition, MACs shall

also email each incident report to mailto:Security_Incident@cms.hhs.gov.

When reporting confirmed security incidents, business partners shall report the date and time when

events occurred or were first discovered; names of systems, programs, or networks affected by the

incident; and impact analysis. Release of information during incident handling shall be on an as-needed and need-to-know basis. When other entities should be notified of incidents at external

business partner sites, CMS will coordinate with legal and public affairs contacts at the effected

entities. If a violation of the law is suspected, CMS will notify the Office of Inspector General

(OIG) Computer Crime Unit and submit a report to the Federal Computer Incident Response

Capability (FedCIRC) of the incident with a copy to the CMS CISO.

As part of the risk management process, the business partner shall determine the extent of the

incident’s impact and the potential for new or enhanced controls required to mitigate newly

identified threats. These new security controls (and associated threats and impacts) should provide

additional input into the business partner’s ISRA. Business partners shall refer to CMS RMH

Chapter 8 Incident Response manual for further guidance.

Many of the PII breaches being reported to CMS occur when unencrypted emails are sent to the

intended recipients. A mitigating control to allow many of these breaches to be closed more easily

is the implementation of the Transport Layer Security (TLS) protocol within email servers such as

Microsoft Exchange. The TLS protocol encrypts emails for transmission between two email

servers. There are different TLS features which can be used and provide different levels of

assurance that an email will be encrypted. Use of any of these features requires TLS to be enabled.

To mitigate the severity of email PII breaches, business partners are required to enable TLS on their

email servers. In addition, the most secure TLS feature that can be enabled to encrypt emails

between business partners shall be implemented. If a business partner cannot implement TLS, a

risk must be documented in the ISRA.