Introduction

This handbook gives practical guidance to Information System Security Officers (ISSO)s at CMS when performing their necessary tasks.  It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for an ISSO to be successful. 

This guide is for CMS (Federal) ISSOs, Contractor ISSOs, and contract security support individuals.  Business Owners and their staff may also find parts of this handbook useful, particularly when appointing new ISSOs or gaining a better understanding of ISSO tasks.

The ISSO role is critical to the safe and authorized use of sensitive information in support of CMS’ commitment to improving healthcare for millions of Americans. As an ISSO, 

What do ISSOs do?

Every CMS system must formally designate an ISSO who serves as the primary point of contact responsible for the system’s security and privacy. 

ISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care, coordinating all information system risk management and information privacy activities, and acting as the Business Owner’s “go-to person” for security questions and needs. Together, the ISSOs make up a supportive community working to ensure the success of the cybersecurity program at CMS.

For more details, see the section on role and responsibilities.

Who do ISSOs work with?

The ISSO is part of the portfolio team – the group of people who work together to make sure that any given CMS information system complies with federal security requirements and is managed in a way that protects the personal and health information of those who depend on CMS for benefits. The portfolio team has the following roles:

Program Executive, Information System Owner (ISO), Business Owner (BO), and Information System Security Officer (ISSO)

These people work together to take full responsibility for implementing the required security and privacy controls and managing the cybersecurity and privacy risk posture for each system. All of these roles must be an agency official (federal government employee) except the ISSO, which may be a federal employee or a contractor.

Cyber Risk Advisor (CRA)

CRAs are the “go-to” experts in all areas of risk management, and as such they evaluate and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the Authorizing Official. CRAs also help to identify the types of information processed by a system, assign the appropriate security categorizations, determine the privacy impacts, and manage information security and privacy risk. They facilitate the completion of all federal cybersecurity and privacy requirements – and this means that CRAs and ISSOs often work closely together.

Data Guardian

The Data Guardian coordinates CMS Program activities involving beneficiary and other types of consumer information that require privacy protections.  The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner.

Privacy Advisor

The Privacy Advisor is a member of ISPG who provides privacy-related expertise to help the team identify and manage privacy risk.  The Privacy Advisor is an agency official (federal government employee) and serves as a point of contact for issues related to the Privacy Act. They also support the completion of privacy-related artifacts such as Systems of Records Notice (SORN), Privacy Act reviews, and FISMA and Privacy Management Report.

Detailed information about all of these roles can be found in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P). 

What should an ISSO know?

The goal of every ISSO should be to support the BO to securely provide the service intended by the system. To help accomplish this goal, an ISSO should ideally know and understand their component’s business processes and how the system supports that business. This knowledge is critically applied during the construction of the System Security and Privacy Plan (SSPP).  

Information security is a means to an end and not the end in itself. In the public sector, information security is secondary to the agency's services provided to its constituency. We, as security professionals, must not lose sight of these goals and objectives.

In order to help the BO provide a CMS service in a manner that is demonstrably secure and safeguards any sensitive beneficiary information, the ISSO must know (at a minimum):

• Mission and business functions of their component
• How the system supports the component’s mission
• System details, including:
  • Architecture
  • System components (hardware, software, peripherals, etc.)
  • Location of each system component
  • Data flow
  • Interconnections (internal and external)
  • Security categorization 
  • Security requirements
  • Configuration management processes and procedures
• Users (how many, location, role, etc.)
• Key personnel by name

How are ISSOs appointed?

The CMS Program Executive in coordination with the Data Guardian, ISO, and Business Owner, is responsible for nominating appropriately qualified ISSO appointees, as defined under FISMA, to the CISO for approval.

The nominated ISSO, by signing the appointment letter, agrees to maintain the appropriate operational security posture of the information system by fulfilling all of the responsibilities identified in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P).  

A subset of the ISSO’s duties and responsibilities is contained in the appointment letter. ISSO letters must be updated whenever a change occurs. The designated ISSO should be consistently identified in three sources: the ISSO letter, the System Security and Privacy Plan (SSPP), and in CFACTS. 

The signed appointment letter should be given to the appropriate CRA for further action.  It is the responsibility of the CRA to upload the letter to CFACTS.

Getting started (for new ISSOs)

Congratulations on your new assignment as an Information System Security Officer (ISSO) at CMS! Because you are charged with protecting the sensitive information contained in systems that support healthcare delivery for millions of people, your role is vital to the success of CMS’ mission. You will learn how to identify and protect information that includes:

• Personally Identifiable Information (PII)
• Individually Identifiable Information (IIF)
• Protected Health Information (PHI)

This means that security must become a vital part of your daily routine and always top-of-mind. Your training as an ISSO will ensure that you know and understand the requirements for protecting government assets like classified information, property, and personnel.

Most importantly, you will learn to work as part of a team that is dedicated to making sure CMS information systems can operate securely. While CMS has established a security program to protect assets and keep sensitive information safe, the key ingredient is always people. No matter how comprehensive a program may be, you and your coworkers will ultimately determine the success of our established procedures. 

And we are here to help you along the way! This Handbook is your primary resource for initial information about your role, and will direct you to other sources of help and support.

Here are the steps you should take to get started:

Complete the paperwork

If you have not already, make sure that your ISSO Appointment Letter is completed and submitted to your Cyber Risk Advisor (CRA) by your Business Owner (BO). The Appointment Letter is intended to formally nominate you as an ISSO. It also gives you a wealth of information about your duties and responsibilities. It also contains the qualifications and training to which you should aspire. This document may be your first communication with your CRA — the first of many conversations. 

If you need a copy of the ISSO Appointment Letter template, contact the ISSO Support Team: ISSO@cms.hhs.gov 

Complete ISSO onboarding

The ISSO Support team in ISPG can help get you started. You should ask for an initial meeting with the team to orient you to your new role and next steps.   You should also reach out to your CRA, who may wish to meet on a regular basis initially, especially if your system has an important near-term milestone. If your BO did not set this up for you, you can do it yourself by sending a note to ISSO@cms.hhs.gov. It is helpful to put the word “Onboarding” in the subject line.

Know your systems

Make sure that in your conversation with your Business Owner, you understand whether you are going to be the primary ISSO (or the only ISSO), or if you are going to be an assistant. Do you know where your system is located? When does the Authority to Operate (ATO) expire? Are you working on a new system? The more you know at the beginning, the easier it will be to prioritize and to work with your integrated team. If you have questions about any of this, reach out to the ISSO Support Team (ISSO@cms.hhs.gov).

Meet your team

In addition to your BO and your CRA, there are others that you should get to know. We recommend that you reach out to them. We also recommend face to face meetings, at least initially. Some others you should get to know include:

• Other ISSOs in your component, if applicable
• Your system’s Technical Lead
• When appropriate, your system’s contractor security support
• The ISSO Support Team (ISSO@cms.hhs.gov)

Assess your skills with the ISSO Score Card

ISSOs come from many backgrounds, both technical and non-technical. Even new ISSOs with a technical background may not be familiar with the “CMS way” of operating. While you will be busy with your new role, you should take some initial time to get a better awareness of your capabilities to be a CMS ISSO through some focused initial training. 

We’ve made it easy to figure out what training you should prioritize using a self-assessment tool: the ISSO Score Card. Every ISSO is encouraged to take this assessment regularly as their knowledge expands. The ISSO Score Card is:

• Confidential - only you will see the results
• Quick - only taking 10-15 minutes to complete
• Geared to ISSO duties - taken directly from CMS policies and requirements
• Personalized - you’ll get a customized report to help you make a training plan
• Easy - using a simple online web interface

Go to the ISSO Score Card

Sign up for training

As an ISSO, it is vital that you understand security and privacy fundamentals and how they are applied at CMS. Regardless of your prior level of experience, you will need to know the CMS-specific workflows and governance. There is a wealth of training available to you, both for getting started and deepening your knowledge.

Wondering where to start? Here’s a simple checklist to make sure you complete the essential training that will start you on the road to success:

• Figure out what you need to know (or brush up on) using the ISSO Score Card. Use the results to sign up for training that is customized to your level.
• Learn about 6 key job functions of ISSOs using the video training series from CMS.
• Sign up for CFACTS training – it’s worth the 2-day time investment to get a solid grasp on this essential tool for the ISSO’s daily work. (This is available in the CMS Computer Based Training platform).

Finally, to build upon the checklist above, we have provided a list of Basic, Intermediate, and Advanced ISSO training courses that are free for you to take. See the Training section of this Handbook for details.

Get a mentor

Optionally, you can join the ISSO Mentorship Program to be paired with an experienced ISSO. Once paired, you should work together to develop a cadence for meeting and knowledge sharing. This allows you to gain confidence faster and get hands-on support. Learn more about the ISSO Mentorship Program here.

Join the community

The cybersecurity community at CMS is alive and growing. There are all kinds of ways that you can get involved, get an idea of what’s going on at CMS, and learn how it affects you. Attend the CMS Cybersecurity Community Forum, read the ISSO Journal, and look for ISPG-sponsored security and privacy activities.

Finally, if you have any questions along the way, just ask. Your job is very important to the success of CMS programs, and everyone at ISPG is here to support you!

Goals for your first year

By the end of your first year as an ISSO, it should be your goal to:

• Learn the security planning and administrative security procedures for systems that process sensitive information such as PHI, PII, FTI, and classified and national intelligence data
• Understand the implementation and enforcement of CMS’ Information System Security and Privacy policies and practices 
• Know the concerns and requirements that determine the administration and management of physical, system, and data access controls based on the sensitivity of the data processed and the corresponding authorization requirements
• Learn the identification, analysis, assessment and evaluation of information system threats and vulnerabilities and their impact on their component’s critical information infrastructures
• Be able to identify management, technical, personnel, operational and physical security controls
• Understand any additional critical areas of knowledge related to your system

Role and responsibilities

ISSOs maintain a strong security and privacy posture for their assigned system(s) in the following high-level ways:

• Serve as principal advisor to the System Owner (SO), Business Owner (BO), and the Chief Information Security Officer (CISO) on all system security and privacy matters

• Maintain system authorization by following the NIST Risk Management Framework to select, implement, document, test, and maintain the security and privacy controls required to authorize and operate information systems within CMS’s risk tolerance throughout the Target Life Cycle (TLC)

• Maintain security and privacy operations capabilities sufficient to identify, detect, protect, respond, and recover from security incidents (as per the NIST Cybersecurity Framework)

• Meet federal reporting requirements for information security and privacy, including documenting and mitigating weaknesses and reporting incidents and breaches

• Manage privacy requirements by working collaboratively with Data Guardians and Privacy Advisors

The official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). The following list is based on those policy documents and includes some key duties for ISSOs:

• Complete the security categorization for the FISMA system using the CFACTS tool
• Complete and maintain the System Security and Privacy Plan using the CFACTS tool
• Ensure Cybersecurity and Risk Assessment Program (CSRAP) – and Penetration Tests have been scheduled and completed in a timely manner
• Develop, document and maintain an inventory of hardware and software components within the FISMA system’s authorization boundary
• Coordinate the development of a Contingency Plan and ensure the plan is tested and maintained accordingly
• Maintain primary responsibility for the actions and activities associated with the FISMA system receiving and maintaining an Authority to Operate (ATO)
• Coordinate with the ISO, BO, and CRA to manage information security and privacy risk
• Monitor and update all POA&Ms in accordance with current requirements and instruction
• Submit recommendations to the CRA for system configuration deviations from the required baseline
• Identify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems;
• Coordinate with the ISO, BO, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information in accordance with the Privacy Act, E-Government Act, and all other applicable guidance
• Coordinate with the BO, Contracting Officer, ISO, and CISO to ensure that all requirements specified by the ARS 5.1 and the RMH are implemented and enforced for applicable information and information systems
• Report and manage IT Security and Privacy Incidents in accordance to the RMH and other applicable federal guidance

Types of ISSO roles

The specific type of ISSO role assigned to a system will depend on the needs of the system and the available personnel. The descriptions below are taken from the CMS Information Security and Privacy Policy (IS2P2).

Primary Information System Security Officer (P-ISSO)

The CMS P-ISSO may be either a federal government employee or a contractor and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers. ISSO must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the IS2P Sections 7.26 and 7.30.

Secondary Information System Security Officer (S-ISSO)

The CMS S-ISSO may be either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward and must assist the P-ISSO.

Information System Security Officer Contractor Support (ISSOCS)

The ISSOCS is a contractor-only role that assists and supports the P-ISSO and S-ISSO roles in fulfillment of their CMS cybersecurity duties.

Security or Privacy Control Assessor

The CMS Security or Privacy Control Assessor role may be performed by an ISSO. The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23.

Contingency Planning Coordinator

The CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by an ISSO. The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30.

ISSO checklist

This section provides a list of specific tasks an ISSO should perform periodically. The timelines listed for each task are general guidelines, which may vary depending on the Component guidance or system circumstances. This list isn’t comprehensive, but serves as a quick reference to help you plan your work. You may choose to make a spreadsheet for yourself to keep track of recurring tasks and due dates.

Weekly

• Review audit logs
• Routinely evaluate risk posture based upon change requests
• Ensure data is backed up
• Check status of any Plan of Action and Milestones (POA&M)

Monthly

• Review / deactivate unused accounts
• Ensure all POA&Ms with Open or Delay status are annotated with current status

Quarterly

• Ensure that all data in CFACTS is current and accurate one week before the end of the quarter (CMS submits a quarterly FISMA report to OMB based on this data)
• Ensure the completion of internal vulnerability scans

Annually

• Review and update all Security Authorization Process documentation, such as those listed below. Remember that most of these require months of effort to complete, so you must be working on them well in advance.
  • Information System Risk Assessment (ISRA)
  • Contingency Plan (CP)
  • Privacy Impact Assessment (PIA)
  • System Security and Privacy Plan (SSPP) Note: Updating security control implementation is a necessary first step to updating the SSPP. When updating any documents, ensure the old copy is retained.
• Ensure that all system users and people with significant security responsibilities (e.g., ISSOs) receive their required annual awareness training
• Conduct a Contingency Plan Test with associated training, after-action, and updated POA&Ms as necessary. Ensure that the Business Owner certifies (signs) any updated CP document.
• Review the Privacy Impact Assessment (PIA) for your system(s) and update as appropriate
• Ensure vulnerability assessments are completed at least annually, or when significant changes are made to the system
• Review and validate user access rights

Ongoing

• Continual security control assessment to ensure no risks are present
• Continual work on tests and assessments (as needed) such as:
  • Cybersecurity and Risk Assessment Program (CSRAP)
  • Penetration Testing
• Continual updating of the Security Authorization Process documentation (see list in the section above). All of these should be updated as changes occur, and all require an annual review and update.
• Complete incident response reports (as required)
• ATO updates (as required)
• Respond to any CCIC monitoring alerts (as required)

ISSO activities

Use this section to learn in-depth about the activities you must understand and perform as an ISSO – from the very beginning of your system’s development. These activities support the CMS Target Life Cycle (TLC), which is the framework that standardizes how IT systems are built, maintained, and retired at CMS. The ISSO activities also support the Risk Management Framework (RMF) from NIST, which helps organizations integrate security considerations into their software development processes.

Conduct a Security Impact Analysis (SIA)

The Security Impact Analysis is the process that you will use initially for your new system and every time a new change to the system is proposed. When you have completed this process, you will be able to provide substantive recommendations to your Business Owner on the impact of any proposed change(s). The impact may be small, or it may rise to the level of a new ATO process.

Note:  SIAs are frequently thought of as documents.  Remember that SIA is a process.  Based on the complexity and extent of the process, a completed form may help better describe the security impact, as well as necessary actions to take.  The actual CMS/FISMA requirement noted in ARS 5.1 Control CM-4 requires “Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) to conduct security impact analyses.”  It is up to you and your Business Owner/organization to determine the level to which you document your analysis.

Learn about Security Impact Assessment (SIA)

Categorize your FISMA system

Your FISMA system has different security controls based on the sensitivity of the information contained in or processed by your system. Categorization takes place within CFACTS.  You enter the appropriate area and select the type of information that will be processed.  The system categorization will be suggested automatically and noted as “Low”, “Moderate”, or “High”.  If necessary, the categorization may be manually overridden; your CRA will have to help with this.  In practice this seldom happens. 

This system categorization will have a variety of uses.  Most importantly, you will need to have this information to determine which controls to allocate for your system.

Note: Although this process sounds like it will only be done once for your FISMA system, you may have to repeat it if a proposed change includes access or storage of different types of data.   Your completed SIA will guide your actions.

• Learn more about system categorization here
• See how to categorize your system in CFACTS

Determine the Authorization Boundary

Another major initial task is to determine the system’s Authorization Boundary. The NIST definition of authorization boundary is: “All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected”.  

One practical way of determining the system’s authorization boundary is to ask whether a particular component can be changed by one’s system team, or if another team has to make updates or changes.  If your team can make the change or configuration, chances are that the component falls within your authorization boundary. As with system categorization, the authorization boundary is usually determined at the outset of system development. It may expand or contract based on changes to the system over its lifecycle.

Be aware of High Value Assets (HVAs)

The HHS HVA Program Policy defines HVAs as: “Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.”

The practical impact of this program is that, if your FISMA system is defined as an HVA, it will face additional security requirements from DHS and HHS, which may impact the continuity operations and assessments of the system.

Allocate controls

Once a system has been categorized, the ISSO has the information necessary to select controls, or allocate them.  The process is largely automatic, and is well-described in the CMS Risk Management Handbook (RMH) Chapter 12: Security and Privacy Planning. Selected controls are allocated for Low, Moderate, or High systems based on system categorization. The mechanics are described very well in the CFACTS User Manual, so that should be your primary reference point on allocating controls. Some general control types include:

System-specific controls

These are controls that your system “owns”.  If you are running on hardware that you are responsible for, there are system-specific controls for it.  If your system is an application, or Major Application, the system-specific controls are those controls that your developers and administrators configure and maintain.

Inherited controls

In many cases your system uses components provided by other FISMA systems. In the above example about hardware, what if your system is housed on hardware administered by others? This is not just a possibility – in most cases major applications run within a separate data center. Certainly this is the case for systems housed in the AWS Cloud. In these instances, the data center (or other entity) that houses your system will most likely take care of some of the controls for your system – in which case your system will be able to “inherit” controls.  

If the providing system completely takes care of a control, it is called a common, or fully inherited control. If the providing system takes care of part of a control, and relies on your system to take care of the rest of the control, it is called a hybrid control. (The CFACTS User Manual has additional information on how to inherit a control.)

Understanding which controls your team must address and which controls are available through full or partial inheritance will help you understand how to document your security control compliance (which is the next step in the cycle).

Supplemental controls

Supplemental controls (previously referred to as non-mandatory controls in ARS 3.1) can be added to a system as necessary, and are not included in baseline control allocation. They should be reviewed and added as appropriate for your system.

Implement security controls

It is your responsibility as your system’s security and privacy Subject Matter Expert to make sure that your Business Owner, system developers, and system administrators understand the controls that must be in place for your system to be “secure” to CMS standards.  Once these controls have been implemented, they need to be documented within CFACTS.  

Note:  All security controls that have been allocated for your system must have some comment.   Even fully inherited controls should have a notation that the control is fully inherited.  

Develop system documentation

Prominent documents are important to understanding the security posture of your FISMA system.  CFACTS can help with this process by automatically generating some of the documents, such as the System Security Plan. Other documents are found within CFACTS, such as System Categorization. Others, such as the Information System Risk Assessment (ISRA) must be completed using CMS-approved templates. Finally, others may either use a CMS template or a locally generated document such as the Security Impact Assessment (SIA).

Note: Make sure that all CFACTS entries, including all security controls, are accurate and complete at all times.  This will ensure that CFACTS-generated documents are accurate.

Items for the system documentation include:

System Security and Privacy Plan (SSPP)

The SSPP is the key document associated with the FISMA system security. It should provide an accurate, detailed description of the FISMA system itself, security requirements, and those controls that are actually in place to protect the system. This document is generated by CFACTS.

Tip: It is a best practice to maintain older copies of SSPPs as new versions are generated. Do not overwrite old SSPPs; you never can tell when you might need to refer to an older version.

Learn more about System Security and Privacy Plan (SSPP)

Information System Risk Assessment (ISRA)

The ISRA details the business and technical risks associated with a FISMA system.  It shares high-level information from CFACTS, as well as specific risks noted and how critical they are.

Learn more about Information System Risk Assessment (ISRA)

Privacy Impact Assessment (PIA)

The PIA is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. A PIA is a process for assessing whether appropriate privacy policies, procedures, business practices, and security controls are implemented to ensure compliance with federal privacy regulations. PIAs are published on HHS.gov and go through a three-year review process.

Learn more about Privacy Impact Assessment (PIA)

Third-Party Websites and Applications

The Office of Management and Budget Memorandum 10-23, Guidance for Agency Use of Third-Party Websites and Applications, requires that agencies assess their uses of third-party websites and applications to ensure that the use protects privacy. The mechanism by which agencies perform this assessment is a privacy impact assessment (PIA). 

In accordance with HHS policy, operating divisions (OPDIVs) are responsible for completing and maintaining PIAs for all third-party websites and applications in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available. The CMS Third-Party Websites and Applications (TPWA) Privacy Impact Assessments for each individual OPDIV system can be accessed here on the HHS website. CMS implementation specifications are included in the CMS Acceptable Risk Safeguards (ARS 5.1).

Privacy Threshold Analysis

A Privacy Threshold Analysis (PTA) is a PIA for a system that does not contain PII or only contains HHS employee information. PTAs remain internal to HHS and do not have to go through the three-year review process. A PTA may be updated based on a major change to the system. It is also possible that change to a system could result in a PTA then meeting the threshold to be a PIA.

Conduct Contingency Planning (CP)

Contingency Planning provides instructions, disaster declaration criteria, and procedures to recover information systems and associated services after a disruption. It involves cooperation with your Business Owner, your data center or hosting facility, and senior CMS leadership. (See CMS Risk Management Handbook Chapter 6: Contingency Planning).

As the ISSO, you will coordinate efforts with your Business Owner to determine the business criticality of key processes. This effort will result in a Business Impact Analysis (BIA) which, in turn, serves as the primary requirement document for determining key recovery metrics including the Recovery Point Objective (RPO), Recovery Time Objective (RTO), Maximum Tolerable Downtime (MTD), and Work Recovery Time (WRT).  

The goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime.  Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods. 

Here are the key steps and documents involved in Contingency Planning:

Create Contingency Plan (CP) document

The CP Plan is a single document that contains:

• Key recovery metrics for your FISMA system
• Pre-defined descriptions of conditions that constitute a need for action
• Pre-defined actions based on the severity of an identified incident
• Key staff, contact information, and specific duties for each person
• Item-level understanding of all of the hardware and software components of the FISMA system.

It’s important to keep in mind:

• The CP must be attested to (signed) by the FISMA System Owner annually.
• All of the information necessary for the conducting of a contingency plan must be in the CP.  There should be no references to offline personnel lists, contact information, system information, etc. 
• All identified Key Personnel must have access to their own copy of the CP in a secure location that is accessible in the event that the FISMA system is unavailable.
• The Contingency Plan, above all FISMA system documentation, must remain current.

Conduct Contingency Plan (CP) Exercise

The CP must be exercised (tested) at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one (the easiest) way to test the CP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual CP event must be available for the exercise.  

Note: Key staff members must be trained annually in their contingency responsibilities. It is best to perform this training immediately prior to the exercise. Training in this way refreshes individuals’ memories and ensures their availability for the test.

Tip: If your FISMA system is involved in an outage that causes you to exercise the CP Plan, you should consider documenting this event as an exercise of your CP Plan.

Learn more about Contingency Plan testing

Get after action report

After the exercise is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.  These deficiencies may be easily correctable, or may result in POA&Ms.  

Achieve Contingency Plan (CP) re-certification

After any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated CP documents that they have access to (even away from the office or after hours). Destroy (or return) older copies.

Assess security controls for your system(s)

All CMS systems are required to undergo assessments of risk and security/privacy control compliance before they are given Authorization to Operate (ATO). The assessment and authorization process protects the security and privacy posture of CMS systems throughout the system development lifecycle. 

Assessments of risk and/or control compliance are conducted:

• When a new system is ready to be placed into an operational state
• When a significant change has been made to an existing system
• Annually, if a system follows a FISMA 1/3 assessment schedule
• Ad hoc when requested or otherwise required

Currently there are two main types of controls assessments – SCA and ACT.  Your component will dictate which type of assessment your system undergoes. 

Note: Whichever one your system uses, make sure to schedule your assessment as soon as possible. When the assessment is complete, make sure all documentation is complete and housed in CFACTS appropriately.

Security Controls Assessment (SCA)

This is a detailed evaluation of the controls protecting an information system.  The security controls assessment determines the extent to which controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.  

Learn more about Security Controls Assessment (SCA)

Cybersecurity and Risk Assessment Program (CSRAP) (Formally Adaptive Capabilities Testing (ACT))

CSRAP is a security and risk assessment for FISMA systems at CMS. CSRAP assesses a system's security capabilities to ensure that it operates as intended and meets the security requirements for the information system. CSRAP is a critical component of the Authorization to Operate (ATO) process and is used to determine the overall system security and privacy posture throughout the system development life cycle (SDLC). For detailed information about CSRAP, see Cybersecurity and Risk Assessment Program Handbook. 

Penetration testing

Penetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by bad actors. It is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to risk within a set of specified constraints (e.g., time, resources, and/or skills). 

Penetration testing attempts to duplicate the actions of internal and external bad actors in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. It can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls. 

Penetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every 365 days or when there has been a significant change to the system. 

It is considered to be part of the group of assessments required for CMS systems, and its results are recorded in CFACTS similarly to the controls assessments (SCA and/or ACT).

Learn more about penetration testing

Security Assessment Report (SAR) and CAAT file

For all assessments, a final Security Assessment Report (SAR) chronicles the results of the assessment. The Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization states: 

At the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at CISO@cms.hhs.gov for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied”. The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. The ISSO has 30 days to create a POA&M within CFACTS.

Manage Plan of Action and Milestones (POA&M)

The POA&M is a remedial action plan (the process of accepting or resolving a risk) which helps the agency to:

• Identify and assess information system security and privacy weaknesses
• Set priorities about how to mitigate weaknesses using available resources
• Monitor and report progress toward mitigating the weaknesses

You – as the ISSO – are responsible for opening, maintaining / updating, and closing POA&Ms on a continual basis to ensure the maximum level of information security for system(s) entrusted to your care.

Learn more about Plan of Action & Milestones (POA&M)

Authorize the system

System authorization is the formal decision by senior officials to allow a CMS information system to operate. Commonly known as Authorization to Operate (ATO), this is the culmination of all the tests, assessments, remediation, documentation, and other activities that the ISSO and others on the portfolio team have done to ensure information security for the system.

In formal terms, authorization is described in the CMS Risk Management Handbook Chapter 4: Security Assessment and Authorization:

Security authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS. The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risks are acceptable. An ATO memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.

There are three NIST document requirements for an ATO “package” and six more that are specific to CMS.  The documents include:

• System Security and Privacy Plan (SSPP)
• Security Assessment (Final) Report (SAR)
• Plans of Action and Milestones (POA&M)
• Contingency Plan (CP)
• CP Testing Plan
• CP Test After Action Report
• Information System Risk Assessment (ISRA)
• Privacy Impact Assessment (PIA)
• Interconnection Security Agreement (ISA) – as applicable

Getting these documents together and conducting all necessary steps can be a long process – so you should start working on your ATO as early as possible to ensure timely completion.

Learn more about System Authorization

Continuous monitoring

Continuous monitoring is the practice of using modern tools and technology to continuously check systems for vulnerabilities and risks. Rather than thinking of getting an ATO as having “achieved” compliance, continuous monitoring allows us to observe and track evolving risks over time. Security is never “done”.

Continuous monitoring is a growing program at CMS. As an ISSO, you will work closely with the CMS Cybersecurity Integration Center (CCIC) to ensure that your system is appropriately monitored.  CCIC ensures oversight of information security and privacy, including Security Information Event Management, for each FISMA system operating by or on behalf of CMS.  

The CCIC delivers various agency-wide security services.  These services include Continuous Diagnostics and Mitigation (CDM) as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance.

More information about continuous monitoring can be found in the CMS Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization.

Manage security incidents

Along the way, a system entrusted to your care might have a security or privacy incident or breach. Anytime there is a violation of computer security policies, acceptable use policies, or standard security practices at CMS, it is considered an incident. If an incident involves the loss of control or unauthorized disclosure of Personally Identifiable Information (PII), then the incident is considered a breach.

Known or suspected security or privacy incidents involving CMS information or information systems must be reported immediately to the CMS IT Service Desk:

• Phone: 410-786-2580 or 1-800-562-1963
• Email: CMS_IT_Service_Desk@cms.hhs.gov.  

You as the ISSO should be apprised of the situation as soon as possible (if you’re not the one who initially reported the incident). You will work with the Incident Management Team (IMT) and others involved with your system to manage and report the incident and mitigate any resulting harm. More details can be found in the CMS Risk Management Handbook (RMH) Chapter 8: Incident Response.

ISSO toolkit

This section contains links to documents you will access often in your daily activities, and resources to support your work as an ISSO. You should become familiar with the purpose and usage of each.

Documents

CMS Acceptable Risk Safeguards (ARS 5.1)

The CMS Information Security Acceptable Risk Safeguards (ARS 5.1) defines information security and privacy control requirements and includes additional, detailed policy traceability statements within each control description. The ARS 5.1 provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS 5.1 may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.

The goal of the ARS 5.1 is to define a baseline of minimum information security and privacy assurance controls. The controls are based on both internal CMS governance documents and laws, regulations, and other authorities created by institutions external to CMS. Protecting and ensuring the confidentiality, integrity, and availability for all of CMS’ information and information systems is the primary purpose of the information security and privacy assurance program. The ARS 5.1 complies with the CMS IS2P2 by providing a defense-in-depth security structure along with a least-privilege, need-to-know basis for all information access.

Learn more about ARS 5.1

CMS Information Security and Privacy Policy (IS2P2)

This policy defines the framework under which CMS protects and controls access to CMS information and information systems. It provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information to assure the confidentiality, integrity, and availability of CMS information and systems.  

Along with the Acceptable Risk Safeguards (ARS 5.1), the IS2P2 stands as one of the core reference sources for cybersecurity policies and practices at CMS.

Go to the IS2P2

CMS Risk Management Handbooks

This series of handbooks is designed to help ISSOs understand and address the many CMS security and privacy requirements developed to protect their system(s). The RMH chapters are generally aligned to provide specific guidance and recommendations for specific ARS 5.1 Control Families. (For example, RMH Chapter 6: Contingency Planning addresses the ARS 5.1 controls in the CP Family.) As you work through your ARS 5.1 controls, you should have the appropriate RMH handy.

Learn more about the CMS Risk Management Handbook (RMH)

Tools and resources

CFACTS

CMS FISMA Controls Tracking System (CFACTS) is the system used by CMS as a repository for managing the security and privacy requirements of its information systems. It provides a common foundation to manage policies, controls, risks, assessments, and deficiencies across the CMS enterprise. You will use it for tracking your tasks associated with system authorization, risk remediation, and more. 

Go to CFACTS (requires CMS login)

A user manual is produced by the team that administers CFACTS and gives a guided tour through all activities in CFACTS. Although it is not a primer in risk management, many activities and concepts can be understood implicitly through their description in the User Manual and implementation in CFACTS.

Go to CFACTS user manual (requires CMS login)

ISPG website (CyberGeek)

The Information Security and Privacy Group (ISPG) provides the “CyberGeek” website as a one-stop shop for all security and privacy related information at CMS – including dedicated resource pages for ISSOs and other roles. This is a new site, and more information will become available as it grows.

Go to ISPG website (CyberGeek)

CMS Slack

Slack is an application that allows for fast and easy communication among all CMS employees and contractors. Spaces called channels allow for focused communication which will keep you organized and informed during your daily routine. Below is a list of Slack channels that will help you on your journey to becoming a fully independent ISSO:

• #ars-feedback
• #cfacts_community
• #cisab
• #cms-isso
• #cyber-risk-management
• #ispg-all
• #isso-as-a-service
• #security_community

Acronyms

Like most other parts of government, the security and privacy world at CMS is full of acronyms. ISPG maintains a list of acronyms so you can easily look up unfamiliar terms.

See the acronym list here.

ISSO Framework

As an ISSO, your daily tasks support CMS in applying the NIST Cybersecurity Framework (CSF), guidance created by the National Institute of Standards and Technology to help organizations effectively manage cybersecurity risk. (Executive Order 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, made the Framework mandatory for U.S. federal government agencies.)

We have created the ISSO Framework to show how ISSO responsibilities align with specific functions and categories of the NIST Cybersecurity Framework, and how the ISSO works with other people within the organization to complete tasks. You can refer to this Framework whenever you have questions about documentation or activities related to your job.

Go to the ISSO Framework (requires CMS login)

Security and Privacy Language for IT Procurements

CMS provides templated language to use in IT procurements to ensure the security and privacy of information and information systems that CMS uses. This includes systems provided or managed by contractors or subcontractors on behalf of CMS. The ISSO may provide support to this process.

Learn more about Security and Privacy Language for IT Procurements

Target Life Cycle (TLC)

CMS requires all new IT systems to follow the Target Life Cycle (TLC), a common framework for governing system development across the enterprise. The TLC accommodates various IT development methodologies while ensuring that systems meet all applicable legislative and policy requirements. 

(The TLC has replaced the former Expedited Life Cycle (XLC) as the official IT governance framework at CMS. If your current projects or contracts specify the use of XLC-related tools, templates, or reviews, you may continue using them.  You may also use fewer or alternative tools and templates, as long as you meet the minimum requirements outlined within the TLC.)

As an ISSO, you will enter the TLC by filling out an intake form when:

• Initiate a new IT project
• Conduct an acquisition to support a new IT project
• Request new/increased funding to support an IT project 
• Plan significant changes to an existing IT project 

After submitting your form, the CMS IT Governance Team will help you meet TLC requirements. You can also contact the governance team via email: IT_Governance@cms.hhs.gov 

• Learn more about the TLC
• Fill out an intake form (requires CMS login)

Resources external to CMS

HHS Policy for Information Security and Privacy Protection (IS2P)

The Department of Health and Human Services (HHS) is the parent organization for CMS. All of our policies and guidance are based on HHS-level documentation. The IS2P comprises HHS policies and procedures that ensure the secure collection, use, sharing, and storage of information that is both terrorism-related information and “protected information (PI)”. 

Where possible, this document identifies existing HHS policies and procedures that meet the privacy requirements. Where necessary, however, this document also creates policies specific to the activities and resources that HHS requires.  The IS2P is one of the base documents from which CMS requirements are created. You can request a copy of this policy from the CISO team: CISO@cms.hhs.gov

HHS Cybersecurity Library

Sometimes CMS borrows policies and standards directly from HHS, our parent organization. You will sometimes need to access the HHS library of cybersecurity documents for your work. 

Go to the HHS library (requires login)

NIST Special Publications

NIST Special Publications in the 800 series are of general interest to the computer security community, and these documents serve as the foundation for CMS security and privacy practices. Specifically helpful to ISSOs are the publications that contain detailed explanations of information security controls and the test cases used to assess them.

• NIST SP 800-53: Recommended Security Controls for Federal Information Systems
• NIST SP 800-53A: Guide for Assessing the Security Controls in Federal Information Systems

Learn more about NIST SP 800 series

NIST Computer Security Resource Center

The National Institute of Standards and Technology (NIST) publishes helpful resources on computer, cyber, and information security and privacy. Explore publications, news, programs, and events that will help you expand your cybersecurity knowledge. 

Visit the NIST Resource Center

OMB Memoranda and Circulars

Every year, the Office of Management and Budget (OMB) publishes a Memo with reporting instructions and guidance for FISMA, which can be useful to people with cybersecurity responsibilities at CMS. Explore OMB memos here.

There are a number of OMB Circulars that provide general guidance on information security. Three of the most relevant are:

• A-130 - Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources
• A-123 - Management's Responsibility for Internal Control
• A-127 - Financial Management Systems

OMB A-130 applies to all IT systems while A-123 and A-127 apply primarily to financial systems. ISSOs should be aware of these foundation documents and have a general understanding of their content. Explore all OMB Circulars here.

Who to contact

When you have a question or challenge, we are here to help! Here are key points of contact for situations you may face as an ISSO.

Security or privacy incident

Report known or suspected security or privacy incidents involving CMS data to the CMS IT Service Desk by calling 410-786-2580 or 1-800-562-1963 or via e-mail to CMS_IT_Service_Desk@cms.hhs.gov. 

Security or privacy questions

Do you have a question or concern related to CMS information security or privacy, and need a place to start? Send an email to the CISO Team at CISO@cms.hhs.gov regarding information security, or an email to privacy@cms.hhs.gov for questions regarding information privacy.

ISSO questions

If you have questions about the ISSO role or other activities such as the ISSO Forum —or if you just want to hear from an ISSO — send an email to ISSO@cms.hhs.gov.

Oversight and guidance

The Cyber Risk Advisor (CRA) and Privacy Advisor are your ISPG support representatives. They help improve accountability and risk management by providing hands-on oversight to system cybersecurity and privacy risk.

ISSO community

CMS Cybersecurity Community Forum (C3F)

This monthly meeting is held for the benefit of the CMS security community, covering timely and relevant topics from ISPG speakers. It’s open to all CMS and contractor security professionals. Meeting details (location, time, video conferencing link) will be in the email invitation, which is sent monthly to everyone at CMS.

See past Forum videos and materials (requires CMS login)

ISSO Journal

Read the ISSO Journal to stay updated on cybersecurity trends, learn about current events, and hear from other ISSOs. The Journal is distributed widely among CMS staff, and all cybersecurity professionals – both CMS and contractor staff – are invited to contribute! Contact us by email (ISSO@cms.hhs.gov) if you would like to write a post.

Read the ISSO Journal (requires CMS login)

ISSO Mentorship Program

The mentorship program allows experienced ISSOs to support those who are newer to the role. For mentors, this is an opportunity to build leadership skills and strengthen the future of cybersecurity at CMS. For mentees, this allows you to build your knowledge faster and get hands-on support. The structure of the program is flexible — both ISSOs will decide what cadence and duration for meetings works for them. 

A mentorship usually lasts 6 months to a year. Your supervisor will need to approve your participation in the program.  Note that although the program is generally used by newer ISSOs, it is also available for existing ISSOs who want additional bootstrap help – for example, if they are dealing with an issue or project that is new to them. Mentorship is for these ISSOs, too!

Learn about the ISSO Mentorship Program

Training

People come to the ISSO role from many backgrounds, with differing experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things operate at CMS. For new ISSOs, see the “Getting Started” section of this Handbook for tips on beginning your training journey.

NICE code for ISSOs

There is a Federal initiative to help train cybersecurity professionals. The National Initiative for Cybersecurity Education (NICE) seeks to link appropriate training to cybersecurity roles by associating NICE “codes” with training opportunities. As an ISSO, your NICE code is OV‐MGT‐001. Knowing this will help you find appropriate training for particular tasks or knowledge areas.

Training sources

There are many external sources – such as professional associations and training organizations – that can help you expand your cybersecurity knowledge and skills, but you can also get excellent free training that is provided by CMS and HHS. They are offered via the following platforms:

• CMS Computer Based Training (CBT) - Free online training courses provided by CMS
• CMS Cybersecurity Training Catalog - List of current training offerings and events (such as webinars) from CMS
• ISSO Training Page - Collection of training resources in the ISPG Confluence environment that helps you navigate the training options available to you
• HHS Learning Management System  (LMS) - Free courses for federal employees (not contractors) provided through HHS to advance your core cybersecurity knowledge or prepare you for certifications
• Federal Virtual Training Environment (FedVTE) - Another source of free training courses available to federal employees and contractors (similar to the LMS above). 

To help ISSOs focus on the most relevant training, below is a list of Basic, Intermediate, and Advanced courses that will help you grow in the specific skills needed for your role.

Basic ISSO training

The courses recommended below provide both an introduction to cybersecurity in general and guidance on how these concepts are implemented at CMS. The courses listed in bold are the most important. You should consider some or all of the rest of the courses as your time permits. If possible, try to complete the bolded courses within your first two months as an ISSO. There is no cost to take these courses. Note: HHS LMS is only available to federal employees.

Intermediate ISSO training

The courses recommended below will build on your initial knowledge. As before, you should start with the courses listed in bold, or on topics that have immediate importance to you. There is no cost to take these courses. Note: HHS LMS is only available for federal employees.

Advanced ISSO training

The advanced courses recommended below will help you gain a deeper understanding of the cybersecurity issues that you have been working with. They may also be appropriate to take earlier if you entered the ISSO role with a good basic understanding of both CMS operations and cybersecurity in general. There is no cost to take these courses.  Note: HHS LMS is only available for federal employees.