Authorization to Operate (ATO)

What is ATO?

Every information system operated by or on behalf of the U.S federal government is required to meet FISMA standards, which includes system authorization (ATO) signed by an Authorizing Official (AO). This means that before a system can be deployed into production at CMS, the Business Owner and other stakeholders must go through the process of testing and documenting the system’s security to demonstrate its compliance with federal requirements.

When this process is successfully completed, an Authorization to Operate (ATO) is signed and the system can be utilized at CMS. However, the ATO process requires months of planning, scheduling, testing, documenting, and collaborating with various individuals and groups across CMS – so you should start working on your ATO as soon as possible.

What is the ATO process?

The ATO process is built around the Risk Management Framework from the National Institute of Standards and Technology (NIST). This framework is based on the idea that no system is ever 100% secure – risk is always present and evolving. So the best practice is to take a risk-based approach to system security, as laid out in the NIST Risk Management Framework (and reflected in the ATO process):

• Prepare: Perform essential activities to prepare the organization to manage security and privacy risks
• Categorize: Categorize the system and information processed, stored, and transmitted based on an impact analysis
• Select: Select the set of NIST SP 800-53 controls to protect the system based on risk assessment(s)
• Implement: Implement the controls and document how the controls are deployed
• Assess: Assess to determine if the controls are in place, operating as intended, and producing the desired results
• Authorize: Senior official makes a risk-based decision to authorize the system (to operate)
• Monitor: Continuously monitor control implementation and risks to the system

When this process is followed for every information system, CMS can track and manage the risk exposure of individual systems and the agency at large – ensuring the protection of critical resources and sensitive information.

However, this is a complex and documentation-heavy process that spans the whole life cycle of a FISMA system. It can be challenging to keep in mind the specific steps that need to be taken in order to obtain and maintain ATO.

ATO and your system’s life cycle

The ATO process can be mapped to the System Development Life Cycle (SDLC) so that it’s easier to see what activities should be completed at each stage. At CMS, this means the steps will align to the Target Life Cycle (TLC) – the system development governance process that all CMS systems must follow. These phases are briefly summarized below, with links to details that will help you plan ATO activities for your system’s whole life cycle.

Initiate

When a business need prompts the idea for a new system (or significant enhancements to a system) at CMS, the Business Owner and other key stakeholders must follow a governance process that makes use of existing resources and ensures the security of CMS information and systems. The first steps of the Initiate phase include documenting the business need and determining if a new system actually needs to be developed.

Document the business need

All new business needs and material changes to existing systems must be documented in the Initiate phase. During this period, the Business Owner will talk with knowledgeable stakeholders to learn about CMS infrastructure and existing assets. Together they will define and document the general business need or desired enhancement and explore solution options. These stakeholders often include:

• Information Security and Privacy Group (ISPG)
• Office of Acquisition and Grants Management (OAGM)
• Governance Review Team (GRT)
• Governance Review Board (GRB)
• Office of Information Technology (OIT) Navigators
• Enterprise Architecture (EA) Team
• Technical Review Board (TRB)
• Office of Financial Management (OFM)
• Section 508 Team
• Various Subject Matter Experts (SMEs)

Consider existing options

An important step in the governance process is to consider existing solution options at CMS to determine whether a new system is indeed necessary. In particular, cloud computing options should be considered, such as Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), and Infrastructure-as-a-Service (IaaS). CMS has a variety of cloud offerings available that help save time and money on development, compliance, and security. If an existing solution at CMS or HHS can be leveraged, there is no reason to duplicate efforts by developing a new system.

Decide to proceed with a new system

If no solution exists to meet the need, the Business Owner and stakeholders will move forward with the governance process for a new system, receive a Life Cycle ID, and then follow the ATO process. The governance team can help the Business Owner with basic funding and contracting needs. ISPG leadership assigns a Cyber Risk Advisor (CRA) based on the CMS component organization the system will fall under, and the Business Owner appoints an Information System Security Officer (ISSO). ISPG also assigns a Privacy SME to each project to support privacy related considerations.

Getting started

Once the decision is made to develop a new system, intake and other foundational activities will start. This phase requires meetings with various groups across CMS to ensure that resources are used efficiently, governance processes are followed, and security requirements are met.

Determine a hosting solution

It is important to decide on the primary hosting location for the solution. Hosting the solution within CMS – for example, using CMS Cloud Services – instead of using vendor provided hosting locations is much preferred. Leveraging CMS hosting allows the team to access a wide variety of services from CMS. This saves time and money on compliance, so they don't have to worry about reducing cost on implementation to stay on budget. This should be the primary goal at this point in the process.

Complete Appendix A

To ensure that the contract for developing a new system includes the appropriate security measures, the system stakeholders (such as the Business Owner, Privacy SME, ISSO, and CRA) must complete the document CMS Security and Privacy Requirements for IT Procurements.These standards help government agencies protect all of their assets from security threats and privacy risks, especially when the assets will be managed by third-party organizations. Part of this process includes completing "Appendix A" of this document, which is signed by the CMS Chief Information Security Officer (CISO) and the CMS Senior Official for Privacy (SOP).

Learn more about security and privacy requirements for CMS technology procurements here.

Complete EASi intake form

If you decide to create a new solution at CMS, the Easy Access to System Information (EASi) system helps you get started by automating the governance process and connecting you and your contract to funding at CMS. The Business Owner submits an intake form in EASi to start the governance process and get a Life Cycle ID for their system. This is required for every CMS system, and key to securing funding for a new project.

Consult with Governance Review Team (GRT)

Submitting the intake form engages the Governance Review Team (GRT), who works with the Business Owner, the Enterprise Architecture (EA) team, and SMEs to create a business case for their system. The resulting case includes pros, cons, and alternative options. If the Business Owner decides to move forward with pursuing an ATO for a new system, this iterative and collaborative process should result in a strong business case to present to the Governance Review Board (GRB).

Present to the Governance Review Board (GRB)

Once they have settled on a direction for their system, the Business Owner and/or their Navigator present their case. The presentation is reviewed by relevant SMEs followed by the GRB itself, which issues an assessment and provides one or more options for the Business Owner to pursue.

Complete Enterprise Architecture Activities

Once the Business Owner selects their chosen path forward, they will work with Enterprise Architecture (EA) to complete a Core System Information Form. EA will then issue a Universally Unique Identification (UUID) number, which allows the project to be entered into the CMS FISMA Continuous Tracking System (CFACTS). The Life Cycle ID and UUID numbers will remain associated with the project for the duration of its life cycle.

Creating an Authorization Package

After the initial consultations and intake processes, the focus turns to Assessment and Authorization activities – the security-related steps required for ATO. An Authorization Package is the collection of documentation put together by the Business Owner and their team to prove that the system has been designed, built, tested, assessed, and categorized appropriately to meet ATO requirements.

As you might imagine, collecting and submitting all required information can take a lot of time and resources. To avoid delays in your development process, it is important to start collecting your system documentation as soon as possible.

Use CFACTS to track compliance

The CMS FISMA Continuous Tracking System (CFACTS) is the tool used to track and manage the security and compliance of all CMS systems. Upon receipt of the UID number from Enterprise Architecture, ISPG enters the new system into CFACTS. To access CFACTS, each user will need the CFACTS_USER_P job code from CMS. From this point on, the Business Owner and their team work together with various stakeholders to complete the required ATO documentation in CFACTS. Once all the documentation is compiled, the ISSO submits the CMS System ATO Request Form, which is filled out and submitted within CFACTS. (This form can also be used to request "re-authorization" for a system that is not a new system. ATOs need to be renewed every 3 years, or when the system undergoes a major change.)

Compile Tier 1 Documentation

The specific documents required are based on many factors and vary from system to system, but all projects should expect to provide the following Tier 1 Documentation:

• System Security and Privacy Plan (SSPP)
• Information Security Risk Assessment (ISRA)
• Privacy Impact Assessment (PIA)
• Contingency Plan (CP)
• Contingency Plan Exercise(often called Tabletop Exercise)

Compile additional documentation

Additional documentation that is often required includes:

• Project management personnel and policies
• Security and privacy documentation
• Risk assessment and abatement
• Architecture diagrams
• Hardware and software inventories
• Vulnerability scanning documentation
• Open Plan of Action & Milestones (PO&AMs)
• ISSO Appointment Letter
• TRB Letter
• Configuration Management
• Baseline security configurations
• Configuration compliance audits policies
• Maintenance and update policies
• Compliance monitoring tool output
• Malware protection
• User ID conventions, group membership, and information system accounts for each component
• Audit documentation
• System procedures manual
• Job descriptions and personnel policies
• Physical access and remote work policies
• Data Use and Service Level Agreements
• Source code
• And others

Categorization, boundary, and controls

During the documentation process described above, the team will add all required information into CFACTS and work together to categorize the system, document the system boundary, and assign appropriate security controls. These activities formally define what kind of information the system handles, the level of risk associated with the system, and what kind of controls are necessary to manage that risk.

Categorize the system

“System categorization” is a required step for every information system with an ATO. The team will classify the system into one of three levels that represent the potential impact to organizations and individuals in the case of a security breach.

At the end of this process, the system will be categorized as either High, Moderate, or Low risk according to the Federal Information Processing Standards (FIPS) Publication 199. This will determine the required controls. In particular, this will also determine whether the system should be classified as a High Value Asset (HVA) System. HVAs require additional security measures due to their unique risks.

Document the system boundary

Next, the team will document the system architecture, components and boundary in CFACTS. The boundary separates what is part of the system from what is not. It is documented through network diagrams, hardware / software inventories, and narrative explanation.

Including a good boundary diagram makes assessments easier and expedites the ATO process. It should include information about what your team is directly responsible for building and maintaining – in addition to anything your system is connected to (or utilizing) that someone else is responsible for building and maintaining.

A boundary diagram should:

• Include CMS shared services and how they connect to your system
• Show proxy - URL Filtering and whitelisting outbound traffic
• Separate S3 buckets for each Subnet
• Display zonal VRF between VDCs and AWS
• Include API Consumers internal access path(s)
• Depict all AWS Services being used

If your team has questions about this, email the Technical Review Board at cms-trb@cms.

Assign a control baseline

Based on the impact categorization from the information provided, the system is assigned a baseline of controls—Low, Moderate, or High. These controls follow the CMS Acceptable Risk Safeguards (ARS), which are the standards and controls for information security and privacy applied to CMS systems to mitigate risk. The ISSO and project team will provide implementation details for each control in CFACTS. This often includes some back-and-forth between the development team, the ISSO, and the CRA as the artifacts are reviewed and accepted.

Develop and Assess

This phase is when the system is actually being designed, built, and deployed – using the requirements and user stories that will ensure the system meets business needs. At this point the system will be in a non-production environment, meaning it is not being formally used for its intended purpose yet (and is not publicly available).

Then the system must be assessed for security and compliance with CMS standards. This includes documenting and implementing all necessary controls, finalizing required artifacts and supplemental documentation, and completing testing and assessments. When all these steps are complete and documented, the system will ideally be granted an ATO so it can begin operating.

There are some key steps to keep in mind as the new system enters the Develop and Assess phase.

Establish stakeholder communications

This part of the system life cycle is document-heavy and requires input 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
• Cybersecurity and Risk Assessment Program (CSRAP) team (within ISPG)
• System Developer and Maintainer (SDM)
• Privacy Subject Matter Expert (PSME)
• Technical Review Board (TRB)

Design, develop, and deploy

Design and development is managed by the Business Owner (BO) and project team. The CMS Target Life Cycle 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 and tested for compliance with requirements and CMS standards. In order to become production ready, everything must comply with CMS Technical Reference Architecture (TRA) and meet the security, privacy, and accessibility standards outlined in the CMS Acceptable Risk Safeguards (ARS).

Define the accreditation boundary

The accreditation boundary describes all components of an information system to be accredited by an authorizing official and excludes separately accredited systems, to which the information system is connected. So it defines exactly what components and assets the ATO will cover.

When defining the accreditation boundary, assets are provided and supported by the CMS cloud service provider. Additionally, the Application Development Organization (ADO) – often a contractor – 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 three-tier architecture set by the CMS Technical Review Board (GRB). 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 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.

Conduct a system test

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 and make sure the system is working as expected. This test validates the complete and fully integrated software product, and involves the full project team.

Start continuous monitoring

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 in 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 Cybersecurity Operations 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 the documentation required for their system and upload it to CFACTS.

Review for assessment readiness

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.

Assessing and testing a new system

Assessments and tests are conducted to ensure that the new system has implemented necessary security controls and meets CMS requirements. If the results show any unacceptable weaknesses in the system, the team will need to mitigate them before continuing the process to request ATO.

Schedule tests promptly

The ISSO and project team will set the timing for the required Penetration Testing and Cybersecurity and Risk Assessment Program (CSRAP) (or, alternatively, a Security Controls Assessment). The ISSO reaches out to the PenTest Team and the CSRAP team to schedule the tests. As the team works, the timeline and schedule should be shared with the CRA.

Conduct Penetration Testing

Penetration Testing (or PenTesting) helps determine the security of a system by attempting to exploit vulnerabilities. It mimics real-world scenarios to see if bad actors will be able to penetrate the system and cause harm to organizations or individuals.

The ISSO and project team work with a PenTest coordinator to schedule and conduct the test. To avoid delays, the pen test should be requested at least 3 months before the ATO deadline. Learn all about PenTesting here, including scheduling instructions.

After the test, the PenTest team will notify the project team of any issues, which must be mitigated within 25 days. If the issue can’t be resolved in 25 days, the team must create a Plan of Action and Milestones (POA&M) to manage it.

Finalized results from Penetration Testing are uploaded as a CAAT spreadsheet into CFACTS, and all parties (including the CISO team) are notified that the results are complete and available.

Conduct the Cybersecurity and Risk Assessment Program (CSRAP)

Cybersecurity and Risk Assessment Program (CSRAP) 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), CSRAP facilitates and encourages risk-based decision making.

CSRAP focuses on the core controls that pose the highest risk to CMS and defines mission-oriented security objectives. CSRAP reports incorporate plain language, relevant findings and actionable results and conclusions to aid project teams’ risk-based decision making. Learn all about CSRAP here, including scheduling instructions.

To fulfill the CSRAP requirement, the ISSO works with the CSRAP team and project team to create and complete an assessment plan. To avoid delays, this assessment should be scheduled at least 3 months before the ATO deadline. Once the CSRAP is complete, the CSRAP Final Package will be uploaded to CFACTS.

Check for 508 compliance

While it is not an explicit requirement for ATO, accessibility is an important consideration for all project teams at CMS. 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. Some 508 resources from GSA can be found here.

Manage identified risks with POA&Ms

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

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 from assessments and audits. The ISSO coordinates with the team to manage, remediate, and (if necessary) accept the risk of open POA&Ms. Learn all about managing POA&Ms in the CMS POA&M Handbook.

CMS System ATO Request / Re-authorization Form

With all documentation and assessments completed and uploaded to CFACTS, the ISSO can now request ATO certification. The ISSO submits the CMS System ATO Request / Re-authorization Form, which is filled out and submitted within CFACTS. (This form can also be used to request "re-authorization" for a system that is not a new system. ATOs need to be renewed every 3 years, or when the system undergoes a major change.)

ATO review and certification

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 U.S. federal government”. With a completed and approved ATO, the system moves into the Operate phase of its life cycle.

Operate

The Operate phase is what we think of as normal business operations. The system runs in a production environment, and the team does normal upgrades, enhancements and maintenance. The system is being used to achieve the business objectives stated in the Initiate phase.

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

The following maintenance issues must be supported throughout this phase:

• Upgrades
• System software patches
• Hardware upgrades
• Modifications to interfaces with other systems

During the Operate Phase the project team works with the Information System Security Officer (ISSO) to maintain current documentation and to support periodic reviews and audits. The inability to produce current documentation may impact a system’s ATO.

Conduct annual assessments

Each system undergoes annual assessments and maintenance throughout their life cycle to ensure compliance with its ATO and identify potential vulnerabilities. These typically include:

• Updating core documentation
• Updating the Contingency Plan (CP)
• Conducting a Contingency Plan Exercise (often in the form of aTableop Exercise)
• Undergoing Penetration Testing
• Addressing and closing any Plan of Action and Milestones (POA&Ms)
• Assessing controls

Request re-authorization

Every three years, a system's ATO is assessed for re-authorization. Much like the annual assessments, this includes a review of a subset of system controls and POA&Ms. Once the review is completed, the ISSO and Business Owner submit an ATO request form proving that all testing has been completed. ISPG then reviews the request form and renews the system authorization.

Update ATO if system changes

A significant change to a system can require an update to its ATO. A significant change is defined as a change that is likely to substantively affect the security or privacy posture of a system (see NIST SP 800-37 for more information). This includes upgraded hardware or applications, changes in the information collected by the system or how the information is handled, changes to system ports or services, and more.

If a system is undergoing a significant update, the Business Owner checks with the ISSO to see if an authorization change will be necessary. The ISSO completes a Security Impact Analysis (SIA). If it is determined that the update will not impact system security, the change is determined to be minor. In this case the only action is to update any relevant documentation in CFACTS.

If the update is determined to be a significant change, the system could require a new ATO. In this case, the ISSO works with the BO and team to complete a new intake form.

Resolve cyber risk events

As more activities move online and to the cloud, the chance of cyber attacks and other risks go up. If a risk event is identified, the ISSO and team must work quickly and collaboratively to isolate and resolve it. The ISSO must open an incident response ticket with the IT service desk to start an investigation. (This is done in ServiceNOW). They will execute the CMS incident management lifecycle process to address any actual or false positive events.

Once the risk is under control, system security should be reviewed and updated to lower the chances of the risk recurring in the future. The updates must be tested to ensure they both remediated the risk and that they haven't negatively impacted any other systems. Learn more about Incident Response here.

The system continues to operate – undergoing assessment, reassessment, and change management – through the end of its contract or useful life. Once it reaches either of these milestones, the system transitions to the Retirement phase.

Retire

A system moves to the Retire phase once it reaches the end of its useful life or the end of its contract. At this point, the decision is made to shut it down through a managed process outlined in the System Disposition Checklist. This ensures compliance with federal guidelines when retiring a government IT system. There are many aspects to consider, including the following:

• Records retention
• Information security
• Investment close-out procedures

The Business Owner (BO) and Information System Security Officer (ISSO) conduct a thorough planning process to define all tasks to decommission the system. There are several documents that must be completed by the ISSO and Project team and signed by the BO and/or the ISSO.

• System Disposition Checklist
• System Disposition Plan
• System Retirement Memo
• Certificate of Destructions

Any remaining activities must be transitioned to a different process or system. All contracts are closed and data is archived according to the System of Record Notice (SORN) or other guidelines. Any remaining hardware must be disposed of according to federal best practices.

Types of authorizations

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 recognizes that every system is unique and that a one-size-fits-all approach won’t work. There are several different types of compliance authorizations provided by CMS to manage agency-wide risk.

Authority to Operate (ATO)

As explained above, 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 three years, although there are circumstances where CMS will authorize a system for a shorter period of time (see more information about this below).

When should ATO be used?

Information systems that intend to operate for three 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

Learn more about the process and requirements for ATO.

Ongoing Authorization (OA)

Getting authorization for a system to operate through Ongoing Authorization (OA) is a new initiative at CMS. Its goal is to fundamentally change authorization and compliance from reactive evaluation to proactive, ongoing monitoring. Rather than subjecting project teams to the current 3-year compliance cycle, the OA approach provides real-time data about a system’s security posture.

OA is equivalent to ATO in that it gives systems the authorization to operate, but it’s done through automation and continuous assessment of risk, instead of through documentation-heavy compliance processes. This reduces the load on Business Owners, ISSOs, and project teams – while providing CMS a clearer picture of its risk level at any given moment.

When should OA be used?

To be eligible for OA, systems must leverage the latest control automation tools, including the latest control automation tools. Additionally, all Continuous Diagnostics and Mitigation (CDM) tools must be implemented and tracking the system's hardware (HWAM), software (SWAM), and vulnerability (VUL).

Learn more about the process and requirements for OA.

Re-authorization

A system may need to be reassessed and re-authorized if the application team is planning to make significant changes. When changes to a system are being planned, the team completes a Security Impact Analysis (SIA) to determine how the changes will impact the system’s security and ATO.

If the change is significant and the analysis reveals that re-authorization is necessary, the team schedules an CSRAP assessment to determine if there are any potential findings (risks). If there are findings, the team works to mitigate them. Once findings are mitigated to an acceptable level, the Cyber Risk Advisor (CRA) presents the case for the re-authorization to the Business Owner for a new ATO letter.

When should re-authorization be used?

Changes to a system that are considered “significant” and may require re-authorization include:

• System security boundary
• Encryption methodologies
• Administrative functionality within the application
• The kinds of information stored (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

ATO stakeholders

The process of gaining and maintaining Authorization to Operate (ATO) involves many stakeholders across the organization. It’s important for each person or group to understand their responsibilities and to communicate clearly with other stakeholders during the process.

Chief Information Security Officer (CISO)

The CISO is an agency official (federal government employee). They carry out the Chief Information Officer’s (CIO) information security responsibilities under federal requirements in conjunction with the Senior Official for Privacy. From setting policy and guidance to approving Authorization to Operation (ATOs), the CISO drives information security at CMS.

Responsibilities related to ATO

• Define information security and privacy control requirements
• Delegate authority to approve system configuration deviations to the Cyber Risk Advisor (CRA) and Information System Security Officer (ISSO)
• Publish an Ongoing Authorization process
• Approve ISSO appointments from the Program Executive
• Approve the independent security control assessment deliverables
• Coordinate with stakeholders to ensure compliance with control family requirements
• Authorize the immediate disconnection or suspension of flagged systems until the AO orders reconnection

Cyber Risk Advisor (CRA)

The CRA is an agency official (federal government employee). They work with ISSOs and project teams to help ensure that projects adhere to security controls and are documented and tracked accordingly in the CMS FISMA Continuous Tracking System (CFACTS). They act as the subject matter expert in all areas of the CMS Risk Management Framework (RMF).

Responsibilities related to ATO

• Evaluate and communicate the risk posture of each system to executive leadership and make risk-based recommendations to the Authorizing Official (AO)
• Help ensure that all requirements of the CMS ARS and the procedures of the Risk Management Handbook (RMH) are implemented
• Participate in the System Development Life Cycle (SDLC) / Technical Review Board (TRB); provide requirements; and recommend design tradeoffs based on security, functionality, and cost
• For each system, coordinate with Data Guardian, System Owner, Business Owner, and ISSO to identify types of information processed, assign security categorizations, and manage information security and privacy risk
• Ensure information security and privacy testing is performed throughout the SDLC and results are considered during the development phase
• Monitor system security posture by reviewing all proposed information security and privacy artifacts to make recommendations to the ISSO

Business Owner (BO)

The BO is a CMS official (federal government employee). They are Group Directors or Deputy Group Directors, and they encounter the ATO process when they are building or implementing a system to address their business needs. BOs are not expected to be technical or security experts, but their participation and collaboration is critical to the success of the ATO.

Responsibilities related to ATO

During an ATO, the BO works closely with technical and security stakeholders – particularly the ISSO – to ensure that the data and information in their system is properly documented and managed. Working with their team, the BO’s responsibilities include:

Document and Protect PII and PHI

• Comply with the the CMS Policy for IT Investment Management & Governance
• Coordinate with the CRA and ISSO to identify the information their system processes, and document and manage any PII and PHI
  • Ensure that CMS has the legal authority to conduct activities involving the collection, use, and disclosure of information
  • Assign the appropriate security categorizations to the information system
  • Determine information security and privacy impacts and manage risks
• Work with Contracting Officers (COs) and Contracting Officer’s Representatives (CORs) to determine the minimum necessary PII/PHI required to conduct the activity for which the agency is authorized
• Coordinate with the COs and CORs, Data Guardian, Program/Project Manager, the CISO, and the Senior Official for Privacy to ensure appropriate information security and privacy contracting language from relevant sources is included into each IT contract. Relevant sources must include, but are not limited to:
  • HHS Office of the Assistant Secretary for Financial Resources (ASFR)
  • HHS Office of Grants and Acquisition Policy and Accountability (OGAPA)
  • CMS Office of Acquisition and Grants Management (OAGM)
• Coordinate with the CRA, ISSO and others to ensure compliance with the CMS ARS and the Internal Revenue Service (IRS) Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies

Manage CMS Data Privacy and Security

• Own and manage access to the information stored, processed, or transmitted in the system
• Manage and approve all use and disclosure of data from CMS programs or systems
• Verify that CMS programs and systems only disclose the minimum data necessary
• Confirm adequate security and privacy controls are in place to protect CMS systems
• Prepare Privacy Impact Assessments (PIAs) for programs or systems with the direction from the CRA
• Support the analysis of incidents involving PII and help determine the appropriate action to make notification of privacy breaches and reporting, monitoring, tracking, and closure of incidents

Information System Security Officer (ISSO)

The ISSO is either a CMS official (federal government employee) or a Contractor (also known as an ISSO Contract Support). They are the key connection between the BO and the CMS security apparatus. They work closely with the BO, the CRA and other stakeholders to move a system through the ATO process.

An ISSO’s role in the ATO process – which overlaps with many ongoing duties related to system security – is outlined in the ISSO Handbook.

System Developer

The Developer must be a CMS official (federal government employee). They are responsible for providing management and oversight to the project team developing and maintaining the system. This includes working with the team to implement the security controls needed for an ATO. They work with the ISSO, project team, CMS Security Automation Framework (SAF), and the DevSecOps support team to help project teams build successful DevSecOps platforms and secure system ecosystems.

Responsibilities related to ATO

• Create, document, and implement information security- and privacy-related functional requirements to protect CMS information, systems, and processes, including:
  • Integrate requirements effectively into IT products and systems
  • Ensure requirements are adequately planned and addressed in all aspects of system architecture
  • Integrate and deploy automated information security and privacy capabilities (as required)
• Coordinate with the ISSO to identify the necessary information security and privacy controls for the system
• Follow the CMS System Development Life Cycle (SDLC) in developing and maintaining a system, including:
  • Understand the relationships among the system's features and information security and privacy safeguards
  • Ensure all development practices comply with the CMS Technical Reference Architecture (TRA)
• Execute the Risk Management Framework tasks listed in NIST SP 800-37 and the CMS Risk Management Handbook
• Ensure CMS systems or applications that share data for any purpose are capable of extracting data by pre-approved categories
• Share only the minimum PII from CMS systems and applications that is necessary and relevant for the purposes it was originally collected

Assessor

The Assessor sits on the CMS security team and is responsible for checking the compliance of systems. Assessors must be independent and impartial, which means they are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the information systems under assessment.

Responsibilities related to ATO

Assessors work with the ISSO and CRA to validate and verify that a system’s documented controls work. They use assessment cases to test the system. The process typically involves the following steps:

• The ISSO notifies the CRA that an assessment is being requested, and a tentative assessment date is set
• The CRA provides the ISSO with pricing information and instructions for using the Comprehensive Acquisitions Management System (CAMS) to pay for the assessment, and notifies the independent assessor that an assessment needs to be scheduled
• At least six weeks prior to the assessment kick-off, the ISSO works with the BO to move funds for the assessment using the CAMS
• The assessment begins once the funds are verified as available via the CAMS

Authorizing Official (AO)

The AO is responsible for the overall impact categorization and risk acceptance. They determine if the risk of operating the system is acceptable, and if so, issue an Authority to Operate (ATO) for that system. They often designate this responsibility to one or more other people. At most federal agencies this role is performed by the Chief Information Officer (CIO).

Penetration Tester (PenTester)

PenTesters test the security of a system by attempting to exploit vulnerabilities.These tests can help CMS to improve its overall information security posture by exposing weaknesses and providing guidance on steps that can be taken to reduce the risk of attack. The test is designed to proactively identify the methods that bad actors might use to circumvent security features. After the test, a findings report is produced.At CMS, this service is offered and funded by the CMS Cybersecurity Integration Center (CCIC).

Learn more about CMS PenTesting here.

Program / Project Team

Those who are trying to build/launch the system.

System Owner

The system owner is usually the product lead or tech lead of the project team. They will be named in the ATO documents and are the main contact during the evaluation process that leads up to an ATO.

Enterprise Architecture and Data Group (EA)

Every federal agency is required to develop Enterprise Architecture to guide information technology investments. The CMS EA Group is located in the Office of Information Technology (OIT), and it works to help document all information system architecture at the agency. This includes working with project teams to provide the documentation required for an ATO.

Governance Review Team (GRT)

The Governance Review Team is a key stakeholder group during the Initiate Phase of the ATO process. It helps project teams determine if there is a need to build a new system, and to work through the IT governance process.

The GRT directs project teams to available resources, advises them on how to properly develop and document their business case, and analyzes potential existing solutions at CMS. Based on these discussions, the GRT makes recommendations to the Governance Review Board (GRB) about whether to move forward with developing a new system.