Introduction

This handbook defines actions that must be taken in response to a suspected breach of Personally Identifiable Information (PII) / Protected Health Information (PHI) / Federal Tax Information (FTI) at the CMS to meet federal requirements for breach response. The handbook includes roles and responsibilities, breach response deliverables and lines of communication, triggers for federal reporting requirements, and resources from HHS and other authorities.

These procedures help to ensure a coordinated response from all entities responsible for investigating and mitigating a breach, including organizations internal and external to CMS, as well as those responsible for remediating any identified process shortfalls.

Scope

These procedures apply to federal information and information systems, as defined in the Federal Information Security Modernization Act (FISMA) – but not to national security systems.

This handbook covers breach response activities at CMS as an Operating Division (OpDiv) of the U.S. Department of Health and Human Services (HHS). It applies to CMS employees, contractors, grant recipients, interns, and affiliates supporting CMS. All organizations collecting or maintaining information or using or operating information systems on behalf of CMS also need to follow these procedures in accordance with such organizations’ contractual requirements to report to and cooperate with CMS during a breach. 

Out-of-scope entities

Medicare Advantage (Plans C and D) and State Medicaid programs are not CMS FISMA entities but are HIPAA-covered entities. These entities must honor their own reporting requirements.

Who needs this handbook?

This handbook is for all CMS stakeholders who may need to participate in or approve of breach response activities, including:

• Personnel at the CMS Cybersecurity Integration Center who support CMS Incident Response (IR) 
   
• People within CMS responsible for ensuring system security and privacy – such as System Owners (SO), Information System Security Officers (ISSO), and Cyber Risk Advisors (CRA) 
   
• People at HHS who must cooperate in or approve CMS actions, including the HHS Privacy Incident Response Team (PIRT) 
   
• CMS Security and Privacy stakeholders who are responsible for developing cyber defense and response systems and must describe the process ecosystem for their services

Definitions for incidents and breaches

Exact reporting requirements during a breach depend on the nature of the data affected by the breach. The Office of Management and Budget (OMB) has defined multiple types of security and privacy incidents within the scope of the Executive Branch. This section presents definitions of types of sensitive data and breach categories for use at CMS.

What counts as sensitive data?

OMB Memorandum M-17-12 prescribes that Personally Identifiable Information refers to information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can distinguish or trace an individual’s identity, the term PII is necessarily broad.

The Health Insurance Portability and Accountability Act (HIPAA) provides that Protected Health Information is personally identifiable health information. PHI is also PII.

Internal Revenue Service Publication 1075 prescribes that Federal Tax Information consists of federal tax returns and return information (and information derived from it) that is in an agency’s possession or control. FTI may contain PII.

What is an incident?

According to the CMS Risk Management Handbook, an incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

What is a breach?

OMB Memorandum M-17-12 stipulates that a breach is a type of incident in which there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where either of these occurs:

• A person other than an authorized user accesses or potentially accesses PII
• An authorized user accesses PII for an other-than-authorized purpose

Breaches begin as incidents until incident responders determine that PII has been affected. Breach activities will often take place concurrently to ongoing incident response activities, such as containment, eradication, and recovery activities. For more information about Incident Response process, see the CMS Risk Management Handbook Chapter 8: Incident Response.

CMS will assess suspected breaches of PII to determine if they represent enough risk of harm to individuals whose data was compromised to require notification and mitigation.

Major incidents

Per OMB Memorandum M-20-04, a major incident is an incident that compromises U.S. national security. CMS does not store any data that, if breached, may impact national security. OMB also defines any unauthorized modification of, unauthorized deletion of, unauthorized exfiltration of, or unauthorized access to the PII of 100,000 or more people as a major incident. Major incidents must be reported to Congress within seven days.

Reporting incidents and breaches

Incident responders may determine during the incident response process, as more information about an incident is discovered, that the incident falls into other incident categories that trigger additional reporting requirements.

Table of reporting triggers

All incidents

All security and privacy incidents at CMS must be reported to the CMS Information Technology (IT) Service Desk.

• Phone: 410-786-2580 or 800-562-1963
• Email: CMS_IT_Service_Desk@cms.hhs.gov

The report should be made immediately upon discovery to start the CMS incident response process. The IT Service Desk instructs the reporter to fill out an incident report using the Incident Report Template – which is then sent to the Incident Management Team (IMT). Incidents must be reported whether they are confirmed to have occurred or are only suspected to have occurred. The Helpdesk refers security and privacy incidents to IMT, which then coordinates efforts to analyze, contain, and eradicate the incident.

All incidents involving CMS must be reported to HHS to ensure that HHS can provide accurate incident statistics for its OpDivs as per FISMA requirements. By integrating CMS’s incident ticketing system with HHS, CMS automatically notifies HHS of incidents. More details on the CMS Incident Response capability and reporting requirements for incidents other than breaches can be found in the Risk Management Handbook Chapter 8: Incident Response.

All breaches

The Incident Management Team (IMT) investigates reported security and privacy incidents to determine if they meet the definition of a breach. The team does not need confirmation of a breach to begin the breach response process – they should treat incidents as breaches as soon as the investigation reveals that PII, PHI, or FTI was jeopardized by an incident.

If an incident reaches the status of a suspected breach, IMT conducts a risk assessment on the suspected breach using the Risk Assessment Checklist. Then they notify the CMS Breach Analysis Team (BAT) that a suspected breach has occurred and provide the BAT with the results of the risk assessment.

The BAT convenes to review the risk assessment and determine the likelihood of sensitive data compromise according to the CMS Breach Analysis Team Handbook. The team assigns the breach a risk rating of Low, Moderate, or High, and advises the affected system’s Business Owner (BO) on whether CMS must notify the affected individuals. Should notification be necessary, the Senior Official for Privacy (SOP) at CMS works with the following people to develop a notification and mitigation plan:

• Business Owner of the CMS system affected by the breach
• Contracting Officer’s Representative (COR) for any affected contractors
• Incident responders

Depending on the nature and quantity of the sensitive data compromised by the breach, different reporting requirements apply:

• If a breach compromises PHI/PII, the HIPAA Breach Notification Rule applies.
• If a breach compromises FTI, the IRS requires that the U.S. Treasury Inspector General for Tax Administration (TIGTA) be notified.
• If a breach compromises any data that may impact U.S. national security or otherwise meets the definition of a major incident, then Congress must be notified.

Low risk scenarios

Some privacy incidents are considered low risk and do not rise to the threshold of a breach. The Data Governance Board (DGB) has defined a set of criteria for such incidents in the Data Governance Board Guidelines. The IMT can close out these breaches automatically if they represent a sufficiently low risk to not require convening a full Breach Analysis Team.

Breaches of PHI

CMS’s administration of Medicare and Medicaid make the agency a covered entity under HIPAA and subject to the law’s reporting and notification requirements when PHI is breached. This includes reporting to the HHS Office of Civil Rights (OCR) of all breaches of Protected Health Information (PHI) for each calendar year –  including those that occur with a business associate.

Any compromise of PHI requires CMS to notify the affected individual(s) within 60 days. If a breach affects the PHI of more than 500 residents of a U.S. state or jurisdiction, CMS is also “required to provide notice to prominent media outlets serving the State or jurisdiction,” and notify OCR within 60 days. The Breach Analysis Team must work with the CMS Office of Communication’s Media Relations Group to complete this notification step.

Breaches of FTI

The Internal Revenue Service (IRS) requires organizations handling FTI (federal tax returns and return information, including information derived from a return) to report any unauthorized access to or disclosure of FTI to the Treasury Inspector General for Tax Administration and the IRS Office of Safeguards within 24 hours of identifying the incident.

If the Incident Management Team (IMT)  determines that there is a possibility that FTI has been compromised by an incident, they should immediately notify the CMS IRS Liaison to begin the process for reporting to the IRS and TIGTA. Breach response stakeholders should be aware that IRS may request additional data and updates from CMS as the incident response process continues.

Major incidents

OMB requires agencies to report major incidents to Congress within seven days. The threshold for a major incident is a breach that affects more than 100,000 individuals. As an HHS OpDiv, CMS will report major incidents to the HHS Computer Security Incident Response Center (CSIRC) to assist HHS in making a report to Congress. CMS will also report major incidents to the CMS Office of Legislation to ensure that the Office can coordinate with HHS on any participation by CMS in the report.

Breach response steps and deliverables

Breach response activities at CMS require robust lines of communication and clearly defined deliverables between multiple organizations and components, including CMS groups, contractors and associates, and HHS entities. 

In general, the communication responsibilities of CMS, HHS, and entities are:

• CMS will be responsible for collecting data pertaining to the breach, developing a plan for notifying persons affected by the breach and mitigating any resulting harm, and reporting all breach response activities to HHS. 
   
• HHS will be responsible for coordinating between CMS and external federal agencies, as well as approving any notification and mitigation plans developed by CMS. 
   
• Entities operating on behalf of CMS (contractors and associates) are responsible for implementing notification and mitigation plans created by CMS and approved by HHS.

Breach response activities take place in tandem with incident response activities. Discovery of new data about a breach should be reported as soon as possible to HHS Computer Security Incident Response Center (CSIRC), to ensure that HHS can meet its own reporting requirements. (HHS CSIRC is the primary communication pathway between CMS and external organizations such as other federal agencies.) 

CMS maintains an incident ticketing system that automatically sends ticket updates to a mirrored ticket in the equivalent HHS CSIRC ticketing system. Incident responders must maintain this integration and ensure that tickets are promptly updated to communicate with HHS.

The Incident Management Team, in keeping with its role during incident response, is the primary communication pathway between organizations within CMS and its contractors and associates. For more details on IMT’s role and process during incidents, see the CMS Risk Management Handbook Chapter 8: Incident Response.

Breach response activities are accomplished through four stages: reporting, risk assessment, breach analysis, and notification and mitigation.

Reporting

The incident ticket submitted by the CMS IT Helpdesk is the first notice to CMS of a possible breach. The IT Helpdesk works with the individual reporting an incident to create an initial incident report as a deliverable to the Incident Management Team (IMT) and create a ticket to track the issue. The incident ticket is automatically mirrored in the equivalent HHS system.

Risk assessment

IMT works with the affected system’s officials and operators to investigate the incident. They assess the incident to determine if any categories of sensitive data may be compromised. If there is a possibility of compromise, the incident is considered a suspected breach. IMT conducts a risk assessment using the “Factors for Assessing the Risk of Harm to Potentially Affected Individuals” prescribed by OMB and defined in the CMS Risk Assessment for Breach Notification Determination form. Then they formally convene the Breach Analysis Team and provide the team with the IMT Risk Assessment as a deliverable.

Breach analysis

The Breach Analysis Team convenes to review the IMT Risk Assessment and categorizes the risk represented by the breach as low, moderate, or high, as described in the CMS Breach Analysis Team Handbook.

The BAT consists of breach response stakeholders in leadership positions and security and privacy subject matter experts for the affected system, including the Business Owner, ISSOs, COR (if the affected system is a contractor system), Senior Official for Privacy, and the DCTSO Incident Commander.

The BAT determines if the conditions of the breach warrant notifying the affected individuals. If so, the BAT drafts a Notification and Mitigation Plan as a deliverable to the HHS Privacy Incident Response Team (PIRT), using the HHS PIRT Response Plan Template. The Business Owner of the affected system has the final decision on whether notification and mitigation will go forward.

Notification and mitigation

HHS PIRT reviews the Notification and Mitigation Plan. The PIRT may overrule the BAT on whether notification and mitigation are necessary or they may request changes to the plan. If the PIRT approves, the Business Owner of the affected system (and the COR if the affected system is a contractor system) are responsible for executing the approved plan.

Table of breach response deliverables

Breach notification and mitigation

The goal of breach response activities is to reduce the risk of harm to individuals that is created by a breach of sensitive data. If the Breach Analysis Team determines that a breach represents enough risk to individuals, they develop a Notification and Mitigation Plan.

The CMS Senior Official for Privacy, in cooperation with the Business Owner of the affected system and with support from the full BAT, is responsible for developing the Notification and Mitigation Plan. CMS will receive approval to implement the plan from the HHS PIRT, using the HHS PIRT Response Plan Template as the formal deliverable. The Notification and Mitigation Plan must consider the nature and scope of the breach to determine if media organizations must be notified as per the HIPAA requirements.

Once approved, the Notification and Mitigation Plan is implemented, with responsibility for implementation assigned to the Business Owner of the affected system (or the COR, if the affected system is a contractor system). If media notification is required, the BAT should coordinate with the CMS Media Relations Group (MRG).

Notification

If the Breach Analysis Team determines that a breach of PII represents a risk of harm to the affected individuals, then CMS must notify individuals whose PII is compromised in a breach. The team will develop a Notification and Mitigation Plan to describe the actions CMS will take to protect the affected individuals.

Individual notification

As prescribed by the CMS Breach Analysis Team Handbook, the CMS Senior Official for Privacy works with the Business Owner of an affected CMS system to develop a notification letter describing the breach for individuals and submit it to HHS PIRT for approval.

OMB M-17-12 provides direction to federal agencies on what information should be included in breach notifications:

• A brief description of what happened, including the date(s) of the breach and of its discovery 
   
• A description of the types of sensitive data compromised by the breach (e.g., full name, Social Security Number, date of birth, home address, account number, and disability code), to the extent possible 
   
• A statement of whether the information was encrypted or protected by other means, when it is determined that disclosing such information would be beneficial to potentially affected individuals and would not compromise the security of the information system 
   
• Guidance to potentially affected individuals on how they can mitigate their own risk of harm, the countermeasures undertaken, and any services provided to potentially affected individuals 
   
• Any steps being taken to investigate the breach, to mitigate losses, and to protect against a future breach 
   
• A description of how potentially affected individuals can learn more information about the breach, including a telephone number (preferably toll-free), email address, and postal address

HHS PIRT has oversight over CMS breach notification plans. After developing the notification letter and a plan to contact the affected individuals, the BAT should meet with HHS PIRT to gain approval to implement the plan. This meeting should also be attended by the Business Owner(s) of any affected CMS systems, the Contracting Officers of any CMS contractor partners who were involved in the breach, and the incident response personnel who investigated the breach to ensure that HHS PIRT can receive timely answers to any questions related to the breach.

Media notification

In addition to individual notification, HIPAA requires CMS to notify local media outlets if a breach of PHI affects more than 500 individuals within a single locality.  The Breach Analysis Team should contact CMS Media Relations Group if a breach of PII/PHI affects more than 500 individuals to make certain that any plans to contact media outlets are included in the notification plan submitted to HHS PIRT for approval.

Notification through public CMS resources

CMS must also consider that a widely publicized breach may cause members of the public to attempt to contact CMS with questions about the breach and inquire whether their own information was affected. As part of the notification plan, the Breach Analysis Team may determine that CMS should provide a public notification message on its public resources, including:

• Posting on the cms.gov homepage to inform the public of the breach, with a link to further details 
   
• Providing CMS call centers with a message to play at the start of calls to inform callers how they can determine if they were affected by a breach

Mitigation

As part of its notification plan, the Breach Analysis Team must determine and document the actions that CMS will take to mitigate the risk of harm. If the breach puts the affected individuals at risk for identity theft, CMS will offer credit monitoring as prescribed by the CMS Breach Analysis Team Handbook.

Budgeting considerations

There may be costs associated with implementing a notification and mitigation plan, such as providing a credit monitoring service free of charge to the affected individuals. If a contractor system is breached, the contractor should cover the costs of notification and mitigation. CMS contracts should establish this responsibility.

Roles and responsibilities

Breach response stakeholders have direct or supporting roles and responsibilities during a breach. Some stakeholders in this group are associated with the FISMA system undergoing a breach and some are part of the CMS incident response capability. The breach response stakeholders have the following roles and responsibilities:

CMS FISMA System Stakeholders

Business Owner (BO)

• Owns decision to notify individuals affected by a breach and provide mitigation, with advisement from the BAT.
• Owns decision to take major actions impacting system availability in response to a breach (such as shutting down a breached system).

Primary Information System Security Officer (ISSO)

• Primary system stakeholder in charge of providing data to IMT, BAT, and other breach response stakeholders about the affected system.

Operations Teams (to include General Support System [GSS] support)

• Takes incident response actions on the system affected by the breach. May escalate decision to take major action impacting availability to the BO.
• Provides system data to IMT, BAT and other breach response stakeholders at the direction of the ISSO.

Cyber Risk Adviser (CRA)

• Provides guidance to breach response stakeholders on risk and compliance for the affected system.

ISPG Breach Response and Coordination

CMS CISO

• Owns the breach response process.
• Is kept apprised of all developments during breach response, analysis, notification, and mitigation.

CMS Senior Official for Privacy (SOP)

• Owns the Breach Analysis Team process.
• Owns and oversees the Notification and Mitigation Plan, in cooperation with the system BO.

DCTSO Incident Coordinator

• Owns the incident response process.

CMS Cybersecurity Integration Center (CCIC)

Incident Management Team (IMT)

• Primary coordination entity for breach response. Works to provide leadership (BAT, senior officials) with data about the breach to make decisions.
• Conducts initial analysis and risk assessment of breaches to provide to the BAT.

CMS Security Operations Center (SOC)

• Provides technical support and security subject matter expertise to the BAT during a breach.

CMS Subject Matter Expert Support

CMS Office of Communications/Media Relations Group

• Provides notification to media outlets in the event of a breach affecting the PHI of more than 500 individuals.

Office of General Counsel

• Provides support to the BAT in the event of a major incident to help CMS prepare for congressional notification.

Breach Analysis Team (BAT)

• Owns the risk decision (low/moderate/high) after IMT conducts a risk assessment.
• Works with the SOP and BO to advise on the Notification and Mitigation Plan.

Laws and guidance

Use this list of applicable laws and guidance to learn more about the processes described in this handbook.

Federal laws

• Federal Information Security Modernization Act (FISMA) of 2014, Pub. L. 113-283, 128 Stat. 3073 (Dec. 18, 2014) (primarily codified at 44 U.S.C. chapter 35, subchapter 11). 
• Health Insurance Portability and Accountability Act (HIPAA) of 1996, Pub. L. 104-191 (Aug. 21, 1996). 

Executive orders, memoranda, and directives

• OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information (January 3, 2017). 
• OMB Memorandum M-20-04, Fiscal Year 2019-2020 Guidance on Federal Information Security and Privacy Management Requirements (November 19, 2019).
• OMB Circular A-130, Managing Information as a Strategic Resource (July 28, 2016). 
• PPD-41, Annex for Presidential Policy Directive – United States Cyber Incident Coordination (July 26, 2016). 
• OMB Memorandum M-16-14, Category Management Policy 16-2: Providing Comprehensive Identity Protection Services, Identity Monitoring, and Data Breach Response (July 1, 2016). 

CMS / HHS policy and procedures

• CMS Risk Management Handbook (RMH) Chapter 8: Incident Response
• CMS Breach Analysis Team Handbook
• Data Governance Guidelines
• HHS PIRT Response Plan Template
• CMS Risk Assessment for Breach Notification Determination

Additional guidance

Department of Commerce / National Institute of Standards and Technology (NIST)

• NIST Special Publication 800-34 (Revision 1), Contingency Planning Guide for Federal Information Systems and Organizations (Apr. 2013). 
• NIST Special Publication 800-61 (Revision 2), Computer Security Incident Handling Guide (Aug. 2012). 
• NIST Special Publication 800-122, Guide to Protecting the Confidentiality of PII (Apr. 2010). 

Department of Homeland Security (DHS) / United States Computer Emergency Readiness Team (US-CERT)

• US-CERT Federal Incident Notification Guidelines
• National Cybersecurity and Communications Integration Center (NCCIC) Cyber Incident Scoring System

General Services Administration (GSA)

• Identity Protection Services (IPS) Multiple Award Blanket Purchase Agreement (BPA)