What is the Risk Management Framework (RMF)?

The National Institute of Standards and Technology (NIST) created the RMF to provide a structured, flexible process to manage risk throughout a system’s life cycle. Using the RMF process helps CMS authorize and monitor our information systems and keep them safe.

The RMF is made up of 7 steps:

• Prepare (this step)
• Categorize
• Select
• Implement
• Assess
• Authorize
• Monitor

What is the Prepare Step?

The Prepare step outlines the essential activities that all levels of CMS should carry out in order to manage its security and privacy risks.

Completing the Prepare step will generate these outcomes for CMS:

• Identify key risk management roles
• Establish risk management strategy
• Determine risk tolerance
• Complete CMS-wide risk assessment
• Develop and implement CMS-wide strategy for continuous monitoring
• Identify common controls

Organizational-level Prepare Tasks

Organizational-level tasks are completed as part of the Information Security and Privacy Program managed by the Office of Information Technology (OIT).

Individual systems do not need to complete these organizational-level tasks, but they are listed here for reference.

Task P-1: Risk management roles

The first Prepare task is to identify and assign individuals to specific roles associated with security and privacy risk management. Clearly defining roles and responsibilities provides a solid foundation for the entire risk management process, ensuring accountability and clear ownership throughout CMS.

Potential inputs

• Defined organizational security and privacy policies and procedures. Those help prepare CMS to manage its security and privacy risks using the RMF.
• Organizational charts to facilitate better communication between CMS senior leaders and executives, its mission and business process levels.

Expected outputs

• Documented Risk Management Framework role assignments. Individuals are identified and assigned key roles for executing the RMF.

Discussion: Task P-1 highlights the importance of having adequate resources and a defined governance structure in place to make it possible to create cost-effective and consistent risk management processes across CMS.

CMS has documented roles with risk management responsibilities in the CMS IS2P2 for roles and responsibilities. This information was derived from the HHS IS2P, NIST guidance, and OMB policy requirements, then narrowed down to CMS-specific needs.

Roles with responsibilities tied to Task P-1 include the Head of the Agency, the Chief Information Officer (CIO), and the Senior Agency Information Security Officer (SAISO).

For additional information on roles and responsibilities visit the NIST RMF roles and responsibilities crosswalk.

The CMS Organizational Chart (PDF), provides the CMS organizational structure, current roles and points of contacts.

Cybersecurity Framework: ID.AM-6; ID.GV-2

Task P-2: Risk management strategy

Establish a risk management strategy for CMS that includes the organizational objectives and a determination of risk tolerance.

Potential inputs

• Organizational mission statement that defines CMS purpose, values and objectives.
• Organizational policies and procedures that align with CMS values and objectives.
• Organizational risk assumptions, constraints, priorities and trade-offs that will inform CMS’s risk management strategy, guide its risk assessment, response, and monitoring activities.

Expected outputs

• A defined risk management strategy of how CMS will assess, respond to, and monitor risk
• Statement of risk tolerance that includes information security and privacy risk (CMS ability to handle different levels of risk), the risk impact, its tolerance level (what CMS is willing to accept) and the risk review schedule

Discussion: CMS uses theCyber risk management and reporting strategy to help ISSOs, Business Owners, and other stakeholders identify and mitigate security and privacy risks to their FISMA systems.

Other supporting documents include:

• CMS IS2P2 Risk management and compliance section
• CMS Acceptable Risk Safeguards (ARS) 5.1
• CMS Cyber Risk Management Plan (CRMP)
• CMS Information System Risk Assessment (ISRA)
• CMS Cyber Security and Risk Assessment Program (CSRAP)

CMS has established an Ongoing Authorization program that monitors CMS FISMA systems to address real-time threats and allow you to make risk-based decisions.

The CMS ARS provides mandatory and supplemental controls, customizable by Business Owners, to meet mission or business functions, threats, security and privacy risks (including supply chain risks), type of system, or risk tolerance.

Roles with responsibilities tied to Task P-2 include the Head of the Agency and Risk Executive (Function).

Cybersecurity Framework: ID.RM; ID.SC

Task P-3: Risk assessment—organization

Assess security and privacy risks across CMS, and update the risk assessment results on an ongoing basis.

Potential inputs

• Risk management strategy
• Mission or business objectives
• Current threat information
• System-level security and privacy risk assessment results
• Supply chain risk assessment results
• Previous organization-level security and privacy risk assessment results
• Information sharing agreements or memoranda of understanding
• Security and privacy information from continuous monitoring

Expected outputs

• Documented risk assessment results that identify strategies used to identify and prioritize risks that could impact CMS operations, assets and individuals

Discussion: CMS carries out security control assessments and vulnerability scanning to identify and report on CMS organizational risks. The Cybersecurity Integration Center (CCIC) provides reporting metrics and risk analysis through Continuous Diagnostics and Mitigation (CDM) by ingesting scan logs and identifying risks using its Security Incident Event Management (SIEM) tool.

CMS manages its risk assessment process through the Cybersecurity and Risk Assessment Program (CSRAP).

You can schedule assessments through the CMS CSRAP Confluence page. Select dates for the type of CSRAP assessment you require:

• Security Assessment slots (login required)
• Risk Assessment slots (login required)

You can schedule CSRAP/SCA and Penetration Testing (PenTest) for both security & privacy assessments.

For more information email the CSRAP team at CSRAP@cms.hhs.gov with your requested dates.

CMS also communicates in monthly Cyber Risk Reports. We use Tableau dashboards for snapshots of the overall health of CMS systems, including the CMS Information System Risk Assessment (ISRA). Those are completed within the security category tab of the CMS FISMA Continuous Tracking System (CFACTS).

Some of the roles with responsibilities tied to Task P-3 include: Senior Accountable Official for Risk Management or Risk Executive (Function), and Senior Agency Information Security Officer (SAISO) and Senior Agency Official for Privacy (SAOP).

Cybersecurity Framework: ID.RA; ID.SC-2

Task P-4: Organizationally tailored control baselines and cybersecurity framework profiles (optional)

Establish, document, and publish organizationally-tailored control baselines and cybersecurity framework profiles. This task is optional.

Potential inputs

• Documented security and privacy requirements directing the use of organizationally tailored control baselines, using federal cybersecurity guidelines and standards
• Mission or business objectives
• Enterprise architecture
• Security architecture
• Privacy architecture
• CMS- and system-level risk assessment results
• List of common control providers and common controls available for inheritance
• NIST Special Publication 800-53B control baselines

Expected outputs

• List of approved or directed organizationally-tailored control baselines that are specific to CMS's risk profile and operational needs
• Implementation of NIST CSF Profiles that align with CMS’s functions, categories, and subcategories of the business requirements, risk tolerance, and resources
  • For CMS-specific cybersecurity activities, these CSF profiles can describe:
    • The current state: Profile indicates CMS cybersecurity outcomes that are currently being achieved
    • The desired target state: Profile indicates the outcomes needed to achieve CMS cybersecurity risk management goals

Discussion: CMS implements the Security & Privacy Planning taken from NIST 800-53 Rev5 and tailored into CMS environment within the ARS 5.1. to define CMS baseline of minimum information security and privacy assurance. These controls are based on governance documents and laws, regulations, and other authorities both internal to CMS and from external institutions.

CMS also implements the Security and Privacy Handbooks that provide overall guidance on how to implement CMS policies and standards across many cybersecurity topics while considering CMS Mission and Business objectives.

Some of the roles with responsibilities tied to Task P-4 includes the mission or business Owner (BO) and Senior Accountable Official for Risk Management or Risk Executive (Function).

Task P-5: Common control identification

Identify, document, and publish CMS-wide common controls that can be inherited by organizational systems.

Potential inputs

• Utilize the CMS information system inventory, the current security and privacy controls and their implementation status to document each security and privacy requirements
• Existing common control providers and associated security and privacy plans
• Information security and privacy program plans
• Organization- and system-level security and privacy risk assessment results

Expected outputs

• A list of common control providers and common controls available for CMS systems to inherit
• Security and privacy plans (or equivalent documents) describing the common control implementation (including inputs, expected behavior, and expected outputs)

Discussion: CMS provides controls derived from NIST 800-53 Rev5 and HHS IS2P control baselines into the CMS Acceptable Risk Safeguard (ARS) 5.1 and made available for inheritance to CMS systems.These serve as a starting point for determining the appropriate controls and countermeasures necessary to protect CMS information systems.

The CMS Common control provider is tasked with providing control inheritance and management of these common controls.

Some of the roles with responsibilities tied to Task P-5 include the Senior Agency Information Security Officer (SAISO), Senior Agency Official for Privacy (SAOP), and Common Control Provider.

Task P-6: Impact-level prioritization (optional)

Prioritize CMS systems and assets based on their impact level, to aid in guiding resource allocation and risk management efforts.

This task is optional.

Potential inputs

• Security categorization information for CMS systems
• System descriptions
• Organization- and system-level risk assessment and impact analyses
• Organization mission or business objectives
• Cybersecurity Framework Profiles

Expected outputs

• CMS systems and assets prioritized by their impact level into low-, moderate-, and high-impact sub- categories
• Guidelines for allocating resources based on the prioritization

These outputs allow CMS to focus on protecting high-impact systems and assets critical to its mission, ensuring that the most significant risks are addressed first.

Discussion: Impact-level prioritization enforces Security categorization that describes the potential adverse impacts to CMS operations, assets, and individuals if CMS information and information systems are compromised through a loss of confidentiality, integrity, and/or availability (CIA).

CMS has synthesized and identified the information types that apply to CMS using NIST 800-60 volume 1 Rev 1 as a guide into nine (9) CMS information types.

CMS prioritizes systems that support its Mission Essential Functions (MEFs) and its Essential Supporting Activities (ESAs) while providing ARS 5.1 controls for all Low, Moderate, High and HVA systems. These priorities are based on the system's risk profile and vulnerability metrics, indicating a direct correlation with the task's goal of impact-level prioritization based on risk.

Some of the roles with responsibilities tied to Task P-6 include the Senior Accountable Official for Risk Management or Risk Executive (Function), and Mission or Business Owners.

Cybersecurity Framework: ID.AM-5

Task P-7: Organization-wide continuous monitoring strategy

Develop and implement an organization-wide strategy for continuously monitoring control effectiveness.

Potential inputs

• Risk management strategy and priorities
• Organization- and system-level risk assessment results
• CMS security and privacy policies

Expected outputs

• A comprehensive continuous monitoring strategy that includes mechanisms for assessing control effectiveness, reporting on security and privacy posture, and responding to changes in risk

Discussion: CMS complies with the HHS Information Security Continuous Monitoring (ISCM) strategy and further defines the control assessment frequencies within the CMS Acceptable Risk Safeguards (ARS).

CMS maintains an ongoing awareness of information security, vulnerabilities, and threats to support its risk management decisions. This includes continuous visibility into the actions of users, applications, and devices through a centralized log data collection.

By implementing a robust continuous monitoring program, the Continuous Diagnostics and Mitigation (CDM) Program and Security Control Assessments determine if a system's security and privacy controls are implemented correctly and operating effectively.

The CDM provides automated scanning capabilities and risk analysis to strengthen the security posture of CMS FISMA systems on an ongoing basis. This lets CMS maintain situational awareness of its security and privacy posture, facilitating timely responses to emerging threats and vulnerabilities. CMS also uses asset inventories and vulnerability management scanning to keep tabs on both resources that employees use (e.g. laptops) and the applications and infrastructure they use as an effort to enhance its continuous monitoring program.

Some of the roles with responsibilities tied to Task P-6 include the Senior Accountable Official for Risk Management or Risk Executive (Function), Chief Information Officer (CIO), Senior Agency Information Security Officer (SAISO) and Senior Agency Official for Privacy (SAOP).

Cybersecurity Framework: DE.CM; ID.SC-4

System Level Prepare Tasks

System level Prepare tasks also take into consideration mission or business process concerns.

Task P-8: Risk mission or business focus

Identify the missions, business functions, and mission or business processes that the information system is intended to support. Ensure that they provide adequate support to CMS objectives.

Potential inputs

• CMS mission statement
• CMS policies
• Mission or business process information
• System stakeholder information
• Cybersecurity Framework Profiles
• Requests for proposal (RFPs) or other acquisition documents
• Concept of operations and any current or future operational requirements

Expected outputs

• Documentation linking information systems to the various missions, business functions, and mission or business processes that the systems will support
• Establish a prioritized list of information systems requirements based on the systems mission and business importance

Discussion: The overall goal of Task P-8 is to ensure that CMS technology investments are directly tied to supporting its mission and business goals.

CMS has established and continues to support the development and maintenance of Business Continuity Plans and Disaster Recovery Plans for the protection of systems and components that are tied to its Essential Support Activities (ESAs), to ensure that CMS can perform Mission Essential Functions (MEFs).

For example, the CMS Continuity of Operations Plan (COOP), Emergency Relocation Group (ERG) and Devolution Emergency Response Group (DERG) all ensure the continuation of CMS essential functions.

CMS systems are required to have an Information System Contingency Plan (ISCP) to protect CMS from potential risks and ensure the continuity of operations. 

CMS also requires that its Business Owners (BO) complete a Business Impact Analysis (BIA) every two (2) years to document the business impact of any service to CMS missions, business functions, and mission or business processes.

Some of the roles with responsibilities tied to Task P-8 include the Mission or Business Owner and Information System Owner (ISO).

Cybersecurity Framework: Profile; Implementation Tiers; ID.BE

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-9: System stakeholders

Identify stakeholders who have an interest in the design, development, implementation, assessment, operation, maintenance, or disposal of the system. This ensures that their needs are considered in the system's risk management process.

Potential inputs

• CMS mission statement
• Mission or business objectives
• Missions, business functions, and mission or business processes that the system will support
• Other mission or business process information
• CMS security and privacy policies and procedures
• CMS charts
• Information about individuals or groups (internal and external) that have an interest in and decision-making responsibility for the system. This includes stakeholder analysis or feedback from previous projects or operational activities

Expected outputs

• A comprehensive list of stakeholders for each system
• A defined process of engagement and collaboration outlining how stakeholders will be involved in the system's risk management process

Discussion: The CMS IS2P2 – Roles and Responsibilities section provides descriptions for CMS personnel that are required to complete their records such as the System Security and Privacy Plan (SSPP) generated by CFACTS, the tool used at CMS for Governance, Risk, and Compliance (GRC). 

CMS systems are encouraged to maintain a list of stakeholders within CFACTS including any interconnecting systems and their stakeholders under the Boundary tab in CFACTS as an effort to improve stakeholder engagement in managing and documenting the risk management process of their systems.

Some of the roles with responsibilities tied to Task P-9 include the System Owner (SO), Senior Agency Officials for Privacy (SAOP), Chief Information Officer (CIO), and others.

Cybersecurity Framework: ID.AM; ID.BE

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-10: Asset identification

Identify assets that require protection such as assets associated with CMS information systems, including hardware, software, data, and personnel.

Potential inputs

• An inventory of each information system's current assets
• Each information system’s operational requirements, based on the CMS missions, business functions, and mission or business processes that the system will support
• Business impact analyses
• Internal stakeholders
• System stakeholder information
• System information
• Information about other systems that interact with the system

Expected outputs

• An updated and comprehensive asset inventory for each systemthat requires protection
  • The assets in each inventory must be categorized based on their importance to CMS's mission and their level of sensitivity

Discussion: The CMS Continuous Diagnostics and Mitigation (CDM) program maintains an automated authorized hardware and software inventory, including FISMA tagging, mapping and asset discovery as part of its Hardware Asset Management (HWAM) and Software Asset Management (SWAM). 

The program is implemented in four (4) phases to address:

• What is on the network
• Who is on the network
• What is happening on the network
• How the data is protected

CMS system assets are identified using data analytics in Tableau and then pushed to CFACTS.

Some of the roles with responsibilities tied to Task P-10 include the System Owner (SO) and Information System Security Officer (ISSO).

Cybersecurity Framework: ID.AM

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-11: Authorization boundary

Determine the authorization boundary of the information system. Clearly delineate the components that are included within the system's authorization scope. To standardize the approach to determine and define the authorization boundary, systems are encouraged to create a checklist or boundary diagram template for reporting systems or ISSOs.

Potential inputs

• System design documentation
• Network diagrams
• System stakeholder information
• Asset information
• Network and/or enterprise architecture diagrams that include the integration and dependency information for interconnected systems
• CMS structure (charts, information)

Expected outputs

• Documented authorization boundary that includes diagrams or other visual representations of the system boundary. Having these effectively determines the scope for risk assessments and for defining the extent of security and privacy control.

Discussion: CMS implements an Ongoing Authorization (OA) program and a Federal Risk and Authorization Management Program (FedRAMP) that define the scope of a particular system that can be continuously managed and monitored.

The OA program supports the FISMA authorization system boundary, which can include one or more cloud offerings.

The FedRAMP authorization boundary is exclusively for cloud service offerings, and may include the full stack (infrastructure, platform, and software) or just parts.

Defining the authorization boundaries can be identified in the Boundary tab for each system within CFACTS.

Some of the roles with responsibilities tied to Task P-11 include the Authorizing Official (AO), System Owner, and Enterprise Architect.

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-12: Information types

Identify the types of information to be processed, stored, and transmitted by the information system to determine the appropriate levels of protection.

Potential inputs

• System design documentation
• Assets to be protected
• Mission or business process information
• Data classification and categorization policies
• Consideration of legal and regulatory requirements impacting data

Expected outputs

• A list of information types for the system categorized by the level of sensitivity and impact
• A detailed documentation of the type and level of protection required for each information type needed to comply with legal and regulatory requirements related to information protection

Discussion: CMS provides system categorization in CFACTSguidance to help systems complete their FIPS 199 security categorization in CFACTS. Theinformation types are categorized based on security and privacy consideration, determined by the CMS Policy team and documented in CFACTS.

The CMS Office of Strategic Operations and Regulatory Affairs (OSORA) (email: OSORA_Regs_Scheduling@cms.hhs.gov) and the CMS Records Retention (email: Records_Retention@cms.hhs.gov) offer guidance on protection and retention of all CMS data.

Some of the roles with responsibilities tied to Task P-12 include the System Owner (SO) and Information Owner or Steward, and the Senior Agency Official for Privacy (SAOP).

Cybersecurity Framework: ID.AM-5

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-13: Information life cycle

Identify and understand all stages of the information life cycle, from creation to final disposition, for each information type processed, stored, or transmitted by the information system.

Understanding the importance of the information life cycle is vital for the design and evaluation of the information systems, because the controls for each stage of the information life cycle are linked to their respective CMS TLC phases.

Potential inputs

• Data management policies and procedures that align with CMS missions, business functions, and mission or business processes the system will support
• System stakeholder information
• Authorization boundary information
• Information about other systems that interact with the system (e.g., information exchange/connection agreements)
• System design documentation outlining data flows and storage
• System element information
• List of system information types

Expected outputs

• Identify all security and privacy controls required at each stage of the information life cycle
• Document the stages through which information passes in the system, such as a data map or model illustrating how information is structured or is processed by the system throughout its life cycle
  • Such documentation includes data flow diagrams, entity relationship diagrams, database schemas, and data dictionaries

Discussion: The CMS Office of Strategic Operations and Regulatory Affairs (OSORA) provides guidance on the CMS systems information life cycle.

The Technical Reference Architecture (TRA) provides the authoritative technical architecture approach and technical reference standards that must be followed by all CMS systems. This approach helps in identifying potential vulnerabilities and in ensuring that data is protected appropriately at all stages.

The information life cycle task is vital for systems handling sensitive or regulated data, ensuring compliance with data protection laws and policies.

Some of the roles with responsibilities tied to Task P-13 include the Senior Agency Official for Privacy (SAOP) and System Owner, and the Information Owner/Steward.

Cybersecurity Framework: ID.AM-3; ID.AM-4

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-14: System-level risk assessment

Conduct a system-level risk assessment to identify, prioritize, and document risks associated with the operation and use of the system. Update the results on an ongoing basis.

Potential inputs

• Asset inventory that needs to be protected
• Missions, business functions, and mission or business processes the system will support
• Business impact analyses or criticality analyses
• System stakeholder information
• Information about other systems that interact with the system
• Provider information
• Threat information
• Data map
• System design documentation (system architecture)
• Cybersecurity Framework Profiles
• Risk management strategy
• Organization-level risk assessment results
• Any previous risk assessments or relevant security and privacy incident reports

Expected outputs

• Security and privacy risk assessment reports detailing identified risks, their likelihood, impact, and recommended mitigation strategies
• Established an action plan to mitigate identified risks and weaknesses

Discussion: CMS Risk Management and Reporting provides information on any potential security and privacy risks to CMS information and system.

The CMS Cyber Risk Management Plan lays the foundation for modernizing CMS approach to identifying and mitigating security and privacy risks associated with the operation of CMS FISMA systems.

CMS implements CSRAP, a security and risk assessment program for CMS FISMA systems that aligns with ISPG strategies and the strategic goal of risk-based program management.

The CMS ISRA documents the overall risk to a system and potential risk reduction strategies.

CMS has established a corrective action plan roadmap to address system weaknesses and the resources required to fix them in a Plan of Action and Milestones (POA&M) that is required whenever audits reveal an area of weakness in security controls.

Risk assessments at CMS are conducted and tracked within CFACTS, showcasing a direct application of this task at the system level.

Some of the roles with responsibilities tied to Task P-14 include the System Owner (SO) and System Security Officer (SSO) or System Privacy Officer (SPO).

Cybersecurity Framework: ID.RA; ID.SC-2

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-15: Requirement definitions

Define the security and privacy requirements specific to the system and its operation environment. Requirements should be things needed to mitigate identified risks and to comply with CMS policies and federal regulations.

Potential inputs

• System design documentation
• Organization- and system-level risk assessment results
• Set of stakeholder assets to be protected
• Missions, business functions, and mission or business processes the system will support
• Business impact analyses or criticality analyses
• System stakeholder information
• Data map of the information life cycle for PII
• Cybersecurity Framework Profiles
• Information about other systems that interact with the system
• Supply chain information
• Threat information
• Laws, executive orders, directives, regulations, or policies that apply to the system
• Risk management strategy

Expected outputs

• Documented security and privacy requirements for the system
• A plan for implementing the necessary controls to meet these requirements

Discussion: CMS implements Security and Privacy Planning Controls to provide guidance on developing the SSPP within CFACTS. The SSPP relates CMS security requirements, defined in the CMS IS2P2, to a set of security controls and control enhancements outlined in the CMS ARS 5.1.

The CMS Security and Privacy Language for IT Procurements helps guide the CISO Team and procurement personnel to determine what kind of security and privacy requirements should be written into a contract before operating in a CMS environment. 

Some of the roles with responsibilities tied to Task P-15 include the Mission or Business Owner (BO) and System Owner (SO) or Information Owner/Steward.

Cybersecurity Framework: ID.GV; PR.IP

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-16: Enterprise Architecture

Determine the placement of the system within the enterprise architecture such that the system's architecture is aligned with CMS's enterprise architecture to support efficient and secure integration and operation within CMS's IT environment.

Potential inputs

• Security and privacy requirements; organization- and system-level risk assessment results; enterprise architecture information; security architecture information; privacy architecture information; asset information.

Expected outputs

• Updated enterprise architecture confirming the system's completion of alignment; updated security architecture; updated privacy architecture; plans to use cloud-based systems and shared systems, services, or applications for integration and optimization.

Discussion: The CMS TRA provides the authoritative technical architecture approach and technical reference standards for all CMS information technology (IT) systems. The infrastructure requirements needed to support and secure high-quality delivery of healthcare services to beneficiaries, providers, and business partners, including aligning CMS systems with the Federal Enterprise Architecture Framework (FEAF).

Some of the roles with responsibilities tied to Task P-16 include the Enterprise Architect and Security or Privacy Architect.

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-17: Requirements allocation

Allocate the defined security and privacy requirements to specific system components, processes and operation environments to ensure comprehensive coverage across the system.

Potential inputs

• Organization- and system-level risk assessment results
• Documented security and privacy requirements
• List of common control providers and common controls available for inheritance
• System description
• System element information
• System component inventory
• Relevant laws, executive orders, directives, regulations, and policies.

Expected outputs

• List of security and privacy requirements allocated to the system, its elements and components, and the environment of operation to ensure that all parts of the system contribute to the overall security and privacy posture

Discussion: CMS implements System and Services Acquisition controls to determine information security and privacy requirements for the information system or information system service in mission or business process planning, document and allocate the resources required to protect the information system or information system service.

Controls for each stage of the information lifecycle are identified by their linked TLC phase, which is relevant for allocating security and privacy requirements to specific system components or processes.

Some of the roles with responsibilities tied to Task P-17 include the System Security Officer (SSO) or System Privacy Officer (SPO) and System Owner (SO).

Cybersecurity Framework: ID.GV

TLC Cycle Phase:

• New: Initiate
• Existing: Operate

Task P-18: System registration

Register the information system within CMS's IT environment. This will formalize its status and ensure that it is recognized and managed as part of CMS’s portfolio of information systems.

Potential inputs

• CMS policy on system registration
• System information (system description, security and privacy requirements, architecture details)
• Information from previous tasks (for example, risk assessment reports, requirements documentation)

Expected outputs

• The system is registered in CMS's IT portfolio in accordance with CMS policies
• Documentation acknowledging the system's registration and outlining any conditions or requirements for operation and maintenance within CMS

Discussion: CMS implements a Security and Privacy Planning (PL) handbook that provides privacy and security requirements for use during the new Authorization to Operate (ATO) cycle for documenting system security compliance enforced by the CMS Chief Information Security Officer (CISO).

CMS also implements the CMS TLC, a governance framework that provides overall guidance for developing and maintaining IT solutions through these four phases: Initiate, Develop, Operate, and Retire. The TLC is enforced by the CMS Office of Information Technology (OIT).

The CMS Technical Review Board (TRB) provides system architecture and infrastructure requirements for all CMS systems to be compliant with as described in the TRA. 

Some of the roles with responsibilities tied to Task P-18 include the System Owner (SO) and Chief Information Officer (CIO).

Cybersecurity Framework: ID.GV

TLC Cycle Phase:

• New: Initiate
• Existing: Operate