Authorizations & Agreements
Every system that is integrated at CMS—either built in-house or contracted—must get a compliance authorization to operate and access government data. This ensures that the agency is aware of all components interacting with its data, and that each system can be monitored for compliance and risk mitigation. This helps safeguard sensitive personal information, manage the risk to critical infrastructure, and address cybersecurity issues when they arise.
If you are introducing a new system at CMS, you must go through the security and compliance process.
CMS also knows that every system is unique and that a one-size-fits-all approach won’t work. This page outlines the different types of compliance authorizations provided by CMS to manage agency-wide risk.
Authority to Operate (ATO)
The Authority to Operate (ATO) is awarded by the CMS Authorization Official (AO) to systems that meet requisite security requirements. Typically, ATOs grant a system compliance for 3-years, although there are circumstances where CMS will authorize a system for a shorter period of time (see more information about this below).
Why get an ATO?
Information systems that intend to operate for 3 years or more are required to get an ATO. This includes projects that:
- Store, process, and distribute Personally Identifiable Information (PII), Personal Health Information (PHI), or other sensitive information
- Have been reviewed and approved through the existing CMS governance process (EASi)
- Have funding and contracting vehicles to develop, implement and maintain a FISMA information system
To receive an ATO, the system's authorization package must include all (or almost all) control documentation requirements and assessment results, including:
- All core security documentation
- Most (if not all) findings from Penetration Testing (PenTest) and Adaptive Capability Testing (ACT) have been identified, documented and remediated
Before approval, the system's Cyber Risk Advisor (CRA) will present a high-level executive summary to the AO in an official approval meeting. They explain the completed tasks and any residual risk presented by the system. For the AO to provide a 3-year ATO, the residual risk must be minimal. Things they look to confirm before approval:
- Most control assessment statuses are "Satisfied" in the CMS FISMA Controls Tracking System (CFACTS)
- CMS and the Department of Health and Human Services (HHS) have approved the Privacy Impact Assessment (PIA)
- Core documentation such as the System Security Plan (SSP), Risk Assessment (RA), Contingency Planning (CP), CP test, and ACT PIA are up to date
- All (or almost all) Plans of Action and Milestones (POA&Ms) have been remediated (a few low POA&Ms may still remain)
- The POA&Ms summary shows remediation from several sources, such as Security Controls Assessment (SCA), ACT, PenTest, etc.
- The ongoing POA&Ms summary status should be at minimum risk (typically 0)
- No critical or high risks have a status of ongoing or delayed (though a few low risks may have an ongoing or delayed status)
In some cases the AO is not able to issue a full ATO, but there is still reason to allow the system to operate while security issues are being resolved—typically for up to one year. Temporary inhibitors often include:
- Security patches are not available from the vendor yet
- Challenges with modernization such as transition to the cloud issues
- Funding issues such as contracting transition or awaiting for more resources
Why get a Temporary ATO?
If critical issues or risks are identified during Penetration Testing and/or Adaptive Capabilities Testing (ACT), the Authorizing Official (AO) may choose to issue a Temporary ATO to allow a system to operate while the team addresses the issues. These often include critical, high or moderate findings identified by assessments, and remediation challenges. Typically, a Temporary ATO lasts 6-12 months.
In this scenario, the CRA will present the residual risk to the AO and—depending on the criticality of the risks and the time to remediate—the AO can provide a limited time for the project team to address the findings. Once addressed, assessors must retest to ensure the findings are mitigated.
Once the temporary ATO expires, the project team will update their mitigation efforts and work with the CRA to present for a second authorization. If the system risk has been sufficiently addressed, the AO can then issue a full ATO.
Ongoing Authorization to Operate (OATO)
The Ongoing Authorization to Operate (OATO) is a new initiative at CMS. Its goal is to fundamentally change authorization and compliance from a reactive evaluation to proactive, ongoing monitoring. The OATO framework is currently a work in progress and the process and criteria to onboard systems has not been created yet.
To be eligible for OATO, systems must leverage the latest control automation tools, including the Security Automation Framework (SAF). All CDM tools must be implemented and tracking the system's hardware (HWAM), software (SWAM), and vulnerability (VUL).
Why get an OATO?
Rather than subjecting project teams to the current 3-year compliance cycle, the OATO will provide CMS real-time data about a system’s security posture. This will reduce the load on BOs and project teams, and give CMS a clearer picture of its risk level at a given moment.
Advantages of OATO include:
- Removing the three-year ATO cycle burden
- New capabilities and increased visibility into Federal Information Security Management Act (FISMA) systems for near “real-time” risk analysis
- Improved risk metric reports through automation and on demand dashboards
- Empowering the Business Owner (BO) and Information System Security Officer (ISSO) with control of their data and risk management
- Improving overall risk posture of the FISMA system and ultimately the agency
- Automates the collection and dissemination of data
The first iteration of OATO will focus only on systems in the CMS Amazon Web Services (AWS) cloud enclave that meet the following criteria:
- System must be fully cloud hosted — no hybrids
- Security Hub (SecHub) must be enabled
- Key CDM data feeds must be integrated into CDM architecture (HWAM, SWAM, VUL)
- Data needs to be integrated into requisite reporting mechanisms and made visible
- System must meet metrics baseline requirements
OATO is in the process of being developed and implemented. Stay tuned for news and updates about the initiative.
Authority to Pilot
CMS takes cyber security and compliance very seriously. However, the agency also recognizes that the ATO process requires resources and could stifle innovation—or worse, incentivize noncompliance. To encourage innovation, experimentation and compliance, CMS recently introduced the Authority to Pilot (ATP) program to allow Business Owners to test a solution before getting an ATO.
The goal of ATP is to help the CMS Information Security and Privacy Group (ISPG) collect as much risk maturity information about the system from the BO as possible. To do so, the BO works with ISPG to complete a risk assessment. Based on the results and a letter of intent, the AO can provide a very short amount of time for the BO to test-run the system.
Why get an ATP?
A Business Owner may want to understand the value of a new tool or product before moving forward with an ATO. An ATP allows the project team to do some temporary testing before seeking a full authorization. To minimize risk, ATP candidates are encouraged not to include Personally Identifiable Information (PII), Personal Health Information (PHI) or sensitive information in their pilot.
The ATP initiative is gaining maturity. However, now every applicant is tested and assessed on a case-by-case basis. To provide much needed clarity and direction to customers, ISPG is creating a formal policy, standards and guidelines for the ATP program. Additionally, due to inherent risk, solutions that will host PII and/or PHI are unlikely to receive an ATP.
Risk-Based Determinations (RBD)
When assessors determine a system has an unacceptable amount of risk, they identify and share findings with the ISSO and BO. The ISSO and BO review the findings, and once accepted a POA&M is created to remediate the risk. The ISSO and project teams are responsible for documenting milestones for each POA&M—high level statements that describe how the project team will mitigate the finding.
Why get a RBD?
For many reasons, sometimes it is difficult for a system to complete the POA&M completely. To address these situations and allow the system to operate, CMS has the RBD process.
Once a finding from an assessment becomes a POA&M, the project team must describe how they are going to mitigate it. RBDs allow ISSOs and BOs to present some level of risk management when POA&Ms can't be remediated completely. This only applies to POA&Ms that cannot be remediated due to technology or funding limitations.
The RBD describes the business and technical challenges preventing the closing of the POA&M. It also includes other compensating controls to help reduce the risk, if applicable.
After being documented in CFACTs by the ISSO and signed by the BO, the RBD is sent to the CRA to present to the AO. Once the AO approves the RBD, the ISSO uploads it to each open POA&M, regardless of their status.
ISA and MOU Agreements
Many systems share data with other systems within CMS and across different agencies. To safeguard the data they communicate, it often makes sense for connected systems to enter into security agreements.
Why get an MOU or ISA?
The Interconnection Security Agreement (ISA) and the Memorandum of Understanding (MOU) are the two most used agreements at CMS. These high-level agreements support the best security posture to protect the data shared by systems across organizations.
The agreements, provided by CMS as templates, are used to ensure the CMS data is protected. They are not legal documents, but they can't be altered without the approval of CMS legal counsel. Both templates are similar—the difference between the two is that the MOU is used between two or more systems approved under the same AO at CMS. An ISA requires the approval of the CMS AO and the AO of the other organization(s).
Once all parties sign the agreements, the CRA for the system presents the documents to the AO for approval. Once approved, the agreement is uploaded to CFACTS.
A system may need to be reassessed and re-authorized if the application team is planning to make significant changes, including but not limited to:
- System security boundary
- Encryption methodologies
- Administrative functionality within the application
- The kinds of information you store (for example, PII))
- The external services used or how/what data flows to/from them
Example changes that do not require re-authorization, as long as they don’t include the above:
- Features and functionality
- Bug fixes
- Interface changes
- Documentation updates
Why get a Re-Authorization?
If a change to a system is significant (see above), the entire system must be reassessed and reauthorized.
The project completes a system impact assessment to determine the level of change. If the change is significant, the team schedules an ACT assessment to determine if there are any potential findings. If there are findings, the team works to mitigate them (see ATO Process above).
Once findings are mitigated to an acceptable level, the CRA presents the case for the Re-Authorization to the BO for a new ATO letter.
If you’re planning a change that you think may require re-authorization, please contact the Authorizing Official.