Skip to main content

CMS Risk Management Framework (RMF): Authorize Step

Determine if the security and privacy risks are acceptable for the system to be authorized to operate

Last reviewed: 12/5/2024

Contact: ISPG Policy Team | CISO@cms.hhs.gov

Related Resources

CMS Risk Management Framework (RMF)
National Institute of Standards and Technology (NIST)

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:

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.

System Level Authorize Tasks

System level Authorize tasks also take into consideration mission/business process concerns.

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:

  • security and privacy plans
  • security and privacy assessment reports
  • plan of action and milestones (POA&M)
  • supporting assessment evidence or other documentation, as required

Expected Outputs:

  • Authorization package (usually with an executive summary), generated on CFACTS, the CMS GRC tool, is 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 will assemble, review and submit the Authorization Package to the CMS CIO - Authorizing Official (AO), in consultation with other members of their team. That team includes but is not limited to the Security and Privacy Officer (formerly known as ISSO), System Developer Maintainer, Cyber Risk Advisor and Privacy SME.

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

The authorization package must include:

The required documentation may also include additional documents. This will vary according to the business functions, purpose, environment and configuration of the individual system.

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. Within CFACTS, there’s provision for Executive Summary in this process.

TLC Cycle Phase:

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
  • supporting assessment evidence or other documentation as required
  • information provided by the senior accountable official for risk management or risk executive (function)
  • organizational risk management strategy and risk tolerance
  • organization- and system-level risk assessment results

Expected Outputs:

  • Risk determination

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 ISRA provide the required information that may influence the risk analysis and determination.

This risk analysis will seek to identify threats to CMS operations, assets, or individuals, or threats to other organizations or the Nation. It will identify any vulnerabilities internal and external to CMS, and evaluate the harm or adverse impact on CMS should any of those identified threats exploit the vulnerabilities, and finally, the likelihood that any harm will occur.

The end result is a determination of risk, which typically is a function of the degree of harm or adverse impact to CMS, and the likelihood of it 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: assess risk, respond to risk and monitor risk over time. The Plan helps establish objectives to support that strategy, establish a program that aligns the processes, data, programs, technologies, and services with the risk management strategy to accomplish the objectives.

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:

Task R-3: Risk response

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

Potential Inputs:

  • authorization package
  • risk determination
  • organization- and system-level risk assessment results

Expected Outputs:

  • Risk responses for determined risks

Discussion:

The risk response component of the CMS 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 framework.

This is achieved through:

  1. developing alternative courses of action for responding to risk
  2. evaluating the alternative courses of action
  3. determining appropriate courses of action consistent with organizational risk tolerance
  4. implementing risk responses based on selected courses of action

With CFACTS, the CMS GRC tool, a standardized framework made up of programs, processes, tools, and technologies designed to identify and mitigate security and privacy risks to FISMA systems is well captured. 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.

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. Whatever 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, 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, and are documented in the SSPP.

Any remaining (residual and inherited) risks must 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:

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

Expected Outputs:

  • Authorization to operate (ATO)
  • Authorization to use
  • Common control authorization
  • OR denial of authorization to operate, denial of authorization to use, denial of common control authorization

Discussion:

The explicit acceptance of risk is the responsibility of the CMS CIO, the Authorizing Official and cannot be delegated to other officials within CMS. Every information system operated in a CMS production environment must have an approved ATO signed by the CMS CIO, the Authorizing Official.

For a system to have an approved ATO, the Business or System Owner and other stakeholders must go through the process of testing and documenting the system's requirements in the artifacts supporting the authorization packages that convey the most recent information about the system, the system environment, and the effectiveness of all assessed implemented controls, with their potential deficiencies to demonstrate the system’s compliance with 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 following: 

  • System Developer Maintainer (SDM)
  • Cyber Risk Advisor (CRA)
  • Security and Privacy Officer (previously known as the ISSO)
  • Business or System Owner
  • Privacy Subject Matter Expert (PSME)
  • CMS Information Security and Privacy Group (ISPG)

Once the review is completed and approved, the package is submitted to the CISO and then 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 Security 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. In such a case, the system would require a reauthorization.

To remain compliant with the ATO, the Business or System Owner maintains the Target Life Cycle (TLC) System Profile with every production release. Annual security requirements such as control assessments, pen tests, and annual recertification are completed to ensure the security posture of the system is sound.

The Security and Privacy Officer ensures that all documentation for the system is updated and current.

Cybersecurity Framework: N/A

TLC Cycle Phase:

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

Expected Outputs:

  • A report indicating the authorization decision for a system or set of common controls
  • Annotation of authorization status in the organizational system registry

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, validating it as an official document. It also generates a report on CFACTS with all the required information about the system or common controls; exploitable deficiencies (vulnerabilities) in the system or controls which represent 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 all applications and systems across CMS. This knowledge and awareness support the individual risk-based decisions about systems and common controls in the roles and responsibilities of officials such as Risk Executive [Function], Cyber Risk Advisor, System or Business Owner and Common Control Providers toward a more secure CMS as an 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: