Skip to main content

CMS ATO Notice

CMS ATO information can now be found at security.cms.gov, along with other security and privacy resources.

This website will be retired. You will be redirected in a moment.

Develop and Assess

Overview

The Develop and Access phase creates user stories or requirements, designs and develops the solution, deploys to a non-production environment, and tests for compliance with the requirements and CMS standards so that it is production-ready.

This is when the system is actually built, deployed and assessed for security and compliance. This includes documenting all controls and implementing necessary controls, finalizing required Artifacts and supplemental documentation, and completing testing and assessments.

This phase of the CMS Target Life Cyle (TLC) framework is document heavy and requires inputs from many stakeholders. To minimize costly delays, each project should have a communication plan in place to ensure all parties are in the loop throughout the process. The plan should include all relevant points of contact, including:

  • Information System Security Officer (ISSO)
  • ISSO Contracting Support (ISSOCS)
  • Cyber Risk Advisor (CRA)
  • Business Owner (BO)
  • Penetration (Pen) Test Coordinator
  • Information Security and Privacy Group (ISPG) Adaptive Capabilities Testing (ACT) team
  • System Developer and Maintainer (SDM)
  • Privacy Subject Matter Expert (PSME)
  • Technical Review Board (TRB)

Design, Develop & Deploy

Design and development is managed by the BO and project team. The TLC requires only a small set of artifacts, and specific methodologies are determined by the BO and team. All initiatives should follow best practices in development and Program Management. Typically, the project team will work with the CMS Cloud Services team to provision the different environments, such as development, implementation and production. As the system is developed, the project team should also move forward with documentation and other compliance activities.

Once the system is designed and developed, it is deployed in a non-production environment. It is tested for compliance with requirements and CMS standards. Everything must all comply with CMS Technical Reference Architecture (TRA) and meet security, privacy and accessibility standards before it is production ready. For more information, see the CMS Acceptable Risk Safeguards (ARS).

Define the Accreditation Boundary

When defining the accreditation boundary, the CMS cloud service provider provides and supports assets. Additionally, the Application Developer Owner (ADO) provides and supports components. Each project team is responsible for maintaining those assets within the accreditation boundary

The ISSO works with the project team to define the boundary according to the CMS TRB three tier architecture. If the system is hosted in the CMS Amazon Web Service (AWS) cloud GSS, it can access and use approved templates to simplify the process

Implement Controls

The Accreditation Boundary creates an inventory of all system components that will require security controls. A system may be able to inherit controls based on its hosting, platform, data center, and other variables, which can greatly ease the process. With the boundary established, the ISSO will start documenting all ARS 3.1 security controls in CFACTS, starting with any inheritable controls available.

Implementing controls often involves conversations between the ISSO and project team, especially technical stakeholders, as well as a CRA. To minimize back-and-forth, all relevant stakeholders should be engaged and prepared to participate.

System Test Development

With all components documented and controls in CFACTS, it’s time for a system test. The purpose of a system test is to evaluate the end‐to‐end system specifications. This test validates the complete and fully integrated software product, and involves the full project team.

Onboarding to Continuous Diagnostics and Mitigation (CDM) 

The Cybersecurity and Infrastructure Security Agency (CISA) works with partners across government and the private sector to secure national infrastructure. A big part of this effort—the Continuous Diagnostics and Mitigation (CDM) program—is strengthening the cybersecurity of federal networks and systems.

As part of the ATO process, the ISSO onboards each system to CDM through three stages:

  • Stage 1: Engage Data Center assessment
  • Stage 2: Implement and integrate required capabilities
  • Stage 3: Validate and verify data

The system is also onboarded to the CMS Cloud Environment for cloud hosting (if applicable), and the CMS Security Operation Center (CCIC) for security monitoring, event management and incident handling.

Complete Tier 1-3 Artifacts

As seen in the Initiate Phase, all systems require Tier 1 Artifacts. Based on the boundary and controls, they may also require additional documentation. The project team should work with their ISSO and CRA to determine which documentation is required for their system and upload it to CFACTS.

Readiness Review

Once all controls, Artifacts and additional documentation are in CFACTS, the ISSO and project team will review the information before the project formally moves to the assessment phase. The ISSO and project team set the timing for the required PenTest and ACT, the ISSO reaches out to the PenTest mailbox and the ACT mailbox to schedule the assessments. As the team works, the timeline and schedule should be shared with the CRA.

PenTest

A PenTest helps determine the security of a system by attempting to exploit vulnerabilities. To start the process: 

  1. The ISSO emails the PenTest mailbox to request an intake form and schedule a test.
  2. The PenTest coordinator will work with the ISSO and project team to fill out the intake form. 
  3. The PenTest team will then arrange a meeting to discuss the process and inform the ISSO and Business Owner of what to expect.

After the test: 

  1. The PenTest team will notify the project team of any issues.
  2. The team mitigates the issues within 25 days. If an issue is not sufficiently resolved/mitigated within the 25-day window, the team is issued a Plan of Action and Milestones (POA&Ms) to manage it.
  3. When the test results are finalized, the PenTest team uploads a completed CAAT spreadsheet to CFACTS and notifies all parties. 
  4. The CISO mailbox is also notified that the CAAT spreadsheet is complete and available on CFACTS.

To avoid delays, the project should contact a PenTest Coordinator to request the assessment at least 3 months before the ATO deadline.

Adaptive Capabilities Testing (ACT)

The ACT program was created to improve the Security Controls Assessment (SCA) process by introducing risk-based security assessment for CMS systems. Instead of emphasizing technical findings and compliance with Controls (which are still important), ACT facilitates and encourages risk-based decision making.

ACT focuses on the Core Controls that pose the highest risk to CMS and defines mission-oriented security objectives. ACT reports incorporate plain language, relevant findings and actionable results and conclusions to aid project teams’ risk-based decision making. Read more about ACT.

To fulfill the ACT requirement, the ISSO emails the ACT mailbox to request an intake form. The lSSO works with the project team to complete the intake form and with the ACT team to create and complete an assessment plan. Once it is complete, the ACT Final Package will also be uploaded to CFACTS.

The project team should also reach out to the ACT team at least 3 months before the ATO deadline to schedule an ACT assessment.

508 Compliance

Section 508 of the Rehabilitation Act requires all federal systems to be accessible to people with disabilities. To ensure the system is accessible to all users, the project team should consider 508 accessibility compliance throughout design, development and deployment. Before approval, the system is required to meet all applicable 508 guidelines.

Managing Identified Risks

All information systems include some level of risk. An ATO is designed to document and manage risk, not eliminate it. Once the PenTest and ACT assessment identify risks, the ISSO will work with the project team and CRA to create a Plan of Action and Milestones (POA&M).

POA&Ms

Plan of Action and Milestones (POA&Ms) are high-level statements that describe how a team will address security weaknesses identified for their system. All federal systems must document POA&Ms to track and mitigate findings identified during the PenTest and ACT assessment process. As indicated in the name, a POA&M includes a plan, the resources needed to accomplish the plan, milestones, and scheduled completion dates. For example, a POA&M to mitigate a vulnerability could be: 

  1. Contact the vendor 
  2. Download the patch 
  3. Apply the patch in the next maintenance window.

The ISSO coordinates with the team to manage, remediate, and (if necessary) accept the risk of open POA&Ms.

ATO Review and Certification

With all aforementioned documentation and assessments completed and uploaded to CFACTS, the ISSO can now complete an ATO Certification Form. The form is submitted through ServiceNow, a tool that manages the tracking and approval for all relevant stakeholders. The CRA initiates the process for the CRA to create the ATO.

The complete ATO package is reviewed by the CRA, ISSO, BO and ISPG. Once approved by ISPG, the package is submitted to the CISO and CIO for final approval. Once approved by the CISO and CIO, an ATO letter is sent to the BO and ISSO. The CRA uploads the approved ATO package to CFACTS and notifies all relevant parties, including FedRAMP. 

The system now officially has an ATO—” the authority to operate decision that culminates from the security authorization process of an information technology system in the US federal government." With a completed and approved ATO, the system officially moves into the Operate Phase of the TLC.