Purpose

As required under the Federal Information Security Modernization Act (FISMA) of 2014 (44 U.S.C. Chapter 35), and in compliance with the updated requirements of the National Institute of Standards and Technology's (NIST) Special Publications (SP) 800-53, Revision 5, and other federal requirements, this Policy defines the framework for protecting and controlling the confidentiality, integrity, and availability of CMS information and information systems. It also provides direction for all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information. As the federal agency responsible for administering the Medicare, Medicaid, Children’s Health Insurance Program (CHIP), and Health Insurance Exchange (HIX), CMS collects, creates, uses, discloses, maintains, and stores personal, healthcare, and other sensitive information subject to federal law, regulation, or guidance. All NIST Special Publication (SP) 800 series are applicable to CMS policy including the IS2P2.

This Policy requires all CMS stakeholders, including Business Owners and System Security and Privacy Officer (previously known as ISSO) to implement adequate information security and privacy safeguards to protect all CMS-sensitive information. The Chief Information Officer (CIO), Chief Information Security Officer (CISO), and the Senior Official for Privacy (SOP) jointly develop and maintain this document. All references contained in this Policy are subject to periodic revision, update, and reissuance.

Background

CMS Information Security and Privacy Group (ISPG), under the direction of the CMS Chief Information Security Officer (CISO) and the Senior Official for Privacy (SOP), is tasked with overseeing the Cybersecurity and Privacy Programs for the agency. Following the Federal and HHS requirements, CMS ISPG identifies cybersecurity and privacy risks, implements mitigation strategies and ensures the confidentiality, integrity and availability of CMS-sensitive information and information systems. These activities are aimed at safeguarding and preventing unauthorized disclosure of Personally Identifiable Information (PII) and Protected Health Information (PHI) entrusted to CMS.

ISPG recognized the need to develop a policy that references and incorporates the security and privacy requirements from authoritative sources while tailoring it to suit the CMS physical and information technology environments. This Policy explains the scope and applicability of security and privacy requirements as it pertains to CMS information systems. This Policy also defines the security and privacy control baselines as well as the supplemental controls available for selection and should be used in conjunction with the Acceptable Risk Safeguards (ARS), CMS process guidelines and other supporting CMS-established policies, procedures, and standards. The format of these requirements is scalable to accommodate modifications or the addition of new requirements over time as a result of the ever-changing cybersecurity landscape.

Scope

This Policy supersedes the CMS Information System Security and Privacy Policy (IS2P2) v 3.3, and supplements the HHS-OCIO-OIS-2021-11-006, HHS Policy for Information Security and Privacy Protection (IS2P) v 1.1, and it applies to all CMS personnel or entities:

• Conducting business for CMS
• Collecting or maintaining information for CMS
• Using or operating information systems on behalf of CMS whether directly or through contractual relationships.

The below list of CMS personnel or entities include, but are not limited to:

• Organizational components, centers, or offices
• Federal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.

This Policy does not supersede any other applicable laws, higher-level agency directives, or the existing labor-management agreement in place.

The contents of and the compliance with this Policy must be incorporated into the applicable contract language, as appropriate. Any contract, agreement, or other arrangement that collects, creates, uses, discloses, or maintains sensitive information, including but not limited to Personally Identifiable Information (PII) and Protected Health Information (PHI), must comply with this Policy. In some cases, other external agency policies may also apply (e.g., if a system processes, stores, or transmits Federal Tax Information [FTI]).

This Policy does not apply to any network or system that processes, stores, or transmits foreign intelligence or national security information under the cognizance of the Special Assistant to the Secretary (National Security) pursuant to Executive Order (E.O.) 12333, United States Intelligence Activities, or subsequent orders. The Special Assistant to the Secretary (National Security) is the point of contact (POC) for issuing IT security and privacy policy and guidance for these systems. Privacy Act questions should be directed to the CMS Privacy Act Officer.

Authorities

The Office of Management and Budget (OMB) designated the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) as authorities to provide guidance to federal agencies for implementing information security and privacy laws and regulations, including FISMA, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and the Privacy Act of 1974 (“Privacy Act”). This Policy addresses CMS applicable information security and privacy requirements arising from federal legislation, mandates, directives, executive orders, and the Department of Health and Human Services (HHS) policies by integrating NIST Special Publication (SP) 800-53 Revision 5, Security and Privacy Controls for Federal Information Systems and Organizations with the Department of Health and Human Services Policy for Information Systems Security and Privacy Protection (HHS IS2P) and other specific programmatic legislations and CMS regulations. The authoritative references include, but are not limited to:

• Buy American Act, 41 U.S.C §§ 8301-8305
• DHS Binding Operational Directive 18-02, Securing High-Value Assets May 7, 2018
• Executive Order 13556, the Controlled Unclassified Information (CUI) program
• E-Government Act of 2002 (44 U.S.C. Chapters 35 and 36)
• Family Educational Rights and Privacy Act (FERPA) 20 U.S.C. § 1232g
• Federal Acquisition Supply Chain Security Act of 2018
• Federal Information Processing Standards: FIPS 140-2, FIPS 199, FIPS 200, FIPS 201-1
• Federal Information Security Modernization Act of 2014 (FISMA), 44 U.S.C § 3551
• Financial Audit Manual (FAM), GAO-18-G01G: Published June 14, 2018
• Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub.L. 104–191, 110 Stat. 1936, enacted August 21, 1996)
• HHS Policy and Plan for Preparing for and Responding to a Breach of Personally Identifiable Information (PII)
• HHS Policy for Information Security and Privacy Protection (IS2P)
• Homeland Security Presidential Directive (HSPD)-12, Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004
• HSPD-12 Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004
• H.R. 1232 – Federal Information Technology Acquisition Reform
• National Archives and Records Administration, CUI Registry
• NIST SP 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
• NIST SP 800-46 Revision 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• NIST SP 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-79-2, Guidelines for the Authorization of Personal Identity Verification Card Issuers (PCI) and Derived PIV Credential Issuers (DPCI)
• NIST SP 800-88 Revision 1, Guidelines for Media Sanitization
• NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices
• NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
• NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
• NIST SP 800-152, A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS)
• NIST SP 800-171, Rev. 2, Protecting CUI in Nonfederal Systems
• NIST SP 800-175A, Guideline for Using Cryptographic Standards in the Federal Government: Directives, Mandates and Policies
• NIST SP 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms
• Office of Management and Budget (OMB), Circular A-108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act
• Office of Management and Budget (OMB), Circular A-130, Managing Information as a Strategic Resource
• OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information
• OMB memorandums M-02-01, M-03-22, M-10-22, M-10-23, M-16-17. M-14-03, M-17-12
• OPM Information systems security awareness training program, 5 CFR § 930.301
• Public Law 113-291, Title VIII, Subtitle D of the National Defense Authorization Act (NDAA) for Fiscal Year 2015
• Public Law 115-232 § 889, Prohibition on Certain Telecommunications and Video Surveillance Services or Equipment, August 13, 2018
• Section 508 of the Rehabilitation Act of 1973, as amended in 1998 (29 U.S.C 794d)
• The Privacy Act of 1974 as amended (5 U.S.C. 552a).

Document Organization

The CMS CIO, CISO, and SOP designed this Policy to comply with the NIST 800-53, Revision 5, Program Management (PM) control family. This Policy integrates information security and privacy roles, responsibilities, and controls into the CMS Information Security and Privacy Program. The key contents of this Policy include:

• An overall description of the Information Security and Privacy Program (Section 6)
• Descriptions of specific roles and responsibilities of key CMS security and privacy Stakeholders (Section 7)
• Defining HHS and CMS-specific tailored policies, policies associated with the security and privacy control families, and the consequences for non-compliance (Sections 8, 9, & 10)
• Supporting Appendices provide references, a glossary of terms, and acronyms:
  • Appendix A: References
  • Appendix B: Glossary of Terms and Acronyms.

In accordance with HHS policy, CMS must update this Policy at least every three years (36 months). In cases where existing policy is insufficient to address changes in governance (e.g., legislation, directives, mandates, executive orders, or HHS policy) or emerging technology, the CMS CIO may publish ad hoc or specialized interim directives or memorandums to address the area of concern. As appropriate, the interim directive or memorandum may be integrated into future releases of or incorporated as an appendix to this Policy. The CMS CISO and SOP may develop memorandums that provide actionable guidance that supports best practices and procedures in support of the implementation of CIO policies and directives, along with legislation, mandates, executive orders and other federal mandates.

Information Security and Privacy Program Summary

The CMS CISO and SOP are responsible for managing the Information Security and Privacy Program (henceforth “Program”). This section describes how specific functional areas of the Program help CMS stakeholders apply this Policy in protecting CMS information and information systems.

CMS security and privacy disciplines are now integrated into a single Program. However, there are requirements unique to each discipline. Privacy as well as security policies apply to CMS programs and activities at their inception, even before information systems are identified or defined. Business Owners must identify the security and privacy requirements, compliance documentation, and contract requirements prior to system development.

Privacy policies apply to the collection, creation, use, disclosure, and retention of information that identifies an individual (i.e., PII, including PHI) in electronic or physical form. CMS’s responsibility for protecting the privacy interests of individuals applies to all types of information, regardless of its form. All CMS standards, regulations, directives, practices, and procedures must clearly state that all forms of information must be protected.

Policy and Governance

The policy and governance functional area establishes and implements the information security and privacy program which develops organizational security and privacy policies, standards, directives, practices, and procedures within the CMS environment. The responsibilities include developing, implementing, and disseminating this Policy to align with and supplement HHS policies, federal legislation, and best practices. The CMS Acceptable Risk Safeguards (ARS) is the HHS Operating Division (OpDiv) of CMS’s implementation of the National Institute of Standards and Technology’s (NIST) Special Publications (SP) 800-53, Revision 5, and it contains detailed minimum control standards that are traceable to the policies contained herein. Each security and privacy control description provides CMS-specified implementation details for all the security and privacy controls allocated as a baseline to an identified CMS FISMA system based on the FIPS 199 Security Category. Additional CMS-established policies and procedures can serve as further guidance for administering CMS standards, requirements, directives, practices, and procedures for protecting CMS information and information systems.

Risk Management and Compliance

The risk management and compliance functional area provides a multi-level approach to managing information system-related security and privacy risks at the enterprise level, the mission/business process level, and the information system level to protect CMS information system assets and individuals accessing these assets. CMS provides a risk-based approach for managing information system-related security and privacy risk which is based on NIST SP 800- 37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. This framework includes developing and updating risk management and compliance processes and procedures to align with HHS policies, federal legislation, and federal cybersecurity and privacy frameworks. The CMS security and privacy program, under the direction of the Chief Information Security Officer (CISO) and the Senior Official for Privacy (SOP) oversees the agency-wide implementation of this framework which includes Security Assessment and Authorization (SA&A), Continuous Diagnostics and Mitigation (CDM), FISMA reporting, internal assessments/audits, and other external assessments/audits.

Awareness and Training

The awareness and training functional area provides organizational security and privacy awareness training and specific role-based training (RBT) for all CMS stakeholders with Significant Security Responsibilities (SSR). The responsibilities include developing curriculum and content, delivering training, ensuring training policies and procedures are current, tracking training status, and reporting on completed security awareness and RBT courses.

Cyber Threat and Incident Handling

The cyber threat and incident handling functional area support CMS’s cyber threat intelligence, information sharing, and incident handling, including breach response. The responsibilities include developing, updating, and disseminating processes and procedures to coordinate information sharing and investigating incidents across CMS, following established CMS incident Response (IR) procedures.

Continuity of Operations

The continuity of operations functional area provides plans and procedures to ensure continuity of operations for information systems that support CMS operations and assets. The responsibilities include developing processes and procedures for system contingency planning, disaster recovery, and participation in federal continuity exercises.

Roles and Responsibilities

This section details significant information security and privacy roles and responsibilities for CMS stakeholders. The responsibilities, defined by role rather than position, are derived from the HHS Policy for Information Systems Security and Privacy Protection (IS2P), RBT requirements, and CMS-specific responsibilities. This section also enhances the responsibilities defined within the HHS Policy for Information Systems Security and Privacy Protection (IS2P), to address CMS’s needs. Therefore, CMS stakeholders must also refer to the HHS Policy for Information Systems Security and Privacy Protection (IS2P) for additional detail.

A current version of the HHS Policy for Information Systems Security and Privacy Protection (IS2P) may be requested via the HHS Office of Information Security (OIS) mailbox at HHSCybersecurityPolicy@hhs.gov.

Most of the roles described in this section are restricted to federal employees based on the specific position and role they fulfill within the CMS organization, while others may be filled by either a federal employee or a contractor.

For additional information, please check CMS Organizational Charts.

General Roles

All CMS personnel, whether federal employees, contractors (including subcontractors), or entities operating on behalf of CMS, must adhere to the information security and privacy responsibilities defined within this section. This subsection describes CMS-specific responsibilities for the roles “All Users” and “Supervisors.”

Federal Employees and Contractors (All Users)

All CMS federal employees and contractors (including subcontractors) must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P), Section 7.36, All Users. All users have the responsibility to protect CMS’s information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction by complying with the information security and privacy requirements maintained in this Policy.

In addition to the HHS IS2P the responsibilities of the CMS federal employees and contractors must include, but are not limited to the following:

• Consider all browsing activities sensitive.
• Notify the CMS CISO and SOP of actual or suspected information security and privacy incidents and breaches, including CMS sensitive data, using CMS specified procedures established in the CMS Incident Response (IR) procedures and applicable Rules of Behavior (RoB).
• Complete mandatory security and privacy awareness training before accessing CMS information systems and annually thereafter.
• For all newly hired personnel and staff, and those who transfer into a new position with significant security and/or privacy responsibilities, complete specialized security or privacy RBT as appropriate for their assigned roles within 60 days of entry on duty or upon assuming new responsibilities. Thereafter, they must complete RBT at least annually.
• For contractors with significant security and/or privacy responsibilities, complete specialized RBT within 60 days of beginning work on a contract. They must complete RBT at least annually thereafter.
• Report anomalies when CMS programs, systems, or applications are collecting, creating, using, disclosing, or retaining more than the minimum data necessary.

Supervisors

Supervisors may be federal employees or contractors2 and must fulfill all responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.37, Supervisors.

In addition to the HHS IS2P, the responsibilities of Supervisors include, but are not limited to, the following:

• Notify the appropriate System Security and Privacy Officer (Previously known as ISSO) (or the CMS CISO or designee, if the System Security and Privacy Officer (Previously known as the ISSO)  is not available) within one hour of any unexpected departure or separation of a CMS employee or contractor.
• Ensure personnel under their direct report complete all required information security training, including privacy and RBT, within the mandated time frames established in the CMS Incident Response (IR) procedures.
• Ensure background checks are conducted on all individuals identified by system owners with access to CMS information systems in accordance with position sensitivity designation as derived by the use of the appropriate CMS tool.

Human Resource Officer

Human Resource Officer must be an agency official (federal government employee) and must fulfill the responsibilities that include, but are not limited to, the following:

• Coordinating with appropriate CMS CIO POCs and Office of Security, Facilities and Logistics Operations (OSFLO) POCs to ensure background checks are conducted for individuals with significant security responsibilities.
• Notifying the appropriate CMS POC (Manager, Supervisor, COR or CIO designated official) within one business day when CMS personnel are separated from the Department.
• Ensuring relevant paperwork, interviews, and notifications are sent to the appropriate CMS POC (Manager, Supervisor, COR or CIO designated official) when personnel join, transfer within, or leave the organization, either permanently or on detail.
• Participating at the request of the CMS CCIC in the investigation of Federal employees with regard to security incidents.
• Participating at the request of the CMS CCIC in the investigation of Federal employees relative to PII breaches and violations.
• Ensuring all HR systems and records/data are maintained, used and shared in compliance with the Privacy Act of 1974, as amended (5 U.S.C. 552a) and the HHS implementing regulations and applicable Systems of Records Notices (SORNs), and, all other applicable laws, policies and procedures.

CMS Federal Executives

This subsection describes the information security and privacy responsibilities of CMS Federal Executives, including the Administrator, Chief Financial Officer (CFO), Personnel and Physical Security Officers (PPSO), and Operations Executive (OE). Only agency officials (federal government employees) are authorized to fill these roles.

Administrator

The Administrator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.2, OpDiv Heads, including “Delegating responsibility and authority for management of HHS Operating Division (OpDiv) IT security and privacy programs to the OpDiv CIOs,” and those identified in the HHS Policy and Plan for Preparing for and Responding to a Breach of Personally Identifiable Information (PII). These responsibilities include:

• Delegating responsibility and authority for making final decisions regarding external breach notification and issuing written notification to individuals affected by a privacy breach.
• Receiving inquiries, investigations, or audits from enforcement authorities, such as any initiated by the HHS Office for Civil Rights related to compliance with HIPAA or the HIPAA Privacy and Security Rules and coordinating responses with the Chief Information Officer and other appropriate staff.

HHS’s Continuity of Operations Program Policy also requires that the Administrator must:

• Incorporate continuity of operations requirements into all CMS activities and operations
• Designate in writing an accountable official as the Agency Continuity Point of Contact, who is directly responsible to the Administrator for management oversight of the CMS continuity program and who is the single point of contact for coordination within CMS for continuity matters.

Chief Financial Officer

The CFO must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.3, Office of Finance (OF)/Assistant Secretary for Financial Resources (ASFR)/Chief Financial Officer (CFO).

Personnel and Physical Security Officer

The PPSO must fulfill the shared responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P), Section 7.6, Office of National Security (ONS). In addition to the HHS IS2P, the general and incident response responsibilities of the PPSO must include, but are not limited to:

General

• Protect employees, visitors, and CMS-owned and CMS-occupied critical infrastructure
• Coordinate national security information services to all components within the Office of the Administrator (OA).
• Coordinate with appropriate CMS CIO POCs and HHS POCs to ensure background checks are conducted on all individuals identified by system owners with access to CMS information systems in accordance with position sensitivity designation as derived by the use of the appropriate CMS tool.

Incident Response

• Participate at the request of law enforcement, the HHS Computer Security Incident Response Center (CSIRC), the HHS Office of the Inspector General (OIG), and/or the CMS Cybersecurity Integration Center (CCIC) in investigating security and privacy incidents and breaches involving federal employees and/or CMS contractor personnel.
• Participate at the request of the HHS Privacy Incident Response Team (PIRT) and/or the CMS Breach Analysis Team (BAT) in investigating incidents and/or violations involving federal employees, PII, PHI, and/or Federal Tax Information (FTI).

Operations Executive

The Operations Executive must fulfill the responsibilities that include, but are not limited to, the following:

• Oversee day-to-day information security and privacy operations for CMS employees.
  • Develop and maintain, in coordination with the CISO and SOP, the HHS Rules of Behavior for Use of HHS Information and IT Resources Policy, to address, at a minimum, the following Acceptable Use standards:
    • Privacy requirements must be identified in contracts and acquisition-related documents.
    • Personal use of CMS IT resources must comply with HHS Policy for Personal Use of Information Technology Resources, such that personal use of CMS IT resources does not put CMS data at risk of unauthorized disclosure or dissemination.
  • Ensure all CMS system users annually read and sign the HHS Rules of Behavior for Use of HHS Information Resources, which governs the appropriate use of CMS IT resources.
  • Inform CMS employees and contractors that use of CMS information resources, other than for authorized purposes, is a violation of the HHS RoB and Article 35 of the Master Labor Agreement and is grounds for disciplinary action, up to and including removal from federal service, monetary fines, and/or criminal charges that could result in imprisonment. CMS bargaining unit employees must also adhere to Article 35 of the Master Labor Agreement.
  • Ensure CMS employees and contractors encrypt CMS sensitive information transmitted to a non-CMS controlled environment,7 including but not limited to email, using Federal Information Processing Standard (FIPS) 140-3 compliant encryption solutions/modules.
  • Ensure CMS employees and contractors are prohibited from transmitting sensitive CMS information using any non-CMS approved, Internet-based mechanism, including but not limited to, personal email, file-sharing, file transfer, or backup services.
  • Ensure that any CMS contractor, other person, or organization that performs functions or activities that involve the use or disclosure of PHI on behalf of CMS have Business Associate Agreement provisions in their contracts or agreements per OAGM standard contract language requirements.
  • Ensure CMS uses PII internally only for the purpose(s) that are authorized by statute, regulation, or Executive Order; and when the PII is also considered PHI for treatment, payment, healthcare operations, or as permitted under HIPAA (e.g., for research as permitted under 45 CFR §164.512).

Office Director, Office of Enterprise Data and Analytics and Chief Data Officer

• The Office Director of the Office of Enterprise Data and Analytics (OEDA) also serves as the CMS Chief Data Officer (CDO). The CDO must be an agency official (federal government employee). The CDO must establish and implement policies, practices, and standards for maximizing the value and impact of CMS data for internal and external stakeholders.

  OEDA develops and implements a data services strategy to maximize use of data on all CMS programs, including issue papers, chart books, dashboards, interactive reports, data enclave services, public use files, and research identifiable files. OEDA oversees the creation of data sets that de-identify individuals and makes these data sets publicly available when there is legal authority permitting their creation. Methods for creating these data sets may include:

• The methodology set out at 45 CFR §164.514(b)(2) (the “Safe Harbor Rule”).
• The methodology set out at 45 CFR §164.514(b)(1) (the “Expert Determination Rule”)

• OEDA also oversees the creation of “limited data sets” (LDS), which are data sets to be used or disclosed for purposes of research, public health, or healthcare operations, using the methodology set out at 45 CFR §164.514(e).

  The Administrator may designate other specific responsibilities to the CDO as necessary.

Office Director, Office of Acquisition and Grants Management and Head of Contracting Activity

The Office Director of the Office of Acquisition and Grants Management (OAGM) and Head of Contracting Activity (HCA) also serve as the CMS Chief Acquisition Officer (CAO). The CAO must be an agency official (federal government employee) designated to advise and assist the head of the agency and other agency officials to ensure that the mission of CMS is achieved through the management of the agency’s acquisition activities. The responsibilities of the Chief Acquisition Officer include, but are not limited to:

• Advise and assist the administrator and other agency officials to ensure that the mission of CMS is achieved through the management of the agency's acquisition activities.
• Coordinate with the authorizing official, business owners, system owners, common control providers, chief information security officer, senior official for privacy, and risk executive (function) to ensure that security and privacy requirements are defined in organizational procurements and acquisitions.
• Monitor the performance of the acquisition activities and programs.
• Establish clear lines of authority, accountability, and responsibility for acquisition decision-making within CMS.
• Manage the direction and implementation of the acquisition policy.
• Establish policies, procedures, and practices that promote full and open competition from responsible sources to fulfill best value requirements considering the nature of the property or service procured.

Center and Office Executive

Each CMS Center and Office Executive must nominate an appropriately qualified staff member as a Data Guardian to the Senior Official for Privacy (SOP) for approval. The executive must ensure the Data Guardian meets the following qualifications:

• Be a proficient consumer advocate
• Have experience in identifying information security and privacy requirements
• Be trained in using the CMS Risk Management Framework (RMF)
• Understand the CMS Center/Office business processes and operations
• Have respect for the role and impact PII and PHI play within the Center/Office and across the CMS enterprise.

Information Security and Privacy Officers

This subsection describes the information security and privacy responsibilities of those federal employees with roles related to establishing this Policy and the associated Program designed to protect CMS information and information systems, including the CIO, CISO, SOP, Privacy Act Officer, Chief Technology Officer (CTO), Configuration Management Executive, Cyber Risk Advisor (CRA), Privacy Advisor, and Marketplace Senior Information Security Officer.

Chief Information Officer

The CIO must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.11, OpDiv CIOs, including serving as the Chief Risk Officer and Authorizing Official (AO) for all CMS FISMA systems. There is only one AO for all CMS FISMA systems.

The responsibilities of the CIO must also include, but are not limited to, the following:

• Designate the CISO as the authority for managing CMS incident response activities identified in the HHS Policy and Plan for Preparing for and Responding to a Breach of Personally Identifiable Information (PII)
• Define recommended minimum System Security and Privacy Officer (previously known as ISSO) qualifications commensurate with the System Security and Privacy Officer (previously known as ISSO) role within CMS for both federal employees and contractors defined with NIST Significant Information Security and Privacy Responsibilities (SISPRs)
• Define mandatory information security and privacy training, education, and awareness activities undertaken by all personnel, including contractors, commensurate with identified roles and responsibilities
• Share threat information as mandated by the Cybersecurity Enhancement Act of 2014
• Coordinate with the CISO to establish configuration management processes and procedures
• Create and manage the review and approval of changes through the appropriate IT governance; change control bodies/boards
• Coordinate with the CISO, SOP, Data Guardian, System Security and Privacy Officer (previously know as ISSO), and Website Owner/Administrator to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and applications
• Respond to any inquiries, investigations, or audits received from enforcement authorities, such as any initiated by the HHS Office for Civil Rights related to compliance with HIPAA or the HIPAA Privacy and Security Rules
• Ensure that all CMS key stakeholders, including the Chief Financial Officer (CFO); Office Director, Office of Acquisition and Grants Management (OAGM) and Head of Contracting Activity (HCA); Senior Official for Privacy (SOP); mission, business, and policy owners; as well as the CISO organizations, are aware of risks associated with High Value Assets (HVAs)
• Ensure the establishment and implementation of an HHS-specific or CMS-specific HVA Policy and HVA Management Program.

Chief Information Security Officer

The CISO must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.12, OpDiv CISOs. The CISO carries out the CIO’s information security responsibilities under federal requirements in conjunction with the SOP.

The responsibilities of the CISO must also include, but are not limited to, the following:

• Define information security and privacy control requirements through the CMS ARS.
• Publish CISO Directives as required to augment existing policy.
• Review any requested waivers and deviations from this Policy and provide recommendations to the AO for risk acceptance.
• Serve as the security official who is responsible for the development and implementation of the policies and procedures that are required by the HIPAA Security Rule (please refer to 45 CFR §164.308(a)(2)).
• Delegate the authority to approve system configuration deviations to the CRA and System Security and Privacy Officer (previously known as the ISSO), where appropriate.
• Ensure CMS-wide implementation of HHS and CMS information security and privacy capabilities, policies, and procedures consistent with the NIST Risk Management Framework (RMF).
• Lead the investigation and resolution of information security and privacy incidents and breaches across CMS.
• Define and oversee the goals and requirements of Agency Security Operations.
• Coordinate incident response and threat information sharing with the HHS CSIRC and/or HHS PIRT, as appropriate.
• Ensure the information security continuous monitoring (ISCM) capabilities accomplish the goals identified in the ISCM strategy.
• Publish an Ongoing Authorization process as part of the Program
• Approve the appointment of the System Security and Privacy Officer (previously know as ISSO) by the Program Executive
• Approve the independent security control assessment deliverables
• Coordinate with the CIO, SOP, Data Guardian, System Security and Privacy Officer (previously known as ISSO), and Website Owner/Administrator to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and applications.
• Authorize the immediate disconnection or suspension of any interconnection by coordinating with the SOP and the CCIC Director to (1) disconnect or suspend interconnections and (2) ensure interconnections remain disconnected or suspended until the AO orders reconnection.

Risk Executive (Function)

The Risk Executive must be an agency official (federal government employee). The Risk Executive must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.13. Risk Executive (Function). The Administrator may designate specific responsibilities to the RE as necessary.

The Risk Executive must also fulfill the responsibilities for agency-wide risk management strategies that include, but are not limited to, the following:

• Coordinate with the CCIC to:
• Manage risk(s) identified in the threat landscape via; cyber threat intelligence, vulnerability assessment, penetration testing, forensics, malware, insider threat, etc., and security and privacy risk(s) identified via; risk assessments, security control assessments, internal/external audits, etc. (including supply chain risk[s] via the Division of Strategic Information [DSI]) information for organizational systems and the environments in which the systems operate.
• Use the CDM program to identify and report on the risk posture of the portfolio of FISMA reported systems in near real time
• Utilize the CFACTS system to report on the risk posture of the FISMA reported systems.

Senior Official for Privacy

The SOP must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.18, OpDiv SOP also include, but are not limited to, the following:

• Lead CMS privacy programs and promote proper information security and privacy practices.
• Lead the development and implementation of privacy policies and procedures, including the following actions:
  • Evaluate any new legislation that obligates the Program to create any regulations, policies, procedures, or other documents concerning collecting, creating, using, disclosing, or retaining PII/PHI.
  • Ensure an appropriate party will develop all such required policies or other documents.
  • Ensure policies exist to impose criminal penalties and/or other sanctions on CMS employees (consistent with the CMS Master Labor Agreement) and non-employees, including contractors and researchers, for violations of law and policy.
• Ensure privacy controls are implemented and enforced.
• Serve as the privacy official responsible for developing and implementing policies and procedures, receiving complaints, and providing further information related to the Notice of Privacy Practices, as required by the HIPAA Privacy Rule (please refer to 45 CFR §164.530(a)).
• Ensure individuals are able to exercise their rights to access, inspect, request additions or amendments, and obtain copies of their PII/PHI in a designated record set or in a Privacy Act system of records (SOR).
• Ensure individuals are able to exercise their right to an accounting of disclosures of their PII/PHI by CMS or its business associates.
• Ensure any use or disclosure of PII/PHI that is not for treatment, payment, health operations, or otherwise permitted or required by the HIPAA Privacy Rule or Privacy Act is disclosed only with the individual’s authorization.
• Ensure the Program develops and documents a Notice of Privacy Practices for all Medicare Fee-for-Service beneficiaries, as required by the HIPAA Privacy Rule, that defines the uses and disclosures of PHI.
• Coordinate with the CIO, CISO, Data Guardian, System Security and Privacy Officer (previously known as ISSO), and Website Owner / Administrator to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and applications.
• Coordinate as the lead and collaborate with the CISO to:
  • Document privacy requirements and manage privacy implementation as CMS information systems are designed, built, operated, or updated
  • Provide recommendations to the CIO regarding the privacy posture of FISMA systems and the use/disclosure of CMS information
• Co-chair the CMS Data Governance Board.
• Approve the appointment of Data Guardians by the Center or Office Executive.
• Provide overall direction for incident handling, which includes all incidents involving PII/PHI.
• Authorize the immediate disconnection or suspension of any interconnection
  • Coordinate with the CISO and the CCIC Director to disconnect or suspend interconnections
  • Coordinate with the CISO and the CCIC Director to ensure interconnections remain disconnected or suspended until the AO orders reconnection
  • Review HVAs and identify those that create, collect, use, process, store, maintain, disseminate, disclose, or dispose of PII/PHI
  • Ensure that all required privacy documentation and materials are complete, accurate, and up to date.

Privacy Act Officer

The Privacy Act Officer must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.20, OpDiv Privacy Act Contact.

The responsibilities of the Privacy Act Officer must also include, but not be limited to, the following:

• Develop, implement, and maintain policies and procedures related to the Privacy Act.
• Process Privacy Act requests, including requests requiring exceptions to the Privacy Act.
• Provide guidance and advice on federal Privacy Act policies and procedures.
• Evaluate the impact of the Privacy Act and regulations on the organization’s activities.
• Coordinate with CMS Offices and staff as needed.
• Represent CMS on issues related to the Privacy Act.
• Assess Privacy Act-related risks associated with programs, operations, and technology.
• Support efforts across CMS to comply with the Privacy Act.
• Plan and conduct training sessions on Privacy Act requirements.
• Ensure procedures exist to:
  • Authenticate the identity of a person requesting PII/PHI and, as appropriate, the authority of any such person permitted access to PII/PHI
  • Obtain any documentation, statements, or representations, as appropriate, whether oral or written, from the authorized person requesting the PII/PHI
  • In responses to requests for disclosures, limit the PII/PHI disclosed to that which is the minimum amount reasonably necessary to achieve the intended purpose of the disclosure or request, relying (if such reliance is reasonable under the circumstances) on the precise scope of the requested disclosure to determine the minimum necessary information to be included in the disclosure
  • In structuring all CMS processes, ensuring that to the greatest degree practicable each person receives only the PII/PHI data elements and records that the person needs (e.g., the data elements the person needs to perform all tasks within the scope of their assigned responsibilities); When CMS requests PII/PHI from third parties, ensure the PII/PHI requested is limited to the amount reasonably necessary to accomplish the purpose for which the request is made.

Chief Technology Officer

The Chief Technology Officer (CTO) must be an agency official (federal government employee). The CIO may designate specific responsibilities to a CTO as necessary.

Configuration Management Executive

The Configuration Management Executive must be an agency official (federal government employee) and must provide executive-level oversight for configuration management and contingency planning.

Cyber Risk Advisor

The Cyber Risk Advisor (CRA) may be federal employees or contractors. The CISO may designate the authority to approve system configuration deviations to the CRA where appropriate.

The responsibilities of the CRA must also include, but are not limited to, the following:

General

• Act as the subject matter expert in all areas of the CMS RMF.
• Evaluate, maintain, and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the AO.
• Support the CMS stakeholders in ensuring that all requirements specified by the CMS ARS are implemented and enforced; serve as an active participant in the system development life cycle (SDLC) / Technical Review Board (TRB); provide requirements; and recommend design tradeoffs considering security, functionality, and cost.
• For each FISMA system or collection of PII/PHI, coordinate with the Data Guardian, Information System Owner (ISO), Business Owner, and System Security and Privacy Officer (previously known as ISSO) to:
  • Identify the types of information processed
  • Assign the appropriate security categorizations to the information systems
  • Ensure that CMS has the legal authority, either under a statute or an executive order, to conduct activities involving the collection, use, and disclosure of PII/PHI
  • Determine the privacy impacts and manage information security and privacy risk.
• Ensure information security and privacy testing is performed throughout the SDLC as appropriate and results are considered during the development phase of the SDLC.
• Monitor system security posture by reviewing all proposed information security and privacy artifacts to provide recommendations to the System Security and Privacy Officer (previously known as ISSO).
• Provide guidance to CMS stakeholders on required actions, potential strategies, and best practices for closure of identified weaknesses.
• Upload findings spreadsheets to the CMS FISMA Controls Tracking System (CFACTS).
• Ensure AO-issued authorization is updated in CFACTS.
• Serve as the authority to approve selected system configuration deviations from the required baseline.
• Remind System Security and Privacy Officer (previously known as ISSO) with expiring or expired letters to resubmit their appointment letters using a new letter.
• Upload signed System Security and Privacy Officer (previously known as ISSO) appointment letter(s) to CFACTS.
• Coordinate with the BO, ISO, PA, and the System Security and Privacy Officer (previously known as ISSO) in documenting Risk-based Decisions which impact the organizational FISMA system in accordance with CMS Acceptable Risk Safeguards.

Privacy Advisor

Privacy Advisors may be federal employees or contractors and work under the direction of the SOP. The Privacy Advisor must fulfill responsibilities that include, but are not limited to the following:

• Identify opportunities to integrate Fair Information Practice Principles (FIPP) into CMS business processes and information systems.
• Evaluate legislation, regulations, and policies that may affect how CMS collects, uses, stores, discloses, or retires PII; identify their potential impacts on CMS; and recommend responsive actions to the CMS management or others that request guidance.
• For IT systems, coordinate with the Business Owner, CRA, Data Guardian, ISO, and System Security and Privacy Officer (previously known as ISSO) to identify the types of information processed, assign the appropriate security categorizations to the information systems, determine the privacy impacts, and manage information security and privacy risk, including:
  • Review the Privacy Impact Assessment (PIA) and existing CFACTS documentation to verify that the PIA follows HHS/CMS guidance and verify that privacy risks have been appropriately documented
  • Evaluate privacy-related agreements (e.g., Computer Matching Agreements [CMA], Information Exchange Agreements [IEAs], and Memoranda of Agreement / Understanding [MOA/MOU]) to verify that privacy requirements are satisfied and privacy risks are adequately addressed, both initially and when periodically reviewed, and provide guidance and advice on these agreements to Business Owners, ISOs, and other CMS staff as needed
  • Continuously monitor all findings of privacy risk or deficiency, including by monitoring progress against privacy-related POA&Ms
  • Track the progress of enterprise privacy risk mitigation activities across portfolios
• Provide ISPG perspective during TRB reviews to assess the impact of changes to IT systems on privacy issues and work to mitigate those impacts.
• Work with System Security and Privacy Officer (previously known as ISSO) to evaluate system changes to determine whether privacy risks are sufficiently significant to require updates to Authority To Operate (ATO) documents.
• Work with BO, ISO, CRA, and the System Security and Privacy Officer (previously known as ISSO) in documenting Risk-based Decisions which impact their organizational FISMA system in accordance with CMS Acceptable Risk Safeguards.
• Works with CRAs to verify that decommission and disposition plans for IT systems do not create significant privacy risks.
• Assist in developing reports on any aspect of privacy requested by CMS senior management, HHS, external auditors, or any other party authorized to request and receive such information.
• Provide recommendations concerning the privacy risks and practices relevant to IT systems.
• Provide incident handling support for incidents involving PII.
• Advise CMS healthcare programs on compliance with privacy and related cybersecurity requirements.

Affordable Care Act (ACA) Senior Information Security Officer

The ACA Senior Information Security Officer must be an agency official (federal government employee).

The responsibilities of the ACA Senior Information Security Officer must include, but are not limited to, the following:

• Ensure the overall information security and privacy of the Health Insurance Marketplace (HIM) by driving integration, collaboration, and innovation across disparate groups under the HIM program.
• Represent the interests of the CCIIO, as well as the CIO, CISO, and SOP by integrating the work of the managers and staff of multiple units to ensure an acceptable information security and privacy posture through visibility, compatibility, and situational awareness.
• Provide technical and policy guidance during all phases of the SDLC to balance risk-based tradeoffs among information security, privacy, functionality, and cost.

CMS Records Officer

The CMS Records Officer must be an agency official (federal government employee), and must fulfill the responsibilities that include, but are not limited to, the following:

• Ensuring compliance with the Federal Records Act of 1950, National Archives and Records Administration (NARA) regulations and/or guidance, OMB directives, and Government Accountability Office (GAO) audit requirements.
• Serving as Chairperson of the CMS Records Management Office.
• Develop CMS records management policies and procedures.
• Providing agency-wide guidance, training, and assistance for compliance with laws and regulations

Supply Chain Risk Management (SCRM) Manager

The SCRM Manager must be an agency official (federal government employee), and must fulfill the responsibilities that include, but are not limited to, the following:

• Managing the development, documentation, and dissemination of the supply chain risk management policy and procedures.
• Analyze and assess the effects and impacts of existing and proposed federal legislation on CMS policies as it relates to supply chain risk management.
• Facilitate or attend SCRM-related working group meetings to promote supply chain risk management program and share policy updates and supply chain risk challenges and solutions to relevant CMS stakeholders.
• Research, identify, analyze and recommend countermeasures and mitigations for supply chain risks that promote supply chain resilience.

Program and Information System Roles

This subsection describes the information security and privacy responsibilities of those with roles related to CMS programs and the associated information systems. Program Executives oversee CMS programs and may also serve as ISOs and/or Business Owners. ISOs, referred to as “System Owners” in the HHS Policy for Information Systems Security and Privacy Protection

(IS2P), take responsibility for the operation of information systems required by the CMS program. Business Owners, referred to in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) as “Data Owners/Business Owners,” take primary responsibility for the information and data processed by the CMS program.

This subsection also identifies specific information security and privacy responsibilities of the ISOs, Data Guardians, Business Owners, Contracting Officers (CO), Contracting Officer’s Representatives (COR), and Program/Project Managers. This subsection also describes the responsibilities of the System Security and Privacy Officer (previously known as ISSO), including auxiliary responsibilities of the Security Control Assessor and Contingency Planning Coordinator (CPC) that may be filled by the System Security and Privacy Officer (previously known as ISSO). The final subsection describes specific responsibilities of the Security Operations Center/Incident Response Team (SOC/IRT).

Information System Owner

The CMS ISO must be an agency official (federal government employee) and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23 IS2P, System Owner.

The responsibilities of the CMS ISO must also include, but are not limited to, the following:

• In coordination with the Data Guardian and Business Owner
  • Nominate appropriately qualified System Security and Privacy Officer (previously known as ISSO) appointees, as defined under FISMA, to the CISO for approval.
  • Ensure that information security and privacy for each information system are planned, documented, and integrated from project inception through all phases of the CMS SDLC.
  • Consult and coordinate with the CIO and SOP to identify, negotiate, and execute appropriate governing artifacts and agreements before sharing CMS information.
  • Identify program or system roles that have NIST Significant Information Security or Privacy Responsibilities (SISPRs) within their purview and oversee the system-specific Rules of Behavior (RoB) training applicable to system(s) in their portfolio.
• For each FISMA system or collection of PII/PHI, coordinate with the Data Guardian, Business Owner, CRA, Privacy Steward, and System Security and Privacy Officer (previously known as ISSO) to:
  • Identify the types of information processed
  • Ensure that CMS or the component of CMS conducting the collection of PII/PHI has the legal authority, either under a statute or an executive order, to conduct activities involving the collection, use, sharing, and disclosure of PII/PHI and subsequent appropriate disposal after disposition and retirement
• Ensure each system’s Change Control Board (CCB):
• Is an integral part of the information system change management process.
• Implements applicable governing standards as defined in the ARS.
• Supports the creation of baseline configuration documentation to reflect ongoing implementation of the operational configuration baseline updates.
• Supports the change management processes to address change requests (CRs) for each system so that an appropriate Security Impact Analysis is performed by the System Security and Privacy Officer (previously known as ISSO) or designated staff
• Approves System Security and Privacy Officer (previously known as ISSO) information security configuration recommendations to address weaknesses and system deficiencies.
• Ensure employees and contractors receive the appropriate training and education regarding relevant information security and privacy laws, regulations, and policies governing the information assets they are responsible for protecting.
• Serve as the attestation official for approving the common controls provided by the system.
• Include the Security Control Assessor or representative from the system as a member of the CCB in all configuration management processes that include the system. If the System Security and Privacy Officer (previously known as ISSO) or Security Control Assessor acts as a voting member of the CCB, they must be federal employees.
• Maintain change documentation in accordance with the CMS Records Retention Policy
• Coordinate with BO, CRA, PA, and the System Security and Privacy Officer (previously known as ISSO) in documenting Risk-based Decisions which impact their organizational FISMA system in accordance with CMS Acceptable Risk Safeguards.

Data Guardian

The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.27, Data Owner/Business Owner.

The responsibilities of the CMS Data Guardian must also include, but are not limited to, the following:

General

• Represent the Center or Office on the Data Guardian Committee under the auspices of the CMS Data Governance Board to ensure a coordinated and consistent approach to protecting PII across the CMS enterprise.
• For each FISMA system or collection of PII/PHI, coordinate with the ISO, Business Owner, CRA, and ISSO (Now referred to as Security and Privacy Officer) to:
  • Identify the types of information processed
  • Ensure that CMS has the legal authority, either under a statute or an executive order, to conduct activities involving the collection, use, and disclosure of PII/PHI
  • Assign the appropriate security categorizations to the information systems
  • Determine the privacy impacts
  • Manage information security and privacy risk.
• Identify and pursue opportunities to proactively enhance information security and privacy controls and increase awareness of the evolving information security and privacy threats to the information assets of the Center or Office.
• Attend quarterly Data Guardian Meetings.

Privacy

• Safeguard PII by creating an information security and privacy awareness culture that adheres to information security and privacy standards and requirements designed to protect CMS data assets as directed by the CISO and SOP.
• Gather lessons learned and communicate best practices for protecting PII to their Center or Office.
• Participate in incident response activities affecting the Center or Office information security and privacy posture.

Business Owner

The CMS Business Owner must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.27, Data Owner/Business Owner in coordination with the Data Guardian. CMS Business Owners are the Group Directors or Deputy Group Directors who have the primary business needs that are or will be addressed by CMS IT investments/projects. The responsibilities of the CMS Business Owner must also include, but are not limited to, the following:

General

• Comply with the requirements of the CMS Policy for IT Investment Management & Governance or its successor policy.
• For each FISMA system and collection of PII/PHI, coordinate with the Data Guardian, ISO, CRA, and System Security and Privacy Officer (previously known as ISSO) to:
  • Identify the types of information processed
  • Ensure that CMS has the legal authority, either under a statute or an executive order, to conduct activities involving the collection, use, and disclosure of PII/PHI
  • Assign the appropriate security categorizations to the information systems
  • Determine the information security and privacy impacts
  • Manage information security and privacy risk.
• Work with the COs and CORs to determine the minimum necessary PII/PHI required to conduct the activity for which the agency is authorized.
• Coordinate with the COs and CORs, Data Guardian, Program/Project Manager, the CISO, and the SOP to ensure appropriate information security and privacy contracting language from relevant sources is incorporated into each IT contract. Relevant sources must include, but are not limited to, the following:
  • HHS ASFR
  • HHS Office of Grants and Acquisition Policy and Accountability (OGAPA)
• CMS Office of Acquisition and Grants Management (OAGM).
• For each FISMA system and collection of PII/PHI, coordinate with the Data Guardian, ISO, CRA, and System Security and Privacy Officer (previously known as ISSO) to ensure compliance with the CMS ARS, and when collecting or using FTI, with Internal Revenue Service (IRS) Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies10.
• Coordinate with ISO, CRA, PA, and the System Security and Privacy Officer (previously known as ISSO) in documenting Risk-based Decisions which impact their organizational FISMA system in accordance with CMS Acceptable Risk Safeguards.

Privacy

• Document data that are collected and maintained and certify that the data are authorized, relevant, and necessary to CMS’s mission.
• Own the information stored, processed, or transmitted in CMS’s information systems and limit access to the data/information.
• Manage and approve all use and disclosure of data from CMS programs or systems that are permitted by routine use under CMS System of Records Notices (SORN) through appropriate vehicles to authorize or deny the release of PII.
• Verify that CMS’s programs or systems only disclose the minimum data necessary.
• Determine and certify that the information security and privacy controls that protect CMS’s systems are commensurate with the sensitivity of the data being protected.
• Establish and revise, in coordination with the Privacy Act Officer, SORNs and computer matching agreements in accordance with the established procedures.
• Prepare PIAs for programs or systems in accordance with the direction provided by the CRA.
• Support the analysis of incidents involving PII and the determination of the appropriate action to be taken regarding external notification of privacy breaches as well as the reporting, monitoring, tracking, and closure of PII incidents.

Contracting Officer and Contracting Officer's Representative

The CMS CO and COR must be agency officials (federal government employees) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.34, CO and COR.

The responsibilities of the CMS CO and COR must also include, but are not limited to, the following:

• Ensure the CISO, SOP, Privacy Act Officer, and Data Guardian are consulted during contract development and that the latest information security and privacy contract language is included in all contracts, as applicable.
• Work with the Business Owner to determine the minimum necessary PII/PHI required to conduct each activity for which the agency is authorized.

• Collect training records demonstrating that all CMS contractors with significant security and/or privacy responsibilities complete specialized RBT commensurate with their roles 

  within 60 days of beginning work on a contract, upon commencement of the contractors’ work, annually thereafter, and upon request.

Program/Project Manager

The CMS Program/Project Manager must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.35, Project/Program Manager in coordination with the Data Guardian.

The responsibilities of the CMS Program/Project Manager must also include, but are not limited to, the following:

General

• Ensure information security and privacy-related actions identified by the CMS SDLC meet all identified information security and privacy requirements.

Privacy

• Ensure contractors follow all required information security and privacy policies, standards, and procedures
• Ensure contractors follow all required procedures and provide all required documentation when requesting/gaining access to PII
• Ensure contractors use the minimum data required to perform approved tasks
• Ensure contractors return data covered by approved information sharing agreements at the end of the contract or task to the COR for proper destruction
• Ensure appropriate notification and corrective actions, as described in the CMS Incident Handling procedure, are taken when a privacy breach is declared and involves a contractor or a public-private partnership operating a SOR on behalf of CMS.

Primary System Security and Privacy Officer (previously known as P-ISSO) 

The CMS Primary System Security and Privacy Officer (previously known as P-ISSO) may be either a federal government employee or a contractor and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers (previously referred to as ISSO). The System Security and Privacy Officer (previously known as ISSO) must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Sections 7.26 and 7.30, and further elaborated in this subsection.

The responsibilities of the CMS Primary System Security and Privacy Officer (previously known as P-ISSO)) must also include, but are not limited to, the following:

General

• For each FISMA system or collection of PII/PHI, coordinate with the Data Guardian, ISO, Business Owner, PA, and CRA to:
  • Identify the types of information processed
  • Ensure that CMS has the legal authority, either under a statute or an executive order, to conduct activities involving the collection, use, and disclosure of PII/PHI
  • Assign the appropriate security categorizations to the information systems
  • Determine the information security and privacy impacts
  • Manage information security and privacy risk
• Report compliance on secure protocol use in websites periodically as defined within the CMS ARS.
• Submit System Security and Privacy Officer (previously known as ISSO) appointment letter for assigned system when nominated for approval and resubmit every two (2) years for review.
• Submit recommendations to the CRA for system configuration deviations from the required baseline.
• Coordinate with the CIO, CISO, SOP, Data Guardian, and Website Owner/Administrator to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and application.
• Coordinate with the System Developer and Maintainer in identifying the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems.
• Document the controls in the information security and privacy plan (or equivalent document) to ensure implemented controls meet or exceed the minimal controls defined by CISO guidance.
• Coordinate with BO, CRA, and the PA in documenting Risk-based Decisions which impact their organizational FISMA system in accordance to CMS Acceptable Risk Safeguards.
• Act as one of the attestation officials for any authorization request for certification for an Authority-To-Operate (ATO) from the CMS Authorization Official (AO).

Privacy

• Coordinate with the Data Guardian, ISO, Business Owner, PA, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for PII, PHI, and FTI in accordance with the Privacy Act, E-Government Act, the HIPAA Privacy and Security Rules, and all applicable guidance.

Assessment and Authorization

• Maintain current system information in CFACTS (such as POCs and artifacts) to support organizational requirements and processes (e.g., communication, contingency planning, training, and data calls).
• Coordinate with the Business Owner, ISO, and CISO to ensure that all requirements specified by the CMS ARS are implemented and enforced for applicable information and information systems.
• • Ensure anomalies identified under the CMS Continuous Diagnostics and Mitigation (CDM) program and ISCM activities are addressed and remediated in a manner that is commensurate with the risks posed to the system from the anomalies.
• Evaluate the impact of network and system changes using standard processes.

System Development Life Cycle

Initiation

• Review and confirm that contracts include appropriate information security and privacy language.
  • Coordinate with Enterprise Architecture.
  • Ensure the system appears in CFACTS.
  • Generate a draft PIA in coordination with the Business Owner.
  • Evaluate whether other privacy artifacts are required.
  • Complete System Security Categorization.
  • Identify system-specific, information security and privacy training needs.
  • Participate in governance and project reviews identified in the SDLC.

Concept

• Identify and discuss risk with the Program Manager and Business Owner.
• Identify any investment needs to ensure each FISMA system meets security and privacy requirements.

Planning

• Develop a System Security and Privacy Plan (SSPP).
• Ensure Security Control Assessment is scheduled.
• Identify training needs.
• Review or develop a corresponding security architecture diagram.
• Participate in governance and project reviews identified in the SDLC.

Requirements Analysis

• Conduct formal information security risk assessment (ISRA).
• Complete documentation activities, including the privacy documents.

Design

• Ensure that security architecture ingress/egress points are reviewed to meet CMS security requirements.
• Ensure data is transmitted, processed, and stored securely.
• Participate in governance and project reviews identified in the SDLC.

Development

• Verify software code is developed in accordance with the CMS Technical Reference Architecture (TRA) and SDLC information security and privacy guidelines.
• Participate in governance and project reviews identified in the SDLC.

Test

• Schedule internal tests such as penetration testing.
• Coordinate with the CCIC to ensure assets are identified within monitoring tools.
• Ensure use case security testing is incorporated into system functional testing.
• Ensure change control processes are followed in accordance with the system security and privacy plan (SSPP).
• Ensure auditing logs are appropriately capturing required information.
• Participate in governance and project reviews identified in the SDLC.

Implementation

• Ensure third-party testing begins and weaknesses are resolved quickly.
• Ensure each FISMA system is authorized for operation before the go-live date.
• Participate in governance and project reviews identified in the SDLC.

Operation and Maintenance

• Address weaknesses and POA&Ms.
• Review available reports.
• Routinely evaluate risk posture based on change requests.
• Conduct Security Impact Analysis (SIA) at the direction of the Business Owner.
• Participate in governance and project reviews identified in the SDLC.

Disposition

• Verify the proper disposition of hardware and software.
• Verify data are archived securely in accordance with the National Archives and Records Administration (NARA) requirements and in coordination with the Data Guardian.
• Initiate the request to close out the project file in CFACTS.
• Participate in governance and project reviews identified in the SDLC.

Secondary System Security and Privacy Officer (previously known as S-ISSO) and System Security and Privacy Officer Contractor Support (previously known as ISSOCS)

The CMS Secondary System Security and Privacy Officer (previously known as S-ISSO) may be either a federal government employee or a contractor identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.25, System Security and Privacy Officer (previously referred to as ISSO) Designated Representative / Security Steward and must assist the Primary System Security and Privacy Officer (previously known as P-ISSO). The System Security and Privacy Officer Contractor Support (previously known as ISSOCS) is a contractor only role that assists and supports the Primary System Security and Privacy Officer (previously known as P-ISSO) and Secondary Systems Security and Privacy Officer (previously known as S-ISSO) roles in fulfillment of their CMS cybersecurity duties.

Security or Privacy Control Assessor

The CMS Security or Privacy Control Assessor (also referred to as Certification Agent) role may be performed by a System Security and Privacy Officer (previously known as ISSO). The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for

Information Systems Security and Privacy Protection (IS2P) Section 7.23, Security or Privacy Control Assessor.

Contingency Planning Coordinator

The CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by a System Security and Privacy Officer (previously known as ISSO). The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30, Contingency Planning Coordinator.

The responsibilities of the CMS Contingency Planning Coordinator must also include, but are not limited to the following:

• Work as part of an integrated project team to ensure contingency plans and related operational procedures accommodate all business resumption priorities and the defined applicable Maximum Tolerable Downtimes (MTD)
• Ensure procedures exist that achieve continuity of operations of business objectives within appropriately targeted systems with any applicable Recovery Time Objective (RTO) and Recovery Point Objective (RPO) identified in the Business Impact Assessment
• Ensure that the contingency plan is activated if any computer security incident disrupts the system; if the disruption is not resolved within the system’s RTO, implement the system’s disaster recovery procedures.

Security Operations Center/Incident Response Team

The FISMA system SOC/IRT may consist of federal employees or contractors and must fulfill all the FISMA system-level responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.16, OpDiv CSIRT, and the applicable responsibilities under the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.17, HHS PIRT. The FISMA system SOC/IRT reports to the Agency Security Operations, which is responsible for CMS-wide incident management.

The Data Guardian, Business Owner, and ISO, in coordination with the CISO, have ownership of and responsibility for incident response and reporting for the FISMA system. The execution of this function begins at the data center/contractor site housing the FISMA system. Once an incident is declared, the CCIC coordinates with FISMA system SOC/IRT and Agency Security Operations personnel for all incident management activities.

The FISMA system SOC/IRT operates under the direction and authority of the System Security and Privacy Officer (previously known as ISSO) and the Business Owner/ISO. The FISMA system SOC/IRT monitors for, detects, and responds to information security and privacy incidents within the FISMA system environment. The FISMA system SOC/IRT also provides timely, accurate, and meaningful reporting to the FISMA system stakeholders.

FISMA systems may perform the SOC/IRT capability by using a separate CMS CISO-approved SOC/IRT service provider. Any FISMA system SOC/IRT that is unable to deploy the required capabilities may establish an agreement with the CCIC to provide SOC/IRT services.

The responsibilities of the FISMA system SOC/IRT must also include, but are not limited to, the following:

General

• For the FISMA system, perform:
  • Real-time network and system security monitoring and triage
  • Analysis, coordination, and response to information security and privacy incidents and breaches
  • Security sensor tuning and management and infrastructure operations and maintenance (O&M).
• Ensure flaw remediation (e.g., patching and installation of compensating controls), planning, ongoing scanning (e.g., ISCM), help desk, asset management, and ticketing are performed for the FISMA system in a manner that meets or exceeds CMS requirements.
• Ensure the SOC/IRT-specific tools are implemented and deployed according to the CCIC and vendor technical guidance.
• Ensure SOC/IRT-specific tools/equipment are isolated, as appropriate, from operational networks and systems.
• Serve as the FISMA system’s information security and privacy lead on behalf of CCIC and HHS CSIRC.

Incident Response

• Report FISMA system information security and privacy incidents and breaches to CCIC and HHS CSIRC as required by federal law, regulations, mandates, and directives, and as reflected in the CMS established procedures.
• Report cyber threat/intelligence/information to CCIC as required by federal law, regulations, mandates, and directives.

Privileged Users

This subsection describes specific information security and privacy responsibilities of users with privileged access to CMS information systems. For example, a privileged user11 is any user that has sufficient access rights to modify, including disabling, controls that are in place to protect the system. The responsibilities for all privileged users must include, but are not limited to, the following:

• Limit the use of privileged access to those administrative functions requiring elevated privileges

System/Network Administrator

The CMS System/Network Administrator may be a federal employee or a contractor and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.33, System Administrator. Per the HHS IS2P, the system administrator role includes, and are not limited to, other types of system administrators (e.g., database administrators, network administrators, web administrators, and application administrators).

Website Owner/Administrator

The CMS Website Owner/Administrator may be a federal employee or contractor and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.28, Website Owner/Administrator.

The responsibilities of the CMS Website Owner/Administrator must also include, but are not limited to, the following:

• Implement proper system backups and patch management processes.
• Assess the performance of security and privacy controls associated with the web service to ensure the residual risk is maintained within an acceptable range.
• Coordinate with the CIO, CISO, SOP, Data Guardian, and System Security and Privacy Officer (previously known as ISSO) to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and applications.
• Limit connections to publicly accessible federal websites and web services to approved secure protocols.
• Ensure federal websites and web services adhere to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS)12 practices.

System Developer and Maintainer

The CMS System Developer and Maintainer must be an agency official (federal government employee) and must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.31, System Developer and Maintainer. The responsibilities of the CMS System Developer and Maintainer must also include, but are not limited to, the following:

• Identify, tailor, document, and implement information security- and privacy-related functional requirements necessary to protect CMS information, information systems, missions, and business processes, including:
  • Ensure the requirements are effectively integrated into IT component products and information systems through purposeful security architecting, design, development, and configuration in accordance with the CMS SDLC and change management processes
  • Ensure the requirements are adequately planned and addressed in all aspects of system architecture, including reference models, segment and solution architectures, and information systems that support the missions and business processes
  • Ensure automated information security and privacy capabilities are integrated and deployed as required.
• Coordinate with the System Security and Privacy Officer (previously known as ISSO) to identify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems.
• Follow the CMS SDLC in developing and maintaining a CMS system, including:
  • Understand the relationships among planned and implemented information security and privacy safeguards and the features installed on the system
  • Ensure all development practices comply with the CMS TRA.
• Execute the RMF tasks listed in NIST SP 800-37 Revision 2.
• Ensure CMS systems or applications that currently disseminate data for any purpose are capable of extracting data by pre-approved categories.
• Share only the minimum PII from CMS systems and applications that is necessary and relevant for the purposes it was originally collected.

Enterprise Architect (Function)

The Enterprise Architect must be an agency official (federal government employee). The Enterprise Architect must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.32. Enterprise Architect. The CIO may designate specific responsibilities to the Enterprise Architect as necessary.

The responsibilities of the Enterprise Architect must also include, but are not limited to the following:

• Develop and disseminate strategies, policies, and standards to implement the Enterprise Architecture program.
• Manage the agency's Enterprise Architecture resources.
• Provide leadership in developing, maintaining, and implementing a sound and integrated Enterprise Architecture for the agency and its sub-organizations.
• Organize and chair the agency's Enterprise Architecture advisory group to provide cross-organization business and technical input to Enterprise Architecture-related matters, ensuring CMS programmatic and technical participation in Enterprise Architecture-related activities.
• Define, document, and align the agency's Enterprise Architecture with HHS Enterprise Architecture.
• Ensure implementation of the Enterprise Architecture alignment reviews, verification of Enterprise Architecture approvals, and granting of waivers within the agency's Capital Planning and Investment Control (CCIC) investment planning and reviews, acquisition procedures, and SDLC project phase reviews.
• Monitor program and project artifacts for alignment with Enterprise Architecture requirements, identifying and reporting non-conforming projects for resolution.
• Advise and inform all contractors and developers of Enterprise Architecture standards and compliance requirements.
• Ensure that CMS adopts data stewardship mechanisms necessary for Enterprise Architecture data of acceptable quality to be created, captured, entered, and maintained promptly in the HHS Enterprise Architecture Repository.
• Recommend technical standards to the agency Technical Review Board, ensuring submission to the HHS Chief Enterprise Architect of proposed modifications to HHS Enterprise Architecture and technology standards to meet CMS business requirements.
• Ensure that CMS Enterprise Architecture-related training requirements are identified, planned for, and implemented.
• Advise or ensure that Enterprise Architecture advice is available to all CMS IT project teams.
• Represent CMS on the HHS Enterprise Architecture Review Board (EARB), and all agency, departmental, and intergovernmental Enterprise Architecture-related advisory bodies or working groups.

Agency Security Operations

Agency Security Operations must fulfill all OpDiv responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.16, OpDiv Computer Security Incident Response Team (CSIRT), and applicable responsibilities under the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.17, HHS Privacy Incident Response Team (PIRT).

Security operations are a shared responsibility between CMS Agency Security Operations and the ISO’s SOC/IRT. For each FISMA system, System Developers and Maintainers are expected to establish, maintain, and operate a SOC/IRT to provide FISMA system situational awareness and incident response. For the CMS enterprise, Agency Security Operations maintains visibility and incident management across all FISMA systems, providing management, information sharing and coordination, unified response (including containment and mitigation approaches), and required reporting across the enterprise to CMS Management.

The responsibilities for Agency Security Operations, both within the CCIC and across all SOC/IRTs, must also include, but are not limited to, the following:

Awareness and Training

• Ensure all personnel with responsibilities for incident response complete annual RBT.
• Ensure non-federal technical personnel (SOC/IRT and CCIC) obtain and maintain appropriate commercial information assurance certification credentials that have been accredited by the American National Standards Institute (ANSI) or an equivalent authorized body under the ANSI/International Standards Organization (ISO)/ International Electrotechnical Commission (IEC) 17024 Standard.
  • Personnel who do not hold a commercial information assurance certification credential must obtain an appropriate credential within six months of the individual’s start date or the release date of this document, whichever is later.
• Encourage federal oversight personnel (SOC/IRT and CCIC) to obtain and maintain a commercial information assurance certification credential that has been accredited by ANSI or an equivalent authorized body under the ANSI/ISO/IEC 17024 Standard.

Director for the CMS Cybersecurity Integration Center

The CCIC operates under the direction and authority of the CMS CISO, who appoints the Director for the CCIC.

The responsibilities of the Director for the CCIC must include, but are not limited to, the following:

General

• Ensure the operational execution of the CCIC function enables the CMS CISO’s strategic vision.
• Oversee the operation of the CCIC.
• Enable CCIC capabilities (penetration testing, security engineering, etc.) to efficiently and effectively enhance the CMS enterprise security posture by performing their roles across the enterprise in coordination with CMS groups, partners, and contractors.
• Support the CISO and SOP when immediate disconnection or suspension of any interconnection is required.

Awareness and Training

• Define information security and privacy RBT requirements for CCIC and FISMA system SOC/IRT personnel.

CMS Cybersecurity Integration Center

The CCIC monitors, detects, and isolates information security and privacy incidents and breaches across the CMS enterprise IT environment. The CCIC provides continual situational awareness of the risks associated with CMS data and information systems throughout CMS. The CCIC also provides timely, accurate, and meaningful reporting across the technical, operational, and executive spectrum.

The responsibilities of the CCIC must include, but are not limited to, the following:

General

• Serve as the primary entity in CMS responsible for maintaining CMS-wide operational cyber security situational awareness, based on coordinated enterprise ISCM activities and the overall information security and privacy risk posture of CMS.
• Serve as the information security and privacy lead organization for coordinating within CMS and identified external organizations for Cyber Threat Intelligence (CTI) sharing, analysis, and response activities, including:
  • Identify enterprise threats and disseminate advisories and guidance
  • Identify and coordinate response with SOC/IRT to ongoing threats to CMS
  • Develop and share Indicators of Compromise (IOC)
  • Develop and disseminate unified containment and mitigation approaches
• Define minimum interoperable defensive technology requirements for CMS systems.

Incident Response

• Serve as CMS’s primary POC with HHS CSIRC.
• Report CMS information security and privacy incidents and breaches to HHS CSIRC.
• Perform malware analysis and advanced analytics in support of unified incident response.
• Coordinate with the Data Guardian when PII is involved.
• Coordinate with the CMS Counterintelligence and Insider Threat Program Office, as appropriate.

Assessment and Authorization

• Define enterprise-wide information security and privacy requirements for all phases of the SDLC.
• Define an enterprise-wide, continual assessment process that:
  • Validates incident response processes and procedures
  • Meets federal law, regulations, mandates, and directives for continual assessment
  • Defines security data monitored by all SOCs/IRTs and is made available to the CCIC
• Define reporting metrics that are compliant with federal law, regulations, mandates, and directives for:
  • Penetration testing
  • Information security continuous monitoring
  • Information security and privacy incident and breach response
  • Cyber threat intelligence
• Determine risk and impact on the CMS enterprise based on:
  • Real-time monitoring and triage
  • Analysis, coordination, and response to incidents
  • Collection, sharing, and analysis of CTI (i.e., knowing the adversary)

• Develop, in coordination with the CCIC Director, information security and privacy RBT requirements for CCIC and FISMA system SOC/IRT personnel.

Agency Continuity Point of Contact

The Agency Continuity Point of Contact must be an agency official (federal government employee) and is the individual the Administrator designates as the accountable official who will:

• Perform the duties and responsibilities of the Agency Continuity Point of Contact, as set out in HHS’s Continuity of Operations Program Policy.
• Be directly responsible to the Administrator for management oversight of the CMS continuity program.
• Serve as the single POC for coordination within CMS for continuity matters.

IT Advisory Organizations

CMS Executive Management established IT advisory and decision-making bodies. These organizations ensure proper project planning; proper use of CMS information; and provide technical guidance ensuring IT projects properly integrate within the CMS environment. These organizations promote CMS strategic objectives and enforce federal requirements, including information security and privacy.

The primary IT Advisory Organizations relevant to information system security and privacy policy are:

• The Strategic Planning Management Council (SPMC), co-chaired by the Chief Operating Officer (COO) and CIO, manages oversight of all CMS investment-related governance boards.
• The Governance Review Board (GRB) Chaired by the CIO, CFO, and Head of Contracting Activity. Members are the Budget Development Group Chairs. The Agencies IT Investment Review Boards and serves as the decision or approval authority for IT expenditure. Capital Planning and Investment Control.
• The Governance Review Team (GRT) - Support staff which gathers information to assist the GRB in making decisions.
• The Technical Review Board (TRB) Chaired by the CTO and supported by IT Governance serves as a key member of the Target Life Cycle Governance Program. They advise and guide IT Projects Teams that are moving through the Target Life Cycle to ensure it conforms to the CMS Technical Reference Architecture.
• The Data Governance Board (DGB) supports overall agency data governance. Led by OEDA CMS Chief Data Officer. works with the national data sets supplied by CMS to different programs.

Strategic Planning Management Council (SPMC)

The Strategic Planning Management Council (SPMC) provides leadership and support for executing CMS strategic objectives across all CMS investments. The SPMC provides a forum for ongoing collaboration among teams and overall management of the CMS Strategy.

Governance Review Board (GRB)

The CMS Governance Review Board (GRB) is established as part of the CMS IT Governance process to enforce the implementation of CMS enterprise standards and strategy. The GRB consists of CMS Senior Leadership which reviews the recommendations for project alternatives. The GRB does not make funding decisions, however, they review proposed options and potential solutions to ensure the best solution is implemented by the project team to address the business needs.

Governance Review Team (GRT)

The CMS Governance Review Team (GRT) is a project planning body that supports project teams in determining the steps needed to ensure projects are in alignment with CMS Security and Privacy Policy. The GRT will:

• Make recommendations to the GRB on proposed business cases and alternative analysis ensuring the project:
  • Fulfills a need,
  • Does not duplicate current processes or functions; and
  • Is in alignment with current IT Portfolio Goals
• Advise Project Teams on the IT Governance Process.
• Consist of Subject Matter Experts which support CMS stakeholders in the development of their projects and business cases.
• Review Business Cases and support the GRB by providing ongoing review of proposed and operational systems for adherence to CMS policies.
• Coordinate with other governance boards when necessary to ensure further reviews are implemented when necessary.

Technical Review Board

The Technical Review Board (TRB) is an advisory board established to ensure IT investments are consistent with CMS’s IT strategy. The board manages updates to the CMS TRA to promote the CMS IT strategy and assists projects by ensuring solutions are technically sound and are on track to deliver promised capabilities on time and on budget. The TRB:

• Provides technology leadership to deliver business value and anticipate change to meet the current and long-term needs of CMS programs.
• Implements and communicates CMS’s IT strategy to ensure projects solutions are cost- effective, sustainable, and support the agency’s business.
• Provides technical guidance to ensure CMS’s IT Investments are properly integrated into the CMS environment.
• Supports teams in building IT features.

Data Governance Board

The CMS Data Governance Board (DGB) provides executive leadership and stewardship of the agency’s data assets, including oversight for the development and implementation of the policies and processes which govern the collection or creation, management, use, and disclosure of CMS data.

The DGB ensures intra-agency transparency and data stewardship to promote efficient and appropriate use of, and investment into, agency data resources. Transparency and data stewardship include:

• Openness: Promoting and facilitating the open sharing of knowledge about CMS data, including an understanding of how and where agency data are collected or created, stored, managed, and made available for analysis.
• Communication: Promoting partnerships across the CMS enterprise to eliminate duplication of effort, stove-piping, and one-off solution designs.
• Accountability: Ensuring agency-wide compliance with approved data management principles and policies. Understanding the objectives of current and future strategic or programmatic initiatives and how they impact, or are impacted by, existing data management principles and policies as well as current privacy and security protocols.

Integrated Information Security and Privacy Policies

CMS Tailored Policies

The HHS Policy for Information Systems Security and Privacy Protection (IS2P) delineates information security and privacy policies, including both mandated security controls and a provision for CMS to develop its own controls over CMS information and information systems as long as the HHS baseline requirements are met. CMS tailored specific security controls to ensure they meet the mission and vision of the organization. This section lists the tailored controls which include the following:

• Controls explicitly mandated for CMS by an authoritative agent (e.g., HHS or other federal agency requirements).
• Controls modified to address the CMS implementation (e.g., CMS architecture, risk framework, and life cycle management).
• Controls that address specialized topics that extend beyond NIST 800-53, Revision 5 (e.g., the Federal Risk and Authorization Management Program [FedRAMP], and FISCAM).

Employee Monitoring / Insider Threat (CMS-EMP)

CMS-EMP-1 The use of warning banners is mandatory on all CMS information systems in accordance with federal and HHS policy and the ARS control requirements. A warning banner

states that by accessing a CMS information system, (e.g., logging onto a CMS computer or network), the employee consents to having no reasonable expectation of privacy regarding any communication or data transiting or stored on that system, and the employee understands that, at any time, CMS may monitor the use of CMS IT resources for lawful government purposes. (For the purposes of this policy requirement, the term “employee” includes all individuals who have been provided and currently have access to CMS IT resources and who are current employees, contractors, guest researchers, visiting scientists, and fellows. The term excludes individuals who are not or are no longer CMS employees, contractors, guest researchers, visiting scientists, or fellows.)

CMS-EMP-2 In accordance with HHS policy the CMS CIO must carry out monitoring in a fashion that protects employee interests and ensures the need for monitoring has been thoroughly vetted and documented.

Computer monitoring of an employee at CMS may be requested by HHS/ONS, HHS/OIG, CMS Counterintelligence and Insider Threat Program Office, or an outside law enforcement authority. 

(For the purposes of this policy, the term “computer monitoring” covers monitoring of CMS IT resources, including real-time or contemporaneous observation, prospective monitoring, (e.g., using monitoring software), and retrospective review and analyses (e.g., of email sent or received, of computer hard-drive contents) focusing on an individual employee. This section of policy does not apply to passive monitoring (computer incident response monitoring) of systems relating to national security or FISMA that perform general system and network monitoring or examinations of computers for malware. Additionally, computer monitoring excludes any review and analysis requested by or approved by the employee(s) being covered. This does not apply to retrospective searches for documents in response to valid information requests in the context of litigation, Congressional oversight, Freedom of Information Act (FOIA) requests, and investigations by the Government Accountability Office (GAO) and the Office of Special Counsel. Such retrospective searches may be conducted with the consent of the employee or the authorization of the CMS CIO.)

CMS-EMP-3 All requests from outside law enforcement agencies must be coordinated through the HHS/OIG, except for requests relating to national security or non-criminal insider threat matters. The latter must be coordinated via the Counterintelligence and Insider Threat Program of the Division of Strategic Information (DSI), which in turn coordinates with the HHS/ONS on all requests. Such external computer monitoring requests may be subject to different standards, partly because they are covered by the internal controls of the requesting agency or judicial process.

CMS-EMP-4 No CMS official may initiate computer monitoring without advance written authorization by the CMS Administrator or the CMS CIO. By HHS policy, this authority to authorize monitoring may not be delegated below the CMS CIO. Prior to submission of a monitoring request, the CMS CIO or HHS/ONS consults with the HHS Office of the General Counsel (OGC). The requesting organization documents the basis for approving any request for computer monitoring.

CMS-EMP-5 Computer monitoring may only be authorized for the following reasons:

1. Monitoring has been requested by the HHS/ONS, HHS/OIG, CMS Counterintelligence and Insider Threat Program Office, or an outside law enforcement authority in accordance with CMS Administrative Services Group, DSI and federally recognized jurisdiction.
2. Reasonable grounds exist to conclude that the individual to be monitored may be responsible for an unauthorized disclosure of legally protected information (e.g., confidential commercial information or Privacy Act protected information).
3. Reasonable grounds exist to believe that the individual to be monitored may have violated an applicable law, regulation, or written HHS or CMS policy.

Routine IT equipment examinations are permissible when malware searches are involved. Any unintended discoveries of problematic content and resulting follow-up actions are not subject to this policy except for follow-up actions that involve computer monitoring.

CMS-EMP-6 In circumstances in which HHS/OIG requests computer monitoring for purposes of an HHS/OIG investigation or where HHS/OIG requires assistance in the conduct of computer monitoring, HHS/OIG will provide such information or notification as is consistent with its responsibilities, duties, and obligations under the Inspector General Act of 1978, as amended.

CMS-EMP-6.1 In concert with the HHS/OGC, the CMS CIO must develop a memorandum of understanding (MOU) or similar written agreement with outside law enforcement agencies as a precondition for approving monitoring requests from these organizations. The MOU must include the following:

• Title and organizational component of the person(s) authorized to make monitoring requests on behalf of the law enforcement agency.
• Documentation of the source of the official request demonstrating approval by an official of the governmental entity that has the authority to request the initiation of such monitoring (e.g., a subpoena [administrative or grand jury], warrant, national security letter [NSL], or other acceptable documented request [e.g., a written law enforcement administrative request that meets applicable requirements of the Privacy Act and/or HIPAA requirements for certain disclosures to law enforcement agencies]).
• Any restrictions applicable to the handling and disclosure of confidential information that may be produced by monitoring.
• Other items consistent with this memorandum, including handling sensitive communications, as described in the following bullet (Documentation).
• Documentation – the written authorization for computer monitoring describes the reason for the monitoring. If the monitoring is initiated at the request of outside law enforcement authorities, the authorization documents that the request was approved, consistent with the applicable MOU with that organization by an official of the governmental entity that has the authority to request the initiation of such monitoring.

CMS-EMP-6.2 Except for monitoring initiated at the request of an outside law enforcement authority or the HHS/OIG, the party requesting the monitoring must document the factual basis justifying the request for monitoring and the proposed scope of the request. Requests for such monitoring must include an explanation of how monitoring will be conducted, how the information collected during monitoring will be controlled and protected, and a list of individuals who will have access to the resulting monitoring information.

CMS-EMP-6.3 A record of all requests for monitoring must be maintained by the CMS CIO along with any other summary results or documentation produced during the period of monitoring. The record must also reflect the scope of the monitoring by documenting search terms and techniques. All information collected from monitoring must be controlled and protected with distribution limited to the individuals identified in the request for monitoring and other individuals specifically designated by the CMS Administrator or CMS CIO as having a specific need to know such information.

CMS-EMP-7 The CMS Administrator or CMS CIO must ensure authorized computer monitoring is appropriately narrow in scope and time-limited and takes the least invasive approach to accomplish monitoring objectives. The CMS Administrator or CMS CIO, in reviewing requests for monitoring, must consider whether there are alternative information gathering methods that CMS can utilize to address the concern in lieu of monitoring. When the monitoring request originates from HHS/OIG or outside law enforcement, CMS will grant appropriate deference to a request made in accordance with this policy.

CMS-EMP-8 No monitoring authorized or conducted may target communications with law enforcement entities, the Office of Special Counsel, members of Congress or their staff, employee union officials, or private attorneys. Employee union officials of CMS will be treated, for non-targeted monitoring purposes, as all other employees of CMS when monitoring is necessary. If such protected communications are inadvertently collected or identified from more general searches, they may not be shared with a non-law enforcement party who requested the monitoring or anyone else without express written authorization from the HHS/OGC and other appropriate HHS official(s).

CMS-EMP-9 When a request for computer monitoring is made by a party other than an outside law enforcement authority or the HHS/ONS, HHS/OIG, CMS Counterintelligence and Insider Threat Program, CMS must consult with the OGC as to whether the monitoring is consistent with all applicable legal requirements, including the Whistleblower Protection Act and HIPAA, and consider whether there are any additional limits. In addition, except for monitoring initiated at the request of outside law enforcement or the HHS/OIG, parties that receive information derived from monitoring must consult with the OGC as to potential restrictions on the use of such information under applicable law.

CMS-EMP-10 The CMS CIO must review all employee monitoring every month and, in consultation with the party who requested the monitoring, assess whether it remains justified or is to be discontinued. The CMS CIO must consider whether or not the decision for ongoing monitoring must be reviewed by the OGC. A decision to continue monitoring must be explained and documented in writing by the CMS CIO, who must report at least monthly to the CMS Administrator regarding the status of any ongoing monitoring.

CMS-EMP-11 The CMS CIO and the OGC may make recommendations to the CMS Administrator for additional procedures, if necessary, to address specific circumstances not addressed in this policy. Insider threat policies and procedures that deviate from the elements of this policy, however, must not be implemented without the written concurrence of the HHS CIO in consultation with the OGC.

Risk Management Framework (CMS-RMF)

CMS-RMF-1 The CMS CISO must develop and maintain within the ARS Assessment, Authorization, and Monitoring family of controls minimum controls to ensure information systems: (i) are assessed at least every three years or whenever a significant change occurs (as defined in the CMS established procedures; NIST SP 800-37, revision 2, describes examples of significant changes to an information system that should be reviewed for possible re-authorization) to the information system to determine if security and privacy controls are effective in their application; (ii) have POA&Ms designed to correct deficiencies and reduce or eliminate vulnerabilities; (iii) are authorized for processing (including any associated information system connections) by the CMS CIO; and (iv) are monitored on an ongoing basis to ensure the continued effectiveness of the controls. In addition, the CMS CISO, where necessary to add clarity, provides methods in the form of Chapters, Procedures, and/or Standards within the CMS established procedures to facilitate implementation, assurance, and tracking effectiveness of those controls. Minimally, these processes and procedures must address the following:

CMS-RMF-1.1 Ensure all systems and networks receive a system categorization in accordance with the frameworks set forth in FIPS 199, NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, as amended, and please refer to the CMS established procedures.

CMS-RMF-1.2 Ensure CMS Business Owners/ISOs conduct risk assessments on systems and networks and document the result in accordance with NIST SP 800-30, Guide for Conducting Risk Assessments, as amended.

CMS-RMF-1.3 Ensure the CMS Business Owners/ISOs review and update risks, as necessary, no less than annually or when significant changes occur to the system/network.

CMS-RMF-1.4 Ensure CMS Business Owners/ISOs implement appropriate information security and privacy controls as documented in an information system security and privacy plan for each CMS system and network in accordance with NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems, and that CMS Business Owners/ISOs review and update plans as needed but no less than annually or when significant changes occur to the system/network.

CMS-RMF-1.5 Ensure CMS Business Owners/ISOs implement and document information security and privacy controls outlined in NIST SP 800-53, Revision 5.

CMS-RMF-1.6 Assess the controls using the procedures outlined in NIST SP 800-53A, as amended, Assessing Security and Privacy Controls in Information Systems and Organizations.

CMS-RMF-1.7 Develop, disseminate, and review/update: (i) formal, documented security assessment and authorization standards that address purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the security assessment and authorization policies and associated security assessment and authorization controls.

CMS-RMF-1.8 Determine (i) the required level of Security Control Assessor independence based on the security categorization of the information system and/or the ultimate risk to organizational operations and assets and to individuals; and (ii) if the level of Security Control Assessor independence is sufficient to provide confidence that the assessment results produced are sound and can be used to make a credible, risk-based decision.

CMS-RMF-1.9 Ensure all CMS systems and networks are formally assessed and authorized using the methodology outlined in NIST SP 800-37 Revision 2, and in accordance with the minimum content requirements for the creation of security authorization packages, as stated in the ARS and the CMS established procedures.

CMS-RMF-1.10 Ensure the Security Control Assessor(s) is identified and assigned prior to applying the RMF tasks to the information system. The AO for the information system (i) is the CMS CIO, (ii) authorizes the information system for processing before commencing operations, and (iii) uses the results of the ISCM process to the maximum extent possible as the basis for rendering a re-authorization decision.

CMS-RMF-1.11 Require SIA and PIA review when any significant change occurs to a CMS system, network, physical environment, etc., to assess the impact of the change on the information security and privacy of the information processed.

CMS-RMF-1.12 Ensure CMS Business Owners/ISOs request to re-authorize all systems at least every three years or when a significant change occurs to the system.

CMS-RMF-1.13 Develop a ISCM strategy and implement a ISCM program that includes:

• (i) a configuration management process for the information system and its constituent components;
• (ii) determination of the security impact of changes to the information system and environment of operation;
• (iii) ongoing information security and privacy control assessments in accordance with the organizational ISCM strategy; and
• (iv) reporting on the security state of the information system to appropriate organizational officials.

The organization assesses the information security and privacy controls in an information system, at a minimum, as part of (i) security authorization or re-authorization, (ii) meeting the FISMA requirement for annual assessments, (iii) ISCM, and (iv) testing/evaluation of the information system as part of the SDLC process. Those controls that are the most volatile (e.g., controls mostly affected by ongoing changes to the information system or its environment of operation) or deemed essential to protecting CMS operations and assets, individuals, other organizations, and the nation are assessed more frequently in accordance with the CMS CISO’s assessment of risk as defined in the CMS established procedures. All other controls are assessed at least once during the information system’s three-year authorization cycle.

CMS Systems Development Life Cycle (CMS-SDLC)

Security Architecture and Engineering (SA&E) activities help CMS Components align with enterprise information security and privacy capabilities, reporting processes, and requirements. SA&E ensures that the information security environment continues to meet business needs and address new and emerging threats by identifying risks and providing adequate information security and privacy protections through testing, implementation, and improvement of new and existing technologies and processes. To help guide a unified enterprise approach to implementing information security and privacy architecture, the risk management and compliance functional area publishes and updates information security and privacy technical guidance and provides input into the development of TRA security-related supplements.17 Security Assessment and Authorization (SA&A) processes help CMS Business Owners/ISOs comply with Capital Planning and Investment Control (CPIC) processes and CMS’s SDLC processes to incorporate the security requirements of the ARS and the CMS TRA to obtain system authorization, also referred to as Authority to Operate (ATO), prior to operation. The CMS CISO and SOP follow the procedures outlined in the RMF for SA&A in accordance with FISMA and the direction of the CMS CIO.

The SA&A processes help CMS stakeholders identify information security and privacy risks, assess the adequacy of information security and privacy controls, and ensure information security and privacy responsibilities are assigned prior to authorizing systems for operation. These processes incorporate ISCM and periodic manual assessment techniques to appropriately test the ongoing effectiveness of all controls.

By following CPIC, SDLC, and RMF, System Developers and Maintainers include information security and privacy requirements from project initiation throughout the life cycle and implement the appropriate controls to manage information security and privacy risk.

The ARS provides specific standards for completing the RMF process and include descriptions of the artifacts required to document information and information system controls. The SA&A processes result in identification of information security and privacy risks that must be managed by the POA&M processes.

CMS-SDLC-1 The CISO must integrate information security and privacy into the CMS life cycle processes. The SDLC provides the processes and practices of the CMS system development life cycle in accordance with the CMS Policy for Information Technology (IT) Investment Management & Governance.

CMS-SDLC-2 Program Executives must engage the System Security and Privacy Officer (previously known as ISSO), CRA, and privacy team early and throughout the SDLC.

CMS-SDLC-3 The SDLC processes and procedures must:

CMS-SDLC-3.1 Integrate information security and privacy requirements into all CMS SDLC activities (i.e., The four distinct phases of the CMS TLC include Initiate, Develop, Operate, and Retire).

CMS-SDLC-3.2 Ensure critical SDLC stage gate reviews are conducted to govern the information security and privacy posture of the system being developed. The TRB must evaluate the information security and privacy risk introduced by the system and provide guidance to improve system architecture and engineering. 

The CMS Technical Review Board (TRB) provides technical guidance to assist project teams with their IT investments and enable them to be integrated within CMS' IT environment. At the project level, the TRB has advisory support services to ensure project solutions are technically sound and on track to deliver the target capabilities. The TRB also promotes IT reuse, information sharing, and systems integration across the Agency.

CMS-SDLC-3.3 Assign information security and privacy roles for the information system.

CMS-SDLC-3.4 Ensure system information security and privacy controls are assessed.

CMS-SDLC-3.5 Ensure system authorization prior to entering the O&M phase of the SDLC.

Cloud Computing Requirements (CMS-CLD)

CMS developed CMS-CLD policies to provide guidance and direction on the acceptable uses of cloud service providers (CSP) and cloud computing services in compliance with the Federal Cloud Computing Strategy (Cloud Smart) when used as part of a CMS FISMA system. The CMS-CLD policies define directives concerning the procurement, deployment, and utilization of cloud computing services across the CMS enterprise.

In accordance with Cloud Smart, CMS permits cloud services within the CMS environment. CMS established the policies in this section to guide the use of cloud services and cloud computing installations.

CMS-CLD-1 All cloud service implementations used must have an approved Federal Risk and Authorization Management Program (FedRAMP) Authorization and CMS-issued ATO.

CMS-CLD-1.1 If a Software as a Service (SaaS) product does not have a current FedRAMP authorization, a Rapid Cloud Review (RCR) and a CMS-issued Provisional Authority to Operate (P-ATO) would be needed to assess FedRAMP readiness.

CMS-CLD-2 All FISMA systems and applications deployed on a CSP service must have a valid CMS-issued ATO.

CMS-CLD-3 All CSP systems must integrate with continuous monitoring and identity management systems.

CMS Email Encryption Requirements (CMS-EMAIL)

CMS must comply with information security and privacy encryption policies defined by federal laws, executive orders, directives, regulations, policies, standards, and guidance (e.g., HIPAA, Health Information Technology for Economic and Clinical Health [HITECH], Privacy Act, and IRS Publication 1075). The CMS Email Encryption Requirements control family provides the CMS standards for implementing information security and privacy controls.

CMS-EMAIL-1 CMS Sensitive Information must be protected and only sent to recipients with a “need to know.” Emails containing sensitive information must be protected using one of the following steps:

CMS-EMAIL-1.1 Ensure unencrypted emails containing sensitive information remain within the CHS email service environment (i.e., “jane.doe@cms.hhs.gov”) or trusted domain.

CMS-EMAIL-1.2 For recipients outside of the CMS email service environment or trusted domain:

CMS-EMAIL-1.2.1 Encrypt sensitive email and email attachments using the certificates contained on federally issued Personal Identity Verification (PIV) cards.

CMS-EMAIL-1.2.2 Place the CMS sensitive information in a password-protected, encrypted email attachment using software that meets FIPS 140-2 for encryption software, (e.g., SecureZip).

CMS-EMAIL-1.2.3 Sending passwords for an encrypted attachment via email is prohibited. Instant messaging clients that are integrated with Microsoft Outlook, such as Lync/Skype, must not be used to communicate passwords. Acceptable approaches for sharing passwords include phone conversation, text message, or a shared secret. The method chosen must protect the password from compromise.

Program Specific Requirements

Enterprise Level Control Packages

CMS has enterprise-level security and privacy controls for inheritance that are based on information security and privacy policies, programs or services that are provided by the offices of the CIO and CISO. These controls must be accounted for within the CMS governance, risk and compliance (GRC) tool in order for them to be leveraged as inherited controls among the FISMA systems. As part of the GRC tool, the systems are designated as FISMA systems, but they are not actual FISMA systems and are not subject to the requirements listed in section 8.1.2. Risk Management Framework (CMS-RMF).

High Value Assets

CMS must comply with the Office of Management and Budget (OMB) Memorandum M-19-03, Strengthening the Cybersecurity of Federal Agencies by enhancing the High Value Asset Program; the Department of Homeland Security (DHS) Binding Operational Directive (BOD) 18-02, Securing High Value Assets; and the HHS High Value Asset (HVA) Program Policy (August 2019).

The HHS HVA Program Policy defines HVAs as:

Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.

The HHS policy requires CMS to establish appropriate governance of HVA activities across its organization and integrate HVA remediation activities into its planning, programming, budgeting, and execution process. These efforts will align with federal law, regulations, standards, and guidelines, as well as CMS policies, processes, and procedures. To meet the HHS policy, CMS will conduct the following activities:

CMS-HVA-1 The CMS CIO develops a process for creating and maintaining an HVA inventory, consistent with any format and content specified by HHS. Upon request, the Program will complete or update the inventory. HHS may require the inventory to note any or all threats, vulnerabilities, and impacts, and the likelihood of each of these occurring, associated with each system. CMS will share its HVA inventory with HHS upon request, following HHS instructions.

CMS-HVA-2 When creating or updating HVA-related contracts and acquisition requirements, CMS Contracting Officers’ Representatives (COR) must incorporate appropriate language from the HHS Security and Privacy Language for Information and Information Technology Procurements.

CMS-HVA-3 HVA-related artifacts must be handled as directed by OMB and DHS. These documents include instructions for securing and encrypting all correspondence involving HVA- related information.

CMS-HVA-4 HVAs must have a valid Authority to Operate (ATO). An ATO must reflect that appropriate safeguards have been implemented to protect the HVA, many of which will be specific to HVAs.

CMS-HVA-5 Security assessments must be conducted as a minimum requirement by the CISA- Led Assessment Team for Tier 1 HVAs, Third Party/Independent Assessor for Tier 2 HVAs, and Self-Assessment for Tier 3 HVAs at the frequency and rigor stipulated by CISA.

CMS-HVA-6 The CMS CIO, Senior Official for Privacy (SOP) or designated official, must develop a Standard Operating Procedure (SOP) for reviewing CMS’s HVAs to identify those HVAs that create, collect, use, process, store, maintain, disseminate, disclose, or dispose of PII.

Federal Taxpayer Information

Systems that collect, maintain, use, or disclose Federal Tax Information (FTI) must follow IRS requirements for protecting FTI. Business Owners of CMS systems, with direction provided by the OIT, must ensure that all applicable information security and privacy controls, whether imposed by an organization or office internal or external to CMS, are incorporated into CMS systems.

The IRS defines Federal Tax Information as federal tax returns and return information (and information derived from it) that is in the agency’s possession or control which is covered by the confidentiality protections of the Internal Revenue Code (IRC) and subject to the IRC 6103(p)(4) safeguarding requirements including IRS oversight. CMS often receives, accesses, and uses FTI in conducting its business processes.

CMS-FTI-1 Business Owners that collect, maintain, use, or disclose FTI must:

CMS-FTI-1.1 Comply with IRS Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies.

CMS-FTI-1.2 Document and certify the incorporated controls in their respective system security and privacy plan and identify residual risks in the corresponding risk assessment for their systems.

CMS-FTI-1.3 Disclose FTI to its agents solely for purposes for which there is an appropriate legal authority, and for which IRS has granted an exception permitting its disclosure.

CMS-FTI-1.4 Notify the IRS Office of Safeguards prior to re-disclosing FTI to contractors. Notify and obtain written approval from the IRS Office of Safeguards prior to re-disclosing FTI to sub-contractors.

CMS-FTI-1.5 Notify the IRS Office of Safeguards when there has been a breach of FTI. CMS-FTI-1.6 Execute a contract or other agreement with any recipient of the FTI. The contract must require the recipient to abide by IRS Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies, including its requirements for providing privacy and security controls for FTI.

CMS-FTI-2 Users with access to FTI must adhere to the following when working from Alternative Work Sites

CMS-FTI-2.1 Telework Locations - FTI remains subject to the same safeguard requirements and the highest level of attainable security. All the requirements of IRS Publication 1075, Section 4.5, Physical Security of Computers, Electronic, and Removable Media, apply to telework locations.

CMS-FTI-2.2 Equipment – CMS must retain ownership and control, for all hardware, software, and end-point equipment connecting to public communication networks, where these are resident at all alternate work sites. Alternatively, the use of virtual desktop infrastructure with non-CMS-owned devices (including personally-owned devices) is acceptable, where all requirements in IRS Publication 1075, Section 9.4.13 Virtual Desktop Infrastructure are met.

CMS-FTI-2.3 Data Storage - FTI may be stored on hard disks only if CMS-approved security access control devices (hardware/software) have been installed, are receiving regularly scheduled maintenance including upgrades, and are being used. Access controls must include password security, an audit trail, encryption, virus detection, and data overwriting capabilities.

CMS-FTI-2.4 Inspection – Alternate work sites may be subject to periodic inspections by CMS personnel to ensure that safeguards are adequate.

Security and Privacy Control Families

The CMS ARS is central to the security and privacy framework. Through this document, CMS identifies the essential set of security and privacy controls that must be implemented for CMS Information Systems. CMS established these safeguards based on the agency’s interpretation of applicability of HHS and CMS internal policies and guidance, mandates and legislative guidance specific to the CMS environment. Each control family has a specific set of “dash one” controls that requires that policies be in place while the remaining controls provide details for implementing the policy. The “dash one” controls are included in this Policy while the required implementation of the details for each security and privacy controls are outlined in the ARS. This section provides an overview of the policy requirements associated with each “dash one” control family and includes additional details required for these “dash one” controls.

Access Control (AC)

AC-1 The Program must develop and document an access control policy that addresses purpose, scope, responsibility, management commitment, coordination among organizational entities, and compliance. The Access Control family of controls ensures access to information systems is limited to authorized users, processes acting on behalf of authorized users, and devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise. The Program must:

AC-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Access Control Policies and Procedures

AC-1.2 Develop an Access Control Policy which is consistent with the ARS and other federal requirements.

AC-1.3 Review and update policies, procedures, and standards for the Access Control family of controls and following defined events in the ARS, or as defined within the SSPP.

AC-1.4 Disseminate policies, procedures, and standards for the Access Control family of controls to all personnel who perform roles defined within this Policy.

AC-1.5 Maintain all policies, procedures, and standards associated with the Access Control family of controls to reflect applicable federal laws, executive orders, directives, regulations, policies, standards, and guidance.

AC-1.6 Define access control policies and procedures to provide the foundation required to ensure privacy protections are implemented for the identified uses of PII and PHI.

Awareness and Training (AT)

AT-1 The Program must develop and maintain minimum controls to ensure managers and users of information systems are made aware of the information security and privacy risks associated with their activities and of the applicable federal and agency requirements related to the information security and privacy of CMS systems. Through the Program, the CMS CISO must:

AT-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Awareness and Training family of controls in the ARS to:

AT-1.1.1 Develop topic-based training to explain privacy processes carried out within CMS and update topic-based training courses when significant changes occur to privacy processes.

AT-1.1.2 Develop and implement an information security and privacy education, awareness, and training program for all employees and individuals working on behalf of CMS involved in managing, using, and/or operating information systems.

AT-1.1.2.1 Ensure information security awareness and training is provided to all employees and contractors, and that all employees and contractors review and acknowledge an approved RoB within sixty (60) days from entry on duty (EOD) date, or commencement of work on a contract or subcontract; and ensure and acknowledge the RoB annually thereafter.

AT-1.1.2.2 Ensure privacy awareness and training is provided within sixty (60) days from EOD date, or commencement of work on a contract or subcontract., and annually thereafter, to all employees and contractors to explain the importance and responsibility in safeguarding PII and PHI and ensuring privacy, as established in federal legislation, regulations, and OMB guidance.

AT-1.1.2.3 Ensure system information security and privacy training records are documented in support of annual FISMA reporting.

AT-2 The Program must develop and maintain minimum controls to ensure those with “significant information security and privacy responsibilities” receive adequate role-based training (RBT) to carry out those responsibilities. Through the Program, the CMS CISO must:

AT-2.1 Ensure initial and periodic information security and privacy RBT is provided for all individuals in roles that possess significant information security and privacy responsibilities, including those that are CMS federal employees, contractors, and subcontractors. CMS RBT must meet or exceed HHS RBT requirements, as follows:

AT-2.1.1 CMS must identify all personnel (employees and contractors) and their associated work roles with significant information security and privacy responsibilities, in accordance with the HHS Cybersecurity Coding Guide and the National Initiative for Cybersecurity Education (NICE) Framework. The Program will identify appropriate minimum RBT requirements for each identified role with significant information security and privacy responsibilities.

AT-2.1.2 All CMS employees, including managers, Senior Executive Service (SES) personnel, and contractors who have significant information security and privacy responsibilities, must complete minimum RBT requirements within sixty (60) days from EOD date, or commencement of work on a contract or subcontract. Thereafter, all personnel with significant information security and privacy responsibilities must complete RBT at least annually.

AT-2.1.3 Individuals who change roles within CMS such that they assume new significant information security and privacy responsibilities, or who otherwise assume such responsibilities, must complete RBT within 60 days of assuming those new responsibilities. Thereafter, they must complete RBT at least annually.

AT-2.1.4 All CMS employees and contractors with significant information security and privacy responsibilities who have not completed the required training within the mandated timeframes will have their user accounts disabled until they have met their RBT requirement.

AT-2.1.5 All companies/vendors contracting with CMS are responsible for ensuring that their personnel who have significant information security and privacy responsibilities have training commensurate with their role. Training records must be submitted to CMS upon commencement of work and annually thereafter (or upon request whichever comes first).

AT-2.1.6 The CMS CISO, in coordination with the CMS’s Training Coordinator(s) and Contracting Officers/Representatives (CO/COR), must track and maintain RBT records for all personnel with significant information security and privacy responsibilities. All training records must be retained consistently with an appropriately selected records retention schedule.

AT-2.2 Develop appropriate security and privacy RBT for personnel with significant information security and privacy responsibilities in accordance with all relevant federal laws, regulations, and guidelines. The Program may provide such training in the form of CMS- or HHS-approved courses or professional development training, or in other appropriate formats. Personnel may also request approval for external training, such as certificate programs or college courses, to satisfy their RBT requirements.

AT-2.3 Require personnel wishing to receive credit for any form of RBT taken from an organization external to CMS, in satisfaction of any CMS or HHS training requirement to first seek review and approval from their supervisor (or for contractors, from their employer). The Program may further require personnel to supply information concerning completion of such external programs (such as grade reports or certificates of completion) before providing personnel with credit or acknowledgment for having satisfied the relevant RBT requirement.

AT-2.4 In addition to periodically identifying all roles of personnel that have significant information security and privacy responsibilities, CMS will also periodically identify all specific individuals who serve in roles with significant information security and privacy responsibilities. CMS managers are responsible for cooperating with the Program to identify individuals with significant information security and privacy responsibilities, and for ensuring that the personnel they manage are appropriately categorized in their roles. CMS managers will be required to complete this identification process as a CMS personnel needs assessment.

AT-2.5 Personnel who assume multiple roles must complete at least one training that addresses the unique responsibilities associated with at least one role. CMS managers must also ensure the personnel they manage complete the appropriate minimum RBT requirements in the required time frames.

AT-2.6 The Program may request verification of completion of RBT of all personnel from CMS managers. The Program may require mangers to supply adequate information, for each individual completing RBT, to verify the individual’s identity, the content of the RBT, and proof of completion of RBT.

AT-3 Develop an Awareness and Training Policy which is consistent with the ARS and other federal requirements.

AT-4 Review and update policies, procedures, and standards for the Awareness and Training Control family of controls and following defined events in the ARS or as defined within the SSPP.

Audit and Accountability (AU)

AU-1 The Program must develop and maintain (within the Audit and Accountability family of controls) minimum controls to ensure information system audit records are created, protected, and retained to the extent needed to: (i) enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure the actions of individual information system users can be uniquely traced to those users so that they can be held accountable for their actions. The Program must:

AU-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Audit and Accountability family of controls in the ARS to:

AU-1.1.1 Identify which events the organization audits, based on a risk assessment and mission/business needs.

AU-1.1.2 Identify and ensure a subset of auditable events applicable to the information system is chosen, based on threat information and risk assessment.

AU-1.1.3 Identify and ensure the rationale is provided for why the list of auditable events is deemed adequate to support incident investigations.

AU-1.2 Develop an Audit and Accountability Control Policy which is consistent with the ARS and other federal requirements.

AU-1.3 Ensure audit record content for all CMS system components, at a minimum, includes:

• Date and time of the event
• Component of the information system (e.g., software component, hardware component) where the event occurred
• Type of event
• User/subject identity
• Outcome (success or failure) of the event
• Execution of privileged functions.

AU-1.4 Ensure audited events are significant and relevant to the information security and privacy needs associated with the information system.

AU-1.4.1 Auditing must be compliant with the Federal Rules of Evidence as published by US Courts.

AU-1.5 Define CMS processes, procedures, and standards for the maintenance and review of audit logs for indications of inappropriate or unusual activity to ensure:

AU-1.5.1 Findings are reported to the designated CMS officials, including system officials with a need to know (e.g., Business Owner, Security and Privacy Officer). AU-1.5.2 The level of audit review, analysis, and reporting is adjusted when there is a change in risk.

AU-1.5.3 A uniform time and time protocol is implemented across CMS, based on CMS approved sources.

AU-1.6 Ensure audit and accountability policies, processes, procedures, and standards directly support privacy audit and accountability requirements.

AU-1.7 Coordinate information security- and privacy-related audit functions with other entities that require audit information to enhance mutual support and guide the selection of auditable events.

AU-1.8 Review and update policies, procedures, and standards for the Audit and Accountability Control family of controls and following defined events in the ARS or as defined within the SSPP.

Assessment, Authorization, and Monitoring (CA)

CA-1 The Program must develop and document a security assessment and authorization control policy governing the assessment and authorization of FISMA systems within the CMS enterprise environment or any systems storing, processing, or transmitting CMS information on behalf of CMS. The Program must:

CA-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Security Assessment and Authorization family of security controls in the ARS to:

CA-1.1.1 Perform security assessments on information systems and the environments in which those systems operate as part of (i) initial and ongoing security authorizations, (ii) FISMA annual assessments, (iii) continuous monitoring, and (iv) system development life cycle activities.

CA-1.1.2 Authorize connections from the information system to other information systems through the use of Interconnection Security Agreements.

CA-1.1.3 Develop and submit a POA&M for the information system as a result of any security assessment findings.

CA-1.1.4 Develop an ISCM strategy and implement a program compliant with HHS ISCM Strategy.

CA-1.2 Develop a Security Assessment and Authorization Policy which is consistent with the ARS and other federal requirements.

CA-1.3 Review and update policies, procedures, and standards for the Security Assessment and Authorization Control family of controls and following defined events in the ARS or as defined within the SSPP.

Configuration Management (CM)

CM-1 The CMS Configuration Management Executive must coordinate with the CMS CISO and the Program to document the configuration management processes and procedures to define configuration items at the system and component level (e.g., hardware, software, workstation); monitor configurations; and track and approve changes prior to implementation, including but not limited to flaw remediation, security patches, and emergency changes (e.g., unscheduled changes such as mitigating newly discovered security vulnerabilities, system crashes, replacement of critical hardware components). Baseline configurations and inventories of information systems (including hardware, software, firmware, and documentation) must be established and maintained throughout the respective system life cycles, and security configuration settings for information products employed in information systems must be established and enforced. In coordination with the CMS Configuration Management Executive, the Program must:

CM-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Configuration Management family of controls in the ARS to:

CM-1.1.1 Ensure configuration management procedures are consistent with applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards.

CM-1.1.2 Ensure scheduled changes to networks or systems are authorized prior to implementation and are not permitted outside of the configuration management process.

CM-1.1.3 Monitor system configurations and changes to ensure configuration management processes and procedures are followed.

CM-1.1.4 Evaluate the configuration management process periodically, as specified in the ARS, as part of the required FISMA reporting process to verify adequacy and effectiveness.

Through the Program the CMS CISO, in coordination with the CMS Configuration Management Executive, defines and develops policies to ensure CMS Business Owner/ISOs:

CM-1.1.5 Implement and enforce configuration management controls for all CMS systems and networks.

CM-1.1.6 Develop, document, and maintain a current baseline configuration of each system and the system’s constituent components.

CM-1.1.7 Develop, document, and maintain an inventory of the components, both hardware and software, that includes relevant ownership information.

CM-1.1.8 Test, validate, and document proposed changes prior to implementation to assess the impact to the information security and privacy of data.

CM-1.1.9 Ensure systems categorized as “Moderate” or “High” under FIPS 199:

• Retain older versions of baseline configurations as deemed necessary to support rollback
• Maintain a baseline configuration for development and test environments to ensure development and test environments are managed separately from the operational environment

Through the program, the CMS CISO must ensure:

CM-1.1.10 Current (up-to-date) anti-virus (AV)/anti-malware and host-based intrusion detection system (HIDS) applications are included, as appropriate, on systems connected to the CMS network.

CM-1.1.11 AV software is configured to automatically perform periodic virus scanning. CM-1.1.12 HIDS software is configured to automatically scan all inbound and outbound network traffic.

The CMS Configuration Management Executive must ensure:

CM-1.1.13 All systems and system components adhere to HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.

CM-1.1.14 Appropriate CCBs are created and managed for the review and approval of changes.

CM-1.1.15 Configuration management includes a representative from the system as a member of the CCB. Participation on the CCB is at the Security Control Assessor’s discretion. If the Security and Privacy Officer or Security Control Assessor acts as a voting member of the CCB, they must be a federal employee.

CM-1.1.16 Personnel with configuration management responsibilities are trained on CMS configuration management processes.

CM-1.1.17 Change documentation is maintained for no less than 12 months after a change is made.

CM-1.2 Develop a Configuration Management Policy which is consistent with the ARS and other federal requirements.

CM-1.3 For systems categorized as “High” under FIPS 199, ensure detection of unauthorized information security and privacy relevant configuration changes is incorporated into the incident response capability to ensure events are tracked, monitored, corrected, and available for historical purposes.

CM-1.4 Review and update policies, procedures, and standards for the Configuration Management Control family of controls and following defined events in the ARS or as defined within the SSPP.

Contingency Planning (CP)

CP-1 The Program must develop and maintain the Contingency Planning family of controls to ensure contingency plans for emergency response, backup operations, and disaster recovery for organizational information systems are established, maintained, and effectively implemented. IT Contingency Plans ensure the availability of critical information resources and continuity of operations in emergency situations. The Program must:

CP-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Contingency Planning family of controls in the ARS to:

CP-1.1.1 Work with Business Owners/ISOs to develop and document an IT contingency plan for all information systems in accordance with NIST SP 800-34 rev 1, Contingency Planning Guide for Information Technology Systems, and all other relevant CP documentations defined in the ARS.

IT contingency plans must support:

CP-1.1.1.1 Applicable CMS continuity of operations plans (COOP), particularly for information systems supporting the continuity of CMS’s essential business functions.

CP-1.1.1.2 Recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure.

CP-1.1.1.3 Implementation of privacy-applicable requirements to reduce the risk of avoidable information security and privacy incidents and breaches while executing contingency measures.

IT contingency plans, as part of the required FISMA reporting process, must be:

CP-1.1.1.4 Reviewed and updated periodically, as defined in the ARS.

CP-1.1.1.5 Tested periodically, as defined in the ARS.

CP-1.1.2 Ensure systems categorized as “High” or “Moderate” under FIPS 199:

• Implement a transaction recovery system for transaction-based systems
• Perform coordinated contingency testing and/or exercises with organizational elements responsible for related plans.

CP-1.1.3 Ensure systems categorized as “High” under FIPS 199 develop an IT contingency plan in coordination with organizational elements responsible for related plans (e.g., incident response).

CP-1.1.3.1 Business Owners/ISOs must develop and document a comprehensive system backup strategy for each system.

CP-1.1.3.1.1 The system backup strategy must document processes to:

• Support the information system recovery
• Store backup copies of the operating system and other critical information system software, as well as copies of the information system inventory, ina physically separate facility or in a fire-rated container not co-located with the operational system
• Meet business continuity needs, including the identified RTO and RPO.

CP-1.1.3.1.2 Applicable alternate processing sites must be established that are compliant with FIPS 199 system categorization requirements.

CP-1.2 Develop a Contingency Planning Policy which is consistent with the ARS and other federal requirements.

CP-1.3 For systems categorized as “High” (or as “Moderate” and supporting essential CMS mission or business functions) under FIPS 199, ensure the CMS Business Owner/ISO establishes and maintains appropriate alternate processing and storage site agreements that require:

CP-1.3.1 Alternate processing sites:

• Be separated from the primary storage site(s) and primary processing site(s)
• Identify potential accessibility problems to the alternate processing site(s) and outline explicit mitigation actions
• Ensure information security measures equivalent to those of the primary processing site(s) are provided
• Be configurable for use as an operational site. CP-1.3.2 Alternate storage sites:
• Be separated from the primary storage site(s)
• Identify potential accessibility problems to the alternate storage site(s) and outline explicit mitigation actions
• Ensure information security measures equivalent to those of the primary storage site(s) are provided.

CP-1.4 Review and update policies, procedures, and standards for the Contingency Planning Control family of controls and following defined events in the ARS or as defined within the SSPP.

Identification and Authentication (IA)

IA-1 The Program must develop and maintain the Identification and Authentication family of controls to ensure information system users, processes acting on behalf of users, and devices are identified, and the identities authenticated (or verified) as a prerequisite to allowing access to information systems. Through the Program, the CISO must:

IA-1.1 Designate CMS Enterprise level defined officials manage the development, documentation, and dissemination of the System and Information Integrity family of controls in the ARS to:

IA-1.1.1 Establish policy and procedures for the effective implementation of selected security controls and control enhancements in the IA control family.

IA-1.1.2 Ensure policy and procedures reflect applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards.

IA-1.1.3 Ensure the information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users) and the organizations meet all the requirements specified by HHS policy and applicable implementation standard(s).

IA-1.2 Develop an Identification and Authentication Policy which is consistent with the ARS and other federal requirements.

IA-1.3 Ensure all users, including federal employees, contractors, and entities with network access to systems, use multi-factor authentication. External facing applications must offer consumers multi-factor authentication as an option.

IA-1.4 Review and update policies, procedures, and standards for the Identity and Authentication Control family of controls and following defined events in the ARS or as defined within the SSPP.

Incident Response (IR)

IR-1 The Program must develop and maintain the Incident Response family of controls to establish an operational incident handling capability for information systems that includes preparation, detection, analysis, containment, recovery, and user response activities. Incidents must be tracked, documented, and reported. The Program must:

IR-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Incident Response family of controls in the ARS to:

IR-1.1.1 Document, maintain, and communicate policies and procedures in accordance with the HHS Policy for Information Technology (IT) Security and Privacy Incident Reporting and Response and the HHS Policy and Plan for Preparing for and Responding to a Breach of PII, including roles and responsibilities for information security and PII incidents and violation handling.

IR-1.1.2 Ensure CMS employees and contractors situational awareness through:

IR-1.1.2.1 Receipt of information system security and privacy alerts, advisories, and directives from designated external organizations on an ongoing basis.

IR-1.1.2.2 Generation of internal information security and privacy alerts, advisories, and directives as deemed necessary.

IR-1.1.2.3 Dissemination of information security and privacy alerts, advisories, and directives to personnel (see the ARS for a complementary, CMS-defined process).

IR-1.1.3 Ensure CMS employees and contractors awareness of privacy-related incidents through:

IR-1.1.3.1 Development and implementation of privacy breach notification and response policies, processes, and standards.

IR-1.1.3.2 Appropriate notification of the SOP for all incidents involving PII or PHI. IR-1.1.4 Ensure CMS employees and contractors maintain incident response processes and procedures by:

IR-1.1.4.1 Reviewing and updating Incident Response Plans periodically as defined in the ARS.

IR-1.1.4.2 Testing Incident Response Plans periodically as defined in the ARS.

IR-1.1.4.3 Incorporating lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises.

IR-1.1.5 Ensure CMS employees and contractors maintain familiarity with incident response processes and procedures through periodic training, as defined in the ARS.

IR-1.2 The CMS CISO, in coordination with the CMS Director of CCIC and Business Owners/ISOs, must establish and maintain an information security and privacy incident and breach response capability that includes preparation, identification, containment, eradication, recovery, and follow-up capabilities to ensure effective recovery from information security and privacy incidents and breaches.

IR-1.2.1 For systems categorized as “Moderate” or “High” under FIPS 199, incident handling activities must be coordinated with contingency planning activities.

IR-1.3 Develop an Incident Response Policy which is consistent with the ARS and other federal requirements.

IR-1.4 Review and update policies, procedures, and standards for the Incident Response Control family of controls and following defined events in ARS or as defined within the SSPP.

Maintenance (MA)

MA-1 The Program must develop and maintain the System Maintenance family of controls to ensure (i) periodic and timely maintenance on organizational information systems is performed and (ii) effective controls are established for the tools, techniques, mechanisms, and personnel used to conduct information system maintenance. The Program must:

MA-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Maintenance family of controls in the ARS to:

MA-1.1.1 Ensure privacy considerations are included in system maintenance policy and procedures, especially when the system contains information subject to the Privacy Act and/or HIPAA.

MA-1.1.2 Ensure routine preventative and regular maintenance (including repairs) on the components of all CMS information systems, supporting utilities, and ancillary equipment (e.g., within the data center, used for testing) are scheduled, performed, documented, and reviewed.

MA-1.1.2.1 Maintenance processes and procedures must be compliant with CMS processes and procedures.

MA-1.1.2.2 Maintenance processes and procedures may reference manufacturer or vendor specifications.

MA-1.1.3 Ensure information system maintenance tools are approved, controlled, maintained, and monitored as required.

MA-1.1.4 Ensure only authorized personnel are allowed to perform maintenance on the information system through established processes and procedures.

MA-1.1.4.1 Personnel authorized to perform maintenance must be compliant with requirements defined under the Awareness and Training and Personnel Security sections of this document.

MA-1.1.5 For non-local (e.g., remote) maintenance and diagnostic services ensure:

MA-1.1.5.1 Services are authorized, monitored, and controlled.

MA-1.1.5.2 Tools are consistent with organizational policy and documented in the security plan for the information system.

MA-1.1.5.3 Strong identification and authentication techniques are employed in the establishment of sessions.

MA-1.1.5.4 Activity records are maintained.

MA-1.1.5.5 All sessions and network connections are terminated when non-local maintenance is completed.

MA-1.1.6 Ensure appropriate protection of information systems and/or components being removed:

MA-1.1.6.1 The CMS Business Owner/ISO or designated federal employee must approve the removal of information systems and/or system components for offsite maintenance/repairs.

MA-1.1.6.2 The equipment/media must be sanitized in a manner compliant with NIST sanitization standards prior to removal from organizational facilities for offsite maintenance or repairs.

MA-1.1.7 For systems categorized as “Moderate” or “High” under FIPS 199, maintenance records must include:

• Date and time of maintenance
• Name of the individual performing the maintenance
• Name of escort, if necessary
• Description of the maintenance performed
• List of equipment (including components and parts), including the removal and/or replacement of applicable identification numbers

CMS Business Owners/ISOs must:

MA-1.1.7.1 Inspect all maintenance tools carried into a facility by maintenance personnel for improper modifications.

MA-1.1.7.2 Check all media containing diagnostic and test applications and programs for malicious code before the media is used in the information system.

MA-1.1.7.3 Ensure non-local maintenance and diagnostic sessions, including review of the maintenance records of the sessions, are audited by the Security and Privacy Officer.

MA-1.1.7.4 Ensure installation and use of non-local maintenance and diagnostic connections are documented in the security plan for the information system.

MA-1.1.8 For systems categorized as “High” under FIPS 199, CMS Business Owners/ISOs must:

MA-1.1.8.1 Employ automated mechanisms to schedule, conduct, and document any required maintenance and repairs.

MA-1.1.8.2 Produce and maintain up-to-date, accurate, complete, and available records of all maintenance and repair actions that are needed, in process, and completed.

MA-1.1.8.3 Prevent the unauthorized removal of maintenance equipment/media by performing one of the following:

• Verifying there is no CMS sensitive information contained on the equipment/media
• Sanitizing or destroying the equipment/media in a manner compliant with NIST or DoD guidance
• Retaining the equipment/media within the facility
• Documenting the removal of the equipment/media from the facility with an exemption signed by the Business Owner/ISO or designated federal employee

MA-1.2 Develop a Maintenance Policy which is consistent with the ARS and other federal requirements.

MA-1.3 Review and update policies, procedures, and standards for the Maintenance Control family of controls and following defined events in the ARS or as defined within the SSPP.

Media Protection (MP)

MP-1 The Program must develop and maintain the Media Protection family of controls to ensure information system media containing sensitive information, both digital and non-digital, is protected by (i) limiting access to authorized users and (ii) sanitizing or destroying information system media before disposal or release for reuse. The program must:

MP-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Media Protection family of controls in the ARS to:

MP-1.1.1 Inform all employees and contractors with potential access to sensitive information, such as PII or PHI, about all policies and procedures to protect any sensitive information residing on the various media types used by CMS.

MP-1.1.2 Ensure procedures exist for protecting information system media during transport, specifically through the use of cryptography and restricting the transport of such media to authorized personnel commensurate with the sensitivity level of the data.

MP-1.1.3 Develop and maintain processes, procedures, and standards to ensure information system media, both digital and non-digital, are properly sanitized and/or disposed of.

MP-1.1.3.1 Ensure sanitization and disposal techniques (i.e., clear, purge, destroy) for digital and non-digital media are in compliance with NIST SP 800-88 Revision 1, Guidelines for Media Sanitization, including the media sanitization decision matrix, prior to disposal, release, and transfer of custody for re-use.

MP-1.1.4 Ensure all confidential or classified information is sanitized and disposed of in accordance with policy, procedures, and standards established by the National Security Agency (NSA) and DoD.

MP-1.2 Develop a Media Protection Policy which is consistent with the ARS and other federal requirements.

MP-1.3 Review and update policies, procedures, and standards for the Media Protection Control family of controls and following defined events in the ARS or as defined within the SSPP.

Physical and Environmental Protection (PE)

Physical controls are important for protecting FTI, PII and PHI against unauthorized access, use, and disclosure. Environmental controls can be critical when FTI and PII have high availability requirements (e.g., core mission capabilities of an organization rely on consistent and frequent access to PII/FTI)

PE-1 The Program must develop and maintain the Physical and Environmental Protection family of controls to ensure physical access to information systems, equipment, and the respective operating environments is limited to authorized individuals. The Program must:

PE-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Physical and Environmental Protection family of controls in the ARS to:

PE-1.1.1 Limit physical access to information systems, equipment, and the respective operating environments to authorized individuals.

PE-1.1.2 Protect the physical plant and support infrastructure for information systems.

PE-1.1.3 Provide supporting utilities for information systems.

PE-1.1.4 Protect against environmental hazards.

PE-1.1.5 Consider the data sensitivity when defining physical and environmental controls for systems.

PE-1.1.6 Maintain an understanding that the sensitivity of information impacts the necessary physical and environmental controls.

PE-1.2 Develop a Physical and Environmental Protection Policy which is consistent with the ARS and other federal requirements.

PE-1.3 Review and update policies, procedures, and standards for the Physical and Environmental Protection Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​Planning (PL)

PL-1 The Program must develop and maintain the Planning family of controls to ensure information security and privacy planning for FISMA systems are performed within the CMS enterprise environment and on any systems storing, processing, or transmitting CMS information on behalf of CMS. The Program must:

PL-1.1 Designate CMS Enterprise-level defined officials to manage the development, documentation, and dissemination of the Planning family of controls in the ARS to:

PL-1.1.1 Develop, document, and maintain information security and privacy plans for each CMS system and network:

PL-1.1.1.1 Security plans must be in accordance with NIST SP 800-18 Revision 1,

Guide for Developing Security Plans for Federal Information Systems.

PL-1.1.1.2 Privacy plans must address the privacy requirements for confidentiality, availability, and integrity for the organization and individual information system(s). PL-1.1.1.3 Business Owners/ISOs must review and update the information security and privacy plans periodically as defined in the ARS, and following defined events in the ARS and applicable control implementation statements of the associated PL controls.

PL-1.1.2 Develop, document, and maintain an Information Security Architecture to: PL-1.1.2.1 Document the information security segments of the CMS enterprise architecture in accordance with OMB Circular A-130.

PL-1.1.2.2 Fully integrate information security and privacy into the CMS architecture framework.

PL-1.1.3 Review and update the security segments of the CMS enterprise architecture periodically, as defined in the ARS.

PL-1.1.4 Develop, document, and maintain the CMS Acceptable Use standards within the HHS Rules of Behavior For Use of HHS Information and IT Resources Policy.

PL-1.1.4.1 Privacy requirements must be identified in contracts and acquisition- related documents.

PL-1.1.4.2 CMS employees and contractors (users) must:

PL-1.1.4.2.1 Be informed that the use of CMS IT resources, other than for authorized purposes, is a violation of the HHS Rules of Behavior for Use of HHS Information and IT Resource Policy and is grounds for disciplinary action, up to and including removal from federal service, monetary fines, and/or criminal charges, which could result in imprisonment.

PL-1.1.4.2.2 Be prohibited from transmitting sensitive CMS information using any non-CMS approved Internet-based mechanism, including but not limited to personal email, file-sharing, file transfer, and backup services.

PL-1.1.4.2.3 Read and sign the HHS RoB periodically, as defined in the ARS. PL-1.1.4.3 Personal use of CMS IT resources must comply with HHS Rules of Behavior for Use of HHS Information and IT Resource Policy, which governs the appropriate use of CMS IT resources to ensure personal use of those resources does not put CMS data at risk of unauthorized disclosure or dissemination.

PL-1.2 Develop a Planning Control Policy which is consistent with the ARS and other federal requirements.

PL-1.3 Review and update policies, procedures, and standards for the Planning Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​Program Management (PM)

PM-1 The Program must develop and maintain the Program Management family of controls to ensure CMS develops an organization-wide information security and privacy program. The Program Management (PM) controls are typically implemented at the organization level and not specifically directed at individual information systems. Through the PM implementation of the controls, the CMS CISO must:

PM-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Program Management family of controls in the ARS to:

PM-1.1.1 Periodic review and update of the Program Plan following defined events in the ARS or as defined within the SSPP.

PM-1.1.2 CMS develops, maintains and reviews:

PM-1.1.2.1 Information security and privacy policy as an overview of the information security and privacy management controls and common controls.

PM-1.1.2.2 Policy and procedures to ensure requirements for protecting controlled unclassified information processed, stored, or transmitted on external systems are implemented.

PM-1.1.2.3 An accurate accounting of disclosures of personally identifiable information as specified in the ARS.

PM-1.1.2.4 Policies and procedures for reviewing the accuracy, relevance, timeliness, and completeness of PII across the information life cycle as specified in the ARS. PM-1.1.2.5 The process for receiving and responding to complaints, concerns, or questions from individuals about the organizational privacy practices.

PM-1.1.2.6 A privacy program structured to inform the information security program of all privacy-related requirements.

PM-1.1.3 CMS identifies roles, responsibilities, and compliance requirements.

PM-1.1.3.1 CMS must appoint the CISO as the Senior Information Security Officer. PM-1.1.3.2 CMS must appoint individuals with specific roles and responsibilities.

PM-1.1.4 CMS holds the approved AO accountable for the risk to the operations within CMS, organizational assets, individuals, and the nation.

PM-1.1.5 CMS develops, implements, and maintains a Risk Management Strategy to: PM-1.1.5.1 Document remediation actions responding to identified risk.

PM-1.1.5.2 Develop and implement a POA&M process to address information security and privacy risks identified in its information systems.

PM-1.1.5.3 Develop and maintain inventory listings of its information systems.

PM-1.1.5.4 Measure the effectiveness of the Program, information security controls, and privacy controls.

PM-1.1.6 CMS develops, implements, and maintains a testing, training, and monitoring program.

PM-1.2 Develop a Program Management Policy which is consistent with the ARS and other federal requirements.

​​​​​​​Personnel Security (PS)

PS-1 The Program must develop and maintain the Personnel Security family of controls to ensure (i) CMS information systems employ personnel security controls consistent with applicable laws, executive orders, policies, directives, regulations, standards, and guidelines and (ii) procedures are developed to guide the implementation of personnel security controls. The Program must:

PS-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Personnel Security family of controls in the ARS to:

PS-1.1.1 CMS information systems employ personnel security controls consistent with applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards.

PS-1.1.2 Processes and procedures are developed to guide the implementation of personnel security controls.

PS-1.1.2.1 Where appropriate, roles that require access to sensitive information (such as PII and PHI) must apply additional personnel security measures.

PS-1.1.3 Individuals occupying positions of responsibility within organizations (i.e., including third-party service providers) are trustworthy and meet established security criteria for the positions of responsibility.

PS-1.1.4 Information and information systems are adequately protected when personnel actions occur such as initial employment, terminations, and transfers.

PS-1.1.5 Formal sanctions for personnel failing to comply with organizational security policies and procedures are employed.

PS-1.2 Develop a Personnel Security Policy which is consistent with the ARS and other federal requirements.

PS-1.3 Review and update policies, procedures, and standards for the Personnel Security Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​PII Processing and Transparency (PT)

PT-1 The Program must develop and maintain the Processing and Transparency family of controls to ensure the confidentiality of Personally Identifiable Information being processed and maintained by CMS organizational information systems.

PT-1-1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Personally Identifiable Information Processing and Transparency family of controls in the ARS to. The Program Must:

PT-1-1-1 Coordinate with the SOP and the CISO in establishing the organizational authority for the use of Personally Identifiable Information being processed and developing processes to restrict the use of PII.

PT-1-1-2 Ensure public notices and policies are developed to describe the purpose for processing PII and monitoring changes.

PT-1-1-3 Ensure procedures are in place for individuals to consent to the processing of their personally identifiable information prior to its collection to allow for them to make informed decisions regarding the use of their personal information.

PT-1-1.4 Establish privacy risk assessments associated with the processing of personally identifiable information to help determine the appropriate elements to include in privacy notices.

PT-1-1-5 Develop, publish and maintain system of records notices in accordance with OMB guidance when systems are used to maintain a group of any record under the control of CMS from which information is retrieved by the name of an individual or some type of identifying number, symbol, or other identifier.

PT-1-1-5 Obtain approval from the Data Integrity Board when systems or organizations conduct computer matching programs.

PT-1-2 Develop a Personally Identifiable Information Processing and Transparency Policy which is consistent with the ARS and other federal requirements.

PT-1-2 Review and update policies, procedures, and standards for the Personally Identifiable Information Processing and Transparency Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​Risk Assessment (RA)

RA-1 Designate CMS Enterprise-level defined officials to manage the development, documentation, and dissemination of the Risk Assessment family of controls to:

• Ensure the risk to organizational operations (e.g., mission, functions, image, reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information, is assessed.
• Develop, document, implement, and update a risk assessment at least every three years or whenever a significant change occurs to the information system, a change in the threat environment occurs, a significant data breach occurs, or the ATO has expired.

The Program must:

RA-1.1 Develop and maintain effective implementation of selected information security and privacy controls and control enhancements in the Risk Assessment family of controls as described in the ARS to ensure formal risk assessment processes and policies provide the foundation for protecting sensitive information.

RA-1.2 Develop a Risk Assessment Policy which is consistent with the ARS and other federal requirements.

RA-1.3 Review and update policies, procedures, and standards for the Risk Assessment Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​System and Services Acquisition (SA)

SA-1 The Program must develop and maintain the System and Services Acquisition family of controls to ensure contracts, especially the Statement of Work (SOW) within the contract, are reviewed for appropriate information security and privacy contracting language specific to the technology or service being acquired. Through the Program, the CMS CISO must:

SA-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the System and Services Acquisition family of controls defined in the ARS to ensure:

SA-1.1.1 Appropriate information security and privacy documentation (i.e., information security and privacy functional requirements/specifications, information security-related and privacy-related documentation requirements, and developmental and evaluation- related assurance requirements) are contractually required for the development or acquisition of new systems.

SA-1.1.2 Appropriate information security and privacy language to protect sensitive information, such as PII and PHI, is contractually required for the development, acquisition, or operation of systems, when applicable.

SA-1.1.3 Documented processes and procedures are developed and implemented effectively to facilitate the acquisition of information security and privacy controls in all system and services acquisitions.

SA-1.1.4 Processes and procedures are consistent with applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards.

SA-1.1.5 Sufficient resources to adequately protect organizational information systems are allocated by the responsible organization.

SA-1.1.6 System development life cycle processes, as defined under the SDLC, incorporate required information security and privacy considerations.

SA-1.1.7 Software usage and installation restrictions are employed and compliant with CMS policy.

SA-1.1.8 Security specifications, either explicitly or by reference, are included in information system acquisition contracts based on an assessment of risk and in accordance with applicable federal requirements and industry best practices.

SA-1.1.9 Security measures consistent with applicable federal requirements and industry best practices to protect information, applications, and/or services outsourced from the organization are required of third-party vendors and are verified as specified in the ARS.

SA-1.2 Develop a System and Services Acquisition Policy which is consistent with the ARS and other federal requirements.

SA-1.3 Review and update policies, procedures, and standards for the System and Services Acquisition Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​System and Communications Protection (SC)

SC-1 The Program must develop and maintain the System and Communications Protection family of controls to ensure the organization develops, documents, and maintains system and communications protection policy, processes, and procedures. Through the Program the CMS CISO must:

SC-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the System and Communications Protection family of controls in the ARS to:

SC-1.1.1 Review and update the System and Communications Protection Policies and Procedures periodically and following defined events in the ARS or as defined within the SSPP.

SC-1.1.2 Protect the system’s assets and information while in transmission or at rest with technical controls based on:

• The confidentiality, integrity, and availability of the system
• The sensitivity of information (e.g., PII and PHI) processed or stored by the system.

SC-1.1.3 Ensure the information system separates user functionality, including user interface services, from system management functionality. By applying the systems security engineering design principles within the TRA to:

SC-1.1.3.1 Isolate access and information flow control from non-security functions and from other security functions.

SC-1.1.3.2 Determine if the information system uses underlying hardware separation mechanisms to implement security function isolation.

SC-1.1.3.3 Minimize the number of non-security functions included within the isolation boundary containing security functions by implementing security and privacy functions as:

• Largely independent modules to maximize internal cohesiveness within modules and minimize coupling between modules
• A layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

SC-1.1.4 Implement information security and privacy controls throughout the SDLC of each system by:

• Implementing usage restrictions based on the potential risk of harm to an information system
• Authorizing, monitoring, and controlling the use of such components within the information system

SC-1.1.5 Operate websites that are within the restrictions stated in federal policies and directives.

SC-1.2 Develop a System and Communications Protection Control Policy which is consistent with the ARS and other federal requirements.

SC-1.3 Review and update policies, procedures, and standards for the System and Communications Protection Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​System and Information Integrity (SI)

SI-1 The Program must develop and maintain the System and Information Integrity family of controls to establish and maintain policy and procedures for the effective implementation of selected information security controls and control enhancements. Through the Program, the CMS CISO must:

SI-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the System and Information Integrity family of controls in the ARS to:

SI-1.1.1 Policy, processes, and procedures are consistent with applicable federal laws, executive orders, mandates, directives, regulations, and HHS and CMS policies and standards.

SI-1.1.2 Policy, processes, and procedures are implemented to protect the integrity of systems and information and to meet the Privacy Act requirements for protection against any anticipated threats or hazards to the security or integrity of records.

SI-1.1.3 Information and information system flaws are identified, reported, and corrected in a timely manner, as defined within the ARS.

SI-1.1.4 Protection from malicious code is provided at appropriate locations within organizational information systems.

SI-1.1.5 Information system security and privacy alerts and advisories issued are monitored and appropriate action taken in response.

SI-1.1.6 Minimum information security and privacy controls are supplemented, as warranted, based on an assessment of risk and local conditions, including organization- specific security requirements, specific threat information, cost-benefit analysis, and special circumstances.

SI-1.1.7 A monitoring strategy is developed to implement an ISCM program that is compliant with Federal Rules of Evidence Section 803(6).

SI-1.2 Develop a System and Information Integrity Policy which is consistent with the ARS and other federal requirements.

SI-1.3 Review and update policies, procedures, and standards for the System and Information Integrity Control family of controls and following defined events in the ARS or as defined within the SSPP.

​​​​​​​Supply Chain Risk Management (SR)

SR-1 The Program must develop and maintain the Supply Chain Risk Management (SR) family of controls to establish and maintain policy and procedures for the effective implementation of the selected information security controls and control enhancements. In coordination with the CISO, the program, the organization must:

SR-1.1 Designate CMS Enterprise level defined officials to manage the development, documentation, and dissemination of the Supply chain risk management family of controls in the ARS to:

SR-1.2 Develop a Supply chain risk management Policy which is consistent with the ARS and other federal requirements.

SR-1.3 Coordinate with the CMS CISO to establish a process to identify and address weaknesses or deficiencies in the supply chain elements.

SR-1.4 Establish procedures and agreements with entities involved in the supply chain for systems, system components or system services to ensure notification of supply chain compromises that can potentially adversely affect organizational systems.

SR-1.5 Review and update policies, procedures, and standards for the Supply chain risk management Control family of controls and following defined events in the ARS or as defined within the SSPP.

Non-Compliance

The HHS Rules of Behavior (RoB) for Use of Information IT Resources Policy cannot account for every possible situation. Therefore, where this Policy does not provide explicit guidance, personnel shall use their best judgment to apply the principles set forth in the standards for ethical conduct to guide their actions and seek guidance when appropriate from the Chief Information Officer (CIO) or his/her designee.

Non-compliance with the requirements in this Policy may be cause for disciplinary and non- disciplinary actions. Depending on the severity of the violation and management discretion, consequences may include one or more of the following actions:

1. Suspension of access privileges;
2. Revocation of access to federal information, information systems, and/or facilities;
3. Reprimand;
4. Termination of employment;
5. Suspension without pay;
6. Removal or disbarment from work on federal contracts or projects;
7. Monetary fines;
8. Criminal charges that may result in imprisonment;
9. Deactivate the accounts.

Information and Assistance

CMS ISPG is responsible for the development and management of this policy. Questions, comments, suggestions, and requests for information about this Policy should be directed to: CISO@cms.hhs.gov.

Effective Date and Implementation

The effective date of this policy is the date on which the policy is approved. This policy must be reviewed, at a minimum, every three (3) years from the approval date.

The CMS CIO has the authority to grant a one (1) year extension of the policy. To archive this policy, approval must be granted, in writing, by the CMS CIO.

Approval

George Hoffmann

CMS Chief Information Officer

Concurrence

This document will be reviewed in accordance with the established review schedule located on the CMS website.

Keith Busby

CMS Chief Information Security Officer

Authoritative References, Statutes, Orders, Directives, Policies, and Guidance

Federal Directives and Policies

• Federal Continuity Directive 1 (FCD 1): Federal Executive Branch National Continuity Program and Requirements, February 2008
• HSPD-12, Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004
• HSPD-7, Critical Infrastructure Identification, Prioritization, and Protection
• Office of Assistant Secretary for Administration and Management and Office of the Assistant Secretary for Resources and Technology: Statement of Organization, Functions, and Delegations of Authority, 74 Fed. Reg. 57679-57682 (2009)
• Office for Civil Rights: Delegation of Authority, 74 Fed. Reg. 38630 (2009) Office of Resources and Technology: Statement of Organization, Functions and Delegations of Authority, 73 Fed. Reg. 31486-31487 (2008)
• Office of the Secretary: Statement of Organization, Functions, and Delegations of Authority, 72 Fed. Reg. 19000-19001 (2007)
• Office of Personnel Management (OPM) Regulation 5 Code of Federal Regulations (CFR) 930.301

Statutes

• The Health Information Technology for Economic and Clinical Health Act, enacted as part of the American Recovery and Reinvestment Act of 2009
• Public Welfare, Title 45 Code of Federal Regulations, Pt. 160. 2009 ed.
• Federal Acquisition Regulation (as amended)
• E-Government Act of 2002
• The Federal Information Security Management Act (Pub. L. No. 107-347)
• Clinger-Cohen Act of 1996
• The Health Insurance Portability and Accountability Act of 1996
• Paperwork Reduction Act of 1995
• Children’s Online Privacy Protection Act of 1988
• The Computer Matching and Privacy Protection Act of 1988
• The Privacy Act of 1974 (as amended)
• Office of Federal Procurement Policy Act of 1974
• Freedom of Information Act of 1966 (Public Law 89-554, 80 Stat. 383; Amended 1996,2002, 2007)
• Federal Records Act of 1950

N.3. HHS Policy

• HHS-OCIO-OIS-2021-11-006, HHS Policy for Information Security and Privacy Protection (IS2P)
• HHS-OCIO-OIS-2021-03-001, HHS Policy for Information Technology Procurements - Security and Privacy Language
• HHS-OCIO-OIS-2020-01-001, HHS Policy for Securing Wireless Local Area Networks
• HHS-OCIO-PIM-2020-05-003, HHS Policy and Plan for Preparing for and Responding to a Breach of Personally Identifiable Information (PII)
• HHS-OCIO-PIM-2020-06-004, HHS Policy for Records Management
• HHS-OCIO-OIS-2019-05-004, HHS Rules of Behavior for the Use of HHS Information and IT Resources Policy
• HHS-OCIO-2018-0001.002S, HHS System Inventory Management Standard
• HHS-OCIO-2017-0001.001S, HHS OCIO Minimum Security Configuration Standards Guidance
• HHS-OCIO-2016-0005, HHS Standard for Encryption of Computing Devices and Information
• HHS-OCIO-2013-0004, Policy for Personal Use of Information Technology Resources
• HHS-OCIO-2012-0001.001S, Standard for Plans of Action and Milestones (POA&M) Management and Reporting
• HHS-OCIO-2010-0002, HHS-OCIO Policy for Capital Planning and Investment Control
• HHS-OCIO-2008-0004.001, HHS OCIO Policy for Information Technology (IT) Enterprise Performance Life Cycle (EPLC)
• HHS-OCIO-2008-0001.003, HHS Policy for Responding to Breaches of Personally Identifiable Information
• HHS CSIRC Concept of Operations
• HHS Minimum Security Configuration Standards
• HHS Memorandum, Continued Implementation of Homeland Security Presidential Directive (HSPD) 12-Policy for a Common Identification Standard for Federal Employees and Contractors
• HHS Memorandum, Resolving Security Audit Finding Disputes
• HHS Memorandum, Security of Information Technology Systems
• HHS Memorandum, Office of Inspector General Management Implication Report – Need for Departmental Security Enhancements for Information Technology Assets
• HHS Memorandum, Updated Departmental Standard for the Definition of Sensitive Information
• HHS Memorandum, Role-Based Training (RBT) of Personnel with Significant Security Responsibilities
• HHS Memorandum, Security Related to Hosting Foreign Visitors and Foreign Travel by HHS Personnel
• HHS Policy for Information Technology (IT): Security and Privacy Incident Reporting and Response
• 48 CFR Chapter 3 Health and Human Services Acquisition Regulation (HHSAR)
• FAC-2005-46, Federal Acquisition Regulation (FAR), amendments
• Department Information Security Policy/Standard Waiver
• HHS Information Security Program Privacy in the System Development Life Cycle
• HHS Memorandum, Federal Information Processing Standards (FIPS) 200 Implementation
• HHS National Security Information Manual
• HHS Personnel Security/Suitability Handbook

OMB Policy and Memoranda

• OMB Circular A-108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act
• OMB Circular A-127, Financial Management Systems
• OMB Circular A-130, Management of Federal Information Resources
• OMB Circular A-123, Management Accountability and Control
• OMB M-14-03, Enhancing the Security of Federal Information and Information Systems
• OMB M-13-13, Open Data Policy – Managing Information as an Asset
• OMB M-12-20, FY 2012 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-11-33, FY 2011 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-11-29, Chief Information Officer Authorities
• OMB M-11-16, 2011 Issuance of Revised Parts I and II to Appendix C of OMB Circular A- 123
• OMB M-11-11, Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors
• OMB M-11-02, Sharing Data While Protecting Privacy
• OMB M-10-22, Guidance for Online Use of Web Measurement and Customization Technologies
• OMB M-10-23, Guidance for Agency Use of Third-Party Websites and Applications
• OMB M-10-15, FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-10-06, Open Government Directive
• OMB M-09-29, FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-08-21, FY 2008 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-08-23, Securing the Federal Government’s Domain Name System Infrastructure
• OMB M-08-09, New FISMA Privacy Reporting Requirements for FY 2008
• OMB M-08-10, Use of Commercial Independent Risk Analysis Services Blanket Purchase Agreements (BPA)
• OMB M-07-20, FY 2007 E-Government Act Reporting Instructions
• OMB M-07-19, FY 2007 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information
• OMB M-06-20, FY 2006 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-06-19, Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments
• OMB M-06-16, Protection of Sensitive Agency Information
• OMB M-06-15, Safeguarding Personally Identifiable Information
• OMB M-05-24, Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors
• OMB M-05-15, FY 2005 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management
• OMB M-05-08, Designation of Senior Agency Officials for Privacy
• OMB M-05-04, Policies for Federal Agency Public Websites
• OMB M-04-26, Personal Use Policies and ‘File Sharing’ Technology
• OMB M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E- Government Act of 2002 (as amended)
• OMB M-04-04, E-Authentication Guidance for Federal Agencies
• OMB M-01-24, Reporting Instructions for the Government Information Security Reform Act
• OMB M-01-05, Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy
• OMB M-99-20, Security of Federal Automated Information Resources
• OMB M-99-05, Instructions on Complying with President's Memorandum of May 14, 1998, "Privacy and Personal Information in Federal Records"
• OMB M-96-20, Implementation of the Information Technology Management Reform Act of 1996

​​​​​​​NIST Guidance

• NIST SP 800-122, Guide to Protecting Confidentiality of PII
• NIST SP 800-81, Secure Domain Name System (DNS) Deployment Guide
• NIST SP 800-65, Integrating IT Security into the Capital Planning and Investment Control Process
• NIST SP 800-64, Security Considerations in the System Development Lifecycle
• NIST SP 800-63, Electronic Authentication Guideline
• NIST SP 800-61, Computer Security Incident Handling Guide
• NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories: (2 Volumes) - Volume 1: Guide Volume 2: Appendices
• NIST SP 800-58, Security Considerations for Voice Over IP Systems
• NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans
• NIST SP 800-53, Recommended Security Controls for Federal Information Systems
• NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
• NIST SP 800-34, Contingency Planning Guide for Information Technology Systems
• NIST SP 800-30, Risk Management Guide for Information Technology Systems
• NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems
• NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model
• NIST United States Government Configuration Baseline for Windows XP & Vista
• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems
• FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
• FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST United States Government Configuration Baseline (USGCB)

​​​​​​​CMS Policy and Directives

• CMS Information Security Acceptable Risk Safeguards, CMS ARS Version 5.0
• CMS Vulnerability Disclosure Policy Program
• CMS Supply Chain Risk Management Policy

​​​​​​​Associated CMS Resources

The CMS ISPG Library is available at: https://security.cms.gov. It contains up-to-date policies, procedures, and directives, including those approved after release of this Policy.