CMS Risk Management Framework (RMF): Authorize Step

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
• Categorize
• Select
• Implement
• Assess
• Authorize (this step)
• Monitor

What is the Authorize Step?

The purpose of the Authorize step is to provide organizational accountability by requiring the CMS CIO, as the Authorizing Official to determine if the security and privacy risk (including supply chain risk) to CMS operations and assets, individuals, other organizations, or the Nation based on the operation of a system or use of common controls, is acceptable.   

Task R-1 Authorization Package   

Assemble the authorization package and submit the package to the authorizing official for an authorization decision. 

An Authorization Package is the collection of documentation put together by the System/Business Owner and their team to prove that the system has been designed, categorized, built, tested and assessed appropriately to meet ATO requirements.

Potential Inputs:

• System Security and Privacy Plans (SSPP) document detailed descriptions of how security and privacy controls are selected, implemented and managed for each specific CMS system. It is a living document which forms the baseline for ongoing risk management and compliance efforts.
• Security and Privacy Assessment Report (SAR) details the strengths and weaknesses of implemented controls, highlights discovered issues, and recommends actions to mitigate risks or close identified gaps.
• Plan of Action and Milestones (POA&M) documents all security and privacy findings that need remediation, along with corresponding corrective actions, assigned responsibilities, and target completion dates. It ensures a structured follow-up and resolution of identified findings in compliance with CMS policies.
• Supporting assessment evidence, such as Privacy Impact Assessment (PIA). CMS processes Personal Identifiable Information (PII) and usually requires such PIA to help determine whether privacy risks exists and if so, propose methods to mitigate them, in compliance with relevant privacy laws and regulations.
• Other documentation, as required. See link for more details.

Expected Outputs: Authorization package (usually with an executive summary), is generated on CFACTS - the CMS GRC tool, and submitted to the authorizing official. The CMS CIO is the Authorizing Official. There is no provision for designation of responsibility for this most critical step in the RMF.

Discussion: The System/Business Owner assemble, review and submit the Authorization Package to the CMS CIO - Authorizing Official (AO). This is done in consultation with the other members of their team, including: 

• Security and Privacy Officer (formerly known as ISSO)
• System Developer Maintainer
• Cyber Risk Advisor
• Privacy Subject Matter Expert (SME).

The authorization package provides information on the security and privacy posture of the system. This helps the CMS CIO - Authorizing Official (AO) to make informed, risk-based decisions.

The authorization package must include: 

• System Security and Privacy Plan (SSPP), document detailed descriptions of how security and privacy controls are selected, implemented and managed for each specific CMS system. It is a living document which forms the baseline for ongoing risk management and compliance efforts.
• Security Assessment Report (SAR), details the strengths and weaknesses of implemented controls, highlights discovered issues, and recommends actions to mitigate risks or close identified gaps.
• Plans of Action and Milestones (POA&M), documents all security and privacy findings that need remediation, along with corresponding corrective actions, assigned responsibilities, and target completion dates. It ensures a structured follow-up and resolution of identified findings in compliance with CMS policies.
• CMS Information Security Risk Assessment (ISRA), document identified threats, vulnerabilities, and potential impacts within the system environment. The assessment results guide CMS in prioritizing risk responses in compliance with CMS risk management policies. 
• Privacy Impact Assessment (PIA), CMS processes Personal Identifiable Information (PII) and usually requires PIA to help determine whether privacy risks exists and if so, propose methods to mitigate them, in compliance with relevant privacy laws and regulations.
• Contingency Plan (CP), documents CMS strategy to maintain or quickly restore essential functions when faced with unexpected disruptions. It details backup procedures, alternate sites, points of contact (POC) and recovery steps to ensure continuity of operations and reduce downtime.
• Contingency Plan Exercise (often call Tabletop Exercise) captures a structured simulation in which CMS key personnel walk through the steps of the contingency plan. This enables  the discussion of roles, responsibilities and procedures. Such Tabletop exercise helps identify potential gaps or improvements that strengthen CMS’ ability to respond effectively during an actual incident.

CFACTS provides for the inclusion of an Executive Summary in submitting the Authorization Package. There may be additional documents required. However, this requirement will vary according to the individual system’s;

• Business function – What it is designed to do: to process financial or health records.
• Purpose – Storing highly sensitive or classified information.
• Environment – Where it operates: in a secure restricted space or public-facing or cloud.
• Configuration – How it is setup, including its software, hardware and network components.

CMS Ongoing Authorization (OA) program and the Federal Risk and Authorization Management Program Plan (FedRAMP) offer standardized approaches to securing Authorization Package. The CMS FISMA Continuous Tracking System (CFACTS) is the GRC tool used to track and manage the security and compliance of all CMS systems. 

TLC Cycle Phase: New – Initiate

                              Existing – Operate

Task R-2 RISK ANALYSIS AND DETERMINATION     

Analyze and determine the risk from the operation or use of the system or the provision of common controls.

Potential Inputs: 

• Authorization package consists of key documents that convey the information system's security and privacy posture to the Authorizing Official. These include System Security and Privacy Plans (SSPP); Security and Privacy Assessment Reports (SAR); and Plan of Action and Milestones (POA&M).
• Supporting assessment evidence would include Privacy Impact Assessment (PIA)
• Other documentation as required may include Contingency Plan, Contingency Plan Exercise (Tabletop Exercise)
• Information provided by the Senior Accountable Official for risk management or Risk Executive (function): CMS organizational risk is the key responsibility of these roles, so they provide guidance, analysis and information that shape how security, privacy and supply chain risks are managed at the system level, ensuring alignment with CMS overall risk tolerance, mission and strategic business objectives.
• CMS risk management strategy and risk tolerance: The risk management strategy describes how CMS identifies, evaluates and monitors risk over time to ensure overall security and compliance, while its risk tolerance defines the acceptable level of risk CMS is willing to assume in order to achieve its mission and objectives.
• CMS and system-level risk assessment results: document identified threats, vulnerabilities, and potential impacts within the system environment. These results guide CMS in prioritizing risk responses in compliance with CMS risk management policies. 

Expected Outputs: 

Risk determination: This process involves first evaluating the likelihood and potential impact of identified threats and vulnerabilities on CMS information systems and data. Secondly, deciding whether the resulting level of risk is acceptable based on CMS organizational objectives and risk tolerance. Then finally determine the appropriate risk response approach to adopt – whether to accept, mitigate, transfer or avoid.

Discussion: The CMS CIO as the Authorizing Official, in consultation with their team analyzes the relevant security and privacy information provided via CFACTS, the CMS GRC tool, to determine the current security and privacy posture of the system. 

Risk assessments through CMS Information System Risk Assessment (ISRA), provide the required information that may influence the risk analysis and determination.

The process involves:

1. To identify threats to CMS operations, assets, or individuals; or threats to other organizations or the Nation.
2. To identify any vulnerabilities internal and external to CMS.
3. To evaluate the harm or adverse impact on CMS should any of those identified threats exploit the vulnerabilities.
4. Determine the likelihood that any harm will occur.

The end result of this process is a determination of risk. It evaluates how much harm will come to CMS and the likelihood of this harm occurring.

CMS Continuous Diagnostics and Mitigation (CDM) helps strengthen the cybersecurity of government networks and systems by providing automated scanning and analysis of risks. 

The Cyber Risk Management Plan (CRMP) outlines the CMS risk management strategy:

• To assess risk
• To respond to risk
• To monitor risk over time. 

 Cybersecurity and Risk Assessment Program (CSRAP) helps evaluate the current results of all available and relevant risk information sources (RIS) and their impact on enterprise-level security capabilities.

The CMS Ongoing Authorization (OA) Program Dashboard displays the results of the data collected for defined OA metrics. The OA Program Dashboard alerts when the defined risk tolerance for an established metric has been exceeded. 

CMS also utilizes the Cyber Risk Report to communicate cyber risk metrics consistently across all Federal Information Security Management Act (FISMA) Systems.

The CMS CIO (Authorization Official) can then leverage all this information, including the authorization package provided by the CSRAP Assessment Team and the System/Business Owner to reach a determination of risk.

TLC Cycle Phase: New – Initiate

    Existing – Operate 

Task R-3 Risk Response

Identify and implement a preferred course of action in response to the risk determined.

Potential Inputs: 

• Authorization package: consists of key documents that convey the information system's security and privacy posture to the Authorizing Official. These include System Security and Privacy Plans (SSPP); Security and Privacy Assessment Reports (SAR); and Plan of Action and Milestones (POA&M).
• Risk determination: involves first evaluating the likelihood and potential impact of identified threats and vulnerabilities on CMS information systems and data. Secondly, deciding whether the resulting level of risk is acceptable based on CMS organizational objectives and risk tolerance. Then finally determine the appropriate risk response approach to adopt – whether to accept, mitigate, transfer or avoid.
• CMS and system-level risk assessment results document identified threats, vulnerabilities, and potential impacts within the system environment. These results guide CMS in prioritizing risk responses in compliance with CMS risk management policies. 

Expected Outputs: 

Risk responses for determined risks: Based on CMS organizational risk tolerance and mission objectives, the CMS CIO, as the Authorizing Official (AO) decides which risk response best applies to determined risks – accept, mitigate, transfer or avoid.

Discussion: CMS Cyber Risk Management Plan (CRMP) addresses how CMS responds once a risk determination is made. It provides a consistent, organization-wide response to risk, or risk mitigation plan, in accordance with the organizational risk frame. 

This is achieved through:

• Developing alternative courses of action for responding to risk
• Evaluating the alternative courses of action
• Determining appropriate courses of action consistent with organizational risk tolerance
• Implementing risk responses based on selected courses of action.

The CMS GRC tool, CFACTS tracks and captures the CMS programs, processes, tools, and technologies designed to identify and mitigate security and privacy risks to FISMA systems. 

The Risk Management strategy of CMS is focused on how CMS identifies, assesses, and prioritizes potential risks and then takes actions to mitigate or manage those identified risks.

There are 4 primary approaches to Risk Management:

1. Risk avoidance – if the risk is too high or the potential impact is unacceptable.
2. Risk mitigation – applying measures, controls, safeguards, or strategies to reduce risk to an acceptable level.
3. Risk transfer – shifting risk to another party, such as through insurance, outsourcing or contracts.
4. Risk acceptance – when the cost of mitigating the risk is greater than its potential impact.

If the risk response is mitigation, then the remediated findings must be re-assessed by the CSRAP Team to reflect a closed status, otherwise the finding is reflected in the POA&M.

If the risk response is acceptance, the CMS CIO as the Authorizing Official determines if the findings need to be mitigated before authorization, or not. However the decision, the findings are monitored for changes to the security risk factors – threat, vulnerability, likelihood and impact.

As part of the risk response strategy, CMS implements security controls based on an assessment of risk and local conditions, including:

• CMS-specific security requirements
• Specific threat information
• Cost-benefit analysis
• Special circumstances

 These are all documented in the SSPP.

However, it must be noted that risks are never totally eliminated:

• Residual risks – These are risks that remain after all possible risk mitigation measures and security controls have been applied. An example could be an Insider Threat within CMS, or a yet unknown cyber-attack.
• Inherited risks – These are risks from an external environment or dependencies, such as third-party systems, or underlying infrastructure.

Any remaining (residual and inherited) risks must also be documented in accordance with the current risk assessment procedure within the ISRA and approved by the CMS CIO - Authorizing Official (AO) using appropriate policy waiver mechanisms.

Cybersecurity Framework: ID.RA-6

 TLC Cycle Phase: New – Initiate

    Existing – Operate

Task R-4 Authorization Decision 

Determine if the risk from the operation or use of the information system or the provision or use of common controls is acceptable.

Potential Inputs: 

Risk responses for determined risks: Based on CMS organizational risk tolerance and mission objectives, the CMS CIO, as the Authorizing Official (AO) decides which risk response best applies to determined risks – accept, mitigate, transfer or avoid.

Expected Outputs: 

• Authorization to Operate (ATO) - The formal decision granted by the CMS CIO, as the Authorizing Official (AO), allowing any CMS information system to operate within CMS organization. This is based on an evaluation of the system’s security and privacy controls, ensuring that the associated risks are within acceptable levels and that the system complies with CMS organizational and regulatory requirements. The ATO is for a specified period and requires continuous monitoring to ensure compliance is maintained.
• Authorization to Use – The CMS CIO as AO can also grant a formal decision allowing the use of an external system, service, or solution (cloud-based service) not directly owned or managed by CMS. This will also be based on the evaluation of the external provider’s security and privacy posture to ensure it meets CMS organizational requirements and aligns with acceptable risk levels. Continuous monitoring and periodic reviews are also required to maintain compliance.
• Common Control Authorization – A formal decision granting approval for controls shared across multiple systems, after evaluating and confirming that their security and privacy posture meets CMS organizational requirements. Regular monitoring ensures common controls remain effective and meet evolving requirements.
• Denial of Authorization to Operate – The formal decision by the AO that an information system is not permitted to operate in CMS. This usually indicates that the security and privacy posture of the system cannot adequately protect CMS organizational assets or comply with regulatory requirements.
• Denial of Authorization to Use – When an external system, service or solution fails to meet CMS security, privacy and compliance requirements, thereby posing unacceptable risks to the organization, the CMS CIO, as AO, issues a formal decision that such external system, service or solution is not permitted for use in CMS environment.
• Denial of Common Control Authorization – When a common control is evaluated and found to be deficient or pose unacceptable risks to CMS systems, the CMS CIO, as AO, issues a formal decision that such common control is not permitted to be shared across multiple CMS systems.

Discussion: The CMS CIO as the Authorizing Official is responsible for accepting risk and this responsibility cannot be given to anyone else within CMS. Every information system used in a CMS production environment must have an approved ATO signed by the CMS CIO as the Authorizing Official.

To get an approved ATO, the Business/System Owner and other stakeholders must test the system, document its requirements, and include this information in the authorization package.

This package should show the latest details about the system, its environment, and how well the security controls work, including any weaknesses, to prove the system meets federal requirements. 

With all documentation and assessments completed and uploaded to CFACTS, the Security and Privacy Officer (previously known as the ISSO) requests an ATO certification. 

The complete ATO package is reviewed by the System Developer Maintainer (SDM), Cyber Risk Advisor (CRA), Security and Privacy Officer (previously known as the ISSO), Business/System Owner, Privacy Subject Matter Expert (PSME) and ISPG. 

Once the review is completed and approved, the package is submitted to the CISO and then to the CMS CIO for final approval.

The CMS CIO as the Authorizing Official, equipped with the required information and in consultation with his team – CMS Chief Information Systems Officer (CISO) and CMS Senior Official for Privacy (SOP) makes a risk-based decision to either grant or deny the ATO.

The ATO usually is for a duration of 3 years, except in cases where there’s a major change in the system. See link for more details.

A change is deemed as major if it is likely to substantively affect the security and privacy posture of the system, such as:

• An upgrade in hardware or software applications.
• Changes in the information collected by the system.
• Changes in how the information is handled or processed.
• Changes to system ports or services.
• A security breach incident where unauthorized users gained access to sensitive data. 

In any of the above listed cases, the system would require a reassessment and reauthorization. See link for more on reauthorization.

To remain compliant with the ATO, the Business/System Owner maintains the Target Life Cycle (TLC) System Profile with every production release, and ensures the security posture of the system is sound by completing annual security requirements, such as: 

• Control assessments
• Penetration tests, and
• Annual recertification. 

The Security and Privacy Officer (previously known as the ISSO) ensures that all documentation for the system is updated and current.

Cybersecurity Framework: N/A

TLC Cycle Phase: New – Initiate

    Existing – Operate

Task R-5 Authorization Reporting 

Report the authorization decision and any deficiencies in controls that represent significant security or privacy risk. 

Potential Inputs: 

Authorization decision: A formal determination made by the CMS CIO as the Authorizing Official (AO), regarding whether or not, an information system, external service, or common control is approved to operate or be used within CMS organization. A decision usually based on an evaluation of their security and privacy posture, associated risks, and compliance with CMS organizational and regulatory requirements.

Expected Outputs: 

• A report indicating the authorization decision for a system or set of common controls: The Authorization Decision Report issued by the CMS CIO, as Authorizing Official (AO) communicates their decision regarding the authorization of a system or set of common controls. It serves as the official record of the system or common control’s security and privacy posture, along with their associated risks. It is generated, captured and tracked on CFACTS.
• Annotation of authorization status in the organizational system registry: Within CMS, this is captured on CFACTS, where each system’s current authorization status is tracked, and clearly communicated, for governance, compliance and monitoring purposes.

Discussion: CFACTS, the CMS GRC tool tracks and manages the entire process of the RMF. 

The Authorization decision requires the signature of the CMS CIO, which validates it as an official document. It also generates a report on CFACTS with:

• Information about the system or common controls
• Exploitable deficiencies (vulnerabilities) in the system or common controls
• Significant security or privacy risks.

The CMS CIO authorization decision report allows CMS senior management to have a clear view of the security and privacy posture of each system across CMS. 

This report also helps the individual risk-based decisions about systems and common controls taken by officials such as Risk Executive [Function], Cyber Risk Advisor, System/Business Owner and Common Control Providers toward making CMS a more secure organization.

Authorization decisions are tracked on CFACTS and may be reflected as part of CMS system registration process during the Prepare Step - Task 18 (System Registration), allowing management to make better budget and resource decisions.

Cybersecurity Framework: N/A

TLC Cycle Phase: New – Initiate

    Existing – Operate