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.

Key Roles

Chief Information Security Officer (CISO)

Background

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 SOP. From setting policy and guidance to approving Authorities to Operation (ATOs), the CISO drives information security at CMS.

Responsibilities:

  • Define information security and privacy control requirements 
  • Publish CISO Directives to augment the existing policy
  • Review any requested policy waivers and deviations and provide recommendations for risk acceptance
  • Develop and implement the policies and procedures required by the Health Insurance Portability and Accountability Act (HIPAA) Security Rule 
  • Delegate authority to approve system configuration deviations to the Cyber Risk Advisor (CRA) and Information System Security Officer (ISSO)
  • Ensure implementation of the Department of Health and Human Services (HHS) and CMS information security and privacy capabilities, policies, and procedures across CMS
  • Lead the investigation and resolution of information security and privacy incidents and breaches across CMS
  • Define and oversee the goals and requirements of Agency Security Operations
  • Coordinate incident response and threat information sharing with relevant parties
  • Ensure the information security continuous monitoring (ISCM) capabilities accomplishes established goals
  • 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)

Background

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 Controls Tracking System (CFACTS). They act as the subject matter expert in all areas of the CMS Risk Management Framework (RMF).

Responsibilities

  • Evaluate, maintain, and communicate the risk posture of each system to executive leadership and make risk-based recommendations to the AO
  • Help ensure that all requirements specified by the CMS ARS and the procedures and standards of the Risk Management Handbook (RMH) are implemented and enforced
  • Serve as an active participant in the System Development Life Cycle (SDLC) / Technical Review Board (TRB); provide requirements; and recommend design tradeoffs considering security, functionality, and cost
  • For each system, coordinate with the Data Guardian, Information System Owner (ISO), Business Owner, and ISSO to:
    • Identify the types of information processed
    • Assign the appropriate security categorizations
    • Ensure that CMS has the legal authority to conduct activities involving the collection, use, and disclosure of Personally Identifiable Information (PII)/ Personal Health Information (PHI)
    • Determine the privacy impacts and manage information security and privacy risk
  • Ensure information security and privacy testing is performed throughout the SDLC as appropriate and results are considered during the development phase of the SDLC
  • Monitor system security posture by reviewing all proposed information security and privacy artifacts to provide recommendations to the ISSO

Business Owner (BO)

Background

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

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, but are not limited to:

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 SOP 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)

Background

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. 

Responsibilities

Before joining a project, an ISSO fills out an appointment letter, which is reviewed by the BO and signed-off by ISPG. Once an ISSO joins a project their responsibilities include, but are not limited to:  

General Duties

  • Coordinate with the Data Guardian, ISO, Business Owner, and CRA to: 
    • Identify the types of information processed 
    • Complete a Privacy Impact Assessment (PIA) that includes all privacy items that will be hosted in the system
    • Ensure that CMS has the legal authority to conduct activities involving the collection, use, and disclosure of PII/PHI 
    • Assign the appropriate security categorizations to the information systems
    • Determine information security and privacy impacts and manage risks
  • Report compliance on secure protocol use in websites as defined within the CMS ARS
  • Submit recommendations to the CRA for system configuration deviations from the required baseline
  • Coordinate with the CIO, CISO, SOP, BO and others to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third-party websites and application
  • Coordinate with the System Developer and Maintainer in identifying the information security and privacy controls for the system
  • Document the controls and ensure they  meet or exceed the minimal controls defined by CISO guidance 

Safeguard Privacy

  • Coordinate with the BO, CRA and other stakeholders to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information

Assess and Authorize

  • Maintain current system information in CFACTS (such as POCs and artifacts) to support requirements and processes
  • Coordinate with the BO, ISO, and CISO to ensure that all system requirements are implemented and enforced
  • Ensure identified anomalies and risks are addressed and remediated appropriately
  • Evaluate the impact of network and system changes

Duties across System Development Life Cycle

Initiation

  • Review and confirm that contracts include appropriate information security and privacy language
  • Coordinate with CMS Enterprise Architecture
  • Ensure the system is entered into CFACTS
  • Work with the BO to draft a PIA
  • Evaluate whether other privacy artifacts are required
  • Complete System Security Categorization
  • Identify system-specific, information security and privacy training needs
  • Participate in governance and project reviews

Concept 

  • Identify and discuss risk with the Program Manager and BO
  • Identify investment needs to ensure each system meets security and privacy requirements 

Planning

  • Develop a System Security Plan (SSP)

System Developer (Developer)

Background

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, and the DevSecOps support team to help project teams build successful DevSecOps platforms and secure system ecosystems. 

Responsibilities

  • Create, document, and implement information security- and privacy-related functional requirements to protect CMS information, systems, and processes, including:
    • Ensure requirements are effectively integrated into IT products and systems
    • Ensure requirements are adequately planned and addressed in all aspects of system architecture
    • Ensure automated information security and privacy capabilities are integrated and deployed 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 TRA
  • Execute the RMF tasks listed in NIST SP 800-37 and the RMH
  • 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

Background

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

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, and 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

Other Stakeholders

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. They work with ISSOs and project teams to set and document the Rules of Engagement (RoE). They then assess the system according to those terms and issue a findings report. At CMS, this service is offered and funded by the CMS Cybersecurity Integration Center (CCIC).

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 the 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.