CMS Information System Security Officer (ISSO) Handbook

Introduction

This handbook gives practical guidance to Information System Security Officers (ISSO)s supporting the mission and programs of the Centers for Medicare & Medicaid Services (CMS). It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for any ISSO to be successful.

This guide is for CMS (federal) ISSOs, Contractor ISSOs, and contract security support individuals. CMS program personnel, such as Business Owners and their staff, may also find parts of this handbook useful — such as the section on ISSO activities — to gain a better understanding of ISSO tasks and their contribution to safely and effectively operate CMS programs and systems. 

Specifically, 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. 

What do ISSOs do?

Every CMS system must formally designate an ISSO who is responsible for the system’s security and privacy. The ISSO coordinates all risk management activities, and is the Business Owner’s “go-to person” for security questions and tasks.

ISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care 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 security and privacy matters for their system

• Maintain system authorization (also known as ATO) by following the CMS 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 Privacy Advisors

The official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Systems Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). For more details on the ISSO’s daily work, see the section on ISSO activities.

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 typically has the following roles. 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). 

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 filled by 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.

Privacy Advisor

The Privacy Advisor is a member of the CMS Information Security and Privacy Group (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 Impact Assessments (PIA), and Data Sharing Agreements.

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.

What should an ISSO know?

The goal of every ISSO should be to support the Business Owner (and component stakeholders) 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).  

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 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 ISSO 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). 

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): This role may be filled by 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. The P-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): This role assists the P-ISSO and may be filled by either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward.

Information System Security Officer Contractor Support (ISSOCS): This 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: This 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: This role may be filled by either 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.

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)
• Federal Tax Information (FTI)

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. 

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 ISSO Appointment Letter

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 formally nominates you as an ISSO. It also provides high-level information about your duties and responsibilities, along with qualifications and training you should pursue.

Complete ISSO onboarding

The ISSO Support Team in the CMS Information Security and Privacy Group (ISPG) can help you get started. You should ask for an initial meeting with the team to orient you to your new role and next steps. If your BO did not already set up this meeting, 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.

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 you’re not sure who your CRA is, ( ….. )

Know your systems

During initial conversations with your Business Owner, make sure 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 with your team

In addition to your BO and your CRA, there are others that you should get to know. Face to face meetings are best, at least initially. Start by ensuring you know your portfolio team. Others you should meet with 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 Scorecard

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 Scorecard. It’s a good idea to take this assessment regularly as your knowledge expands. The ISSO Scorecard is quick and confidential. It gives you a customized report at the end to help you make a training plan.

You can access the ISSO Scorecard here. This is located in the CMS Learning Management System (LMS) and requires a CMS login. Then, reach out to the ISSO Support Team so they can provide access: ISSO@cms.hhs.gov. (This tool is available to ISSOs only).

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. CMS provides extensive training opportunities, both for getting started and deepening your knowledge.

Start your ISSO training journey here, and make space in your calendar for essential courses that will give you the critical skills you need to succeed in your role.

Get a mentor

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

Join the community

The cybersecurity community at CMS is supportive and growing. There are all kinds of ways to stay informed about security and technology at CMS and learn how it affects you. Check out the ISSO community and events list, and prioritize getting involved. These resources will help you make valuable connections and gain practical knowledge.

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 the Information Security and Privacy Group (ISPG) is ready to support you!

Learn 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 activities

This section explains the activities you must perform regularly 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 CMS Risk Management Framework (RMF), which helps organizations integrate security considerations into their software development processes.

These activities are often overlapping and interconnected. They are part of the Authorization to Operate (ATO) process, which will take much of your time and attention as an ISSO.

Security Impact Analysis (SIA)

This is the process you will use initially for your new system and every time a new change to the system is proposed. When you have completed the SIA, 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.

SIAs are frequently thought of as documents — but it’s important to remember that SIA is a process.  Based on the complexity and extent of the process, a completed form (possibly based on the SIA template) may help better describe the security impact, as well as necessary actions to take. The actual CMS/FISMA requirement noted in the CMS Acceptable Risk Safeguards (ARS) is simply to “conduct security impact analyses.” It is up to you and your Business Owner or organization to determine the level to which you document this process.

• Learn how to conduct a Security Impact Analysis (SIA)
• Watch a short video about SIA (CMS login required)

System categorization

Your FISMA system has different security controls based on the sensitivity of the information it contains or processes. Categorization takes place within CFACTS. The CFACTS team provides video tutorials to help you perform system categorization and other tasks.

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.

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 Security Impact Analysis will guide your actions.

Learn more about system categorization in the CMS RMF.

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.

High Value Assets (HVAs)

You will need to know if your FISMA system is classified as a High Value Asset (HVA). 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 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. 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, 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? 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.

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.

Supplemental controls

Supplemental controls (previously referred to as “non-mandatory” controls) can be optionally added to a system to increase its security posture, 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 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.  

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. Many of these are created within CFACTS. 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 a process for assessing whether appropriate privacy procedures and security controls are implemented to ensure compliance with federal privacy regulations. The PIA is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. PIAs are published on CyberGeek and go through a three-year review process.

• Learn more about Privacy Impact Assessment (PIA)
• See all CMS PIAs

PIAs for Third-Party Websites or Applications (TPWA)

The Office of Management and Budget Memorandum 10-23, Guidance for Agency Use of Third-Party Websites and Applications (TPWA), requires that agencies assess their uses of third-party websites and applications to ensure they are protecting user privacy. This means PIAs must also be done for TPWAs, although the process is different from the PIA for CMS-owned systems.

HHS policy requires CMS, as an operating division (OpDiv) of HHS, to complete and maintain PIAs for all TPWA being used at CMS. These must be made publicly available, just like PIAs for CMS-owned systems. TPWA PIAs for CMS are published on CyberGeek.

• Learn more about TPWA PIA
• See all CMS TPWA PIAs

Privacy Threshold Analysis (PTA)

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

Contingency Planning provides the 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. The steps and artifacts related to Contingency Planning are listed below.

Business Impact Analysis (BIA)

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. 

Learn more about Business Impact Analysis.

Information System Contingency Plan (ISCP)

The ISCP is an artifact of Contingency Planning. It 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 ISCP 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 ISCP. 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 ISCP in a secure location that is accessible in the event that the FISMA system is unavailable.
• The ISCP, above all FISMA system documentation, must remain current.

Learn more about Information System Contingency Plan (ISCP).

Information System Contingency Plan (ISCP) Exercise

The ISCP 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 ISCP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual ISCP event must be available for the exercise.  

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 actually utilize (exercise) the Information System Contingency Plan, you should consider documenting this event as an exercise of your ISCP.

Learn more about ISCP testing

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.  

Learn more about the after action report.

ISCP re-certification

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

Assess security controls

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

Your component will dictate which type of Security Controls Assessment your system undergoes. Typically, systems at CMS use Cybersecurity Risk Assessment Program (CSRAP) for their system assessments. CSRAP offers various kinds of assessments depending on your system’s requirements.

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.

• Learn about the different kinds of CSRAP assessments
• Learn how to schedule a CSRAP assessment

Penetration testing

Penetration testing (PenTesting) 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). 

PenTesting is typically performed every 3 years or when there is a significant change to the system (and annually for High or HVA systems). PenTesting is often part of an assessor’s or auditor’s requirement for checking security posture. Its results are recorded in CFACTS similarly to the controls assessments (SCA and/or CSRAP).

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. This includes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. 

Learn more about CAAT files and how to generate them in 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.

Achieving ATO requires an authorization package with many types of documentation. 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.

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.

Another continuous monitoring service at CMS is Software Security Posture Management (SSPM). It can help you monitor the security configurations of any SaaS products used in your system(s) to ensure they are meeting requirements.

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.

• Learn more about Incident Response
• Learn more about Breach Response

Documents, tools, and resources

This section contains links to the documents, tools, and resources you will access most often as an ISSO.

CMS Acceptable Risk Safeguards (ARS)

The goal of the CMS Acceptable Risk Safeguards (ARS) 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 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. The ARS provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.

Learn more about the ARS.

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. The instructions within the IS2P2 aim to ensure the confidentiality, integrity, and availability of CMS information and systems.

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

Go to the IS2P2.

CMS policy guidance

The CMS provides guidance and procedures to help ISSOs and their teams follow CMS policies and standards for information security (such as the ARS and IS2P2). The guidance is generally aligned with ARS control families, but remains broad enough to allow each portfolio team the flexibility needed to meet specific security and privacy needs for individual systems. 

Go to the CMS policy guidance and procedures.

CFACTS

CMS FISMA Controls Tracking System (CFACTS) is 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. 

• Learn more about CFACTS, including instructions for getting access
• Watch videos about how to use CFACTS
• Find CFACTS training in the CMS Learning Management System (LMS) — requires CMS login to access

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. 

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)

HHS, NIST, and OMB resources

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)”. 

You can request a copy of this policy from the CISO team: CISO@cms.hhs.gov

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

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 Computer Security Resource Center (CSRC).

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.

ISSO community and events

ISSOs are highly encouraged to get involved with the cybersecurity community at CMS. Opportunities for engagement, collaboration, and learning are listed below.

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 C3 Forum videos and materials (requires CMS login)

ISSO Journal

The ISSO Journal is a quarterly publication distributed to CMS staff and contractors by the ISSO Support team. Read the Journal to stay updated on cybersecurity trends, learn about current events, and hear from others in the CMS security community. All CMS cybersecurity professionals – both federal staff and contractors – are invited to contribute to the Journal. Contact us by email (ISSO@cms.hhs.gov) if you would like to write an article.

Read past issues of the ISSO Journal (requires CMS login)

ISSO Mentorship Program

As mentioned in “Getting started”, 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. It’s also great for ISSOs who want additional bootstrap help — for example, if you are dealing with a project or experience that is new to you.

Learn about the ISSO Mentorship Program

CMS Information Security Advisory Board (CISAB)

The CISAB was established to provide a space for the Office of the Chief Information Security Officer (CISO), the Information Security and Privacy Group (ISPG), and CMS Information System Security Officers (ISSOs) representing each CMS component to share information and best practices about security and privacy — with the goal of improving the agency’s overall security posture. Meetings of the CISAB are monthly, with minutes shared in the CMS Slack channel #cisab.

Learn how you can participate in CISAB

Cyber360

As part of CMS’ commitment to security awareness and training throughout the workforce, the Cyber360 initiative brings security education resources and events to everyone at CMS. You are encouraged to attend these whenever possible.

• Snack-N-Share is a monthly virtual event open to all CMS staff and contractors. Bring your snack and listen to experts share the latest insights on staying cyber-secure at CMS. Topics include phishing prevention, responsible use of Artificial Intelligence (AI), incident response, and more. Join the CMS Slack channel #cyber360 for registration details and presentation materials.
• CyberWorks is an annual event — held every October during National Cybersecurity Awareness Month — that features security experts and other special guests. All CMS staff and contractors are invited to attend and broaden their cybersecurity knowledge. Learn more about CyberWorks.

CMS Slack

Slack is a collaboration platform that allows fast and easy communication among all CMS employees and contractors. In Slack, spaces called “channels” are organized around topics or specific initiatives at CMS. Slack channels are a good option for asking questions, sharing information, and learning from your fellow cybersecurity professionals. Below is a list of Slack channels you may want to join for keeping up-to-date on CMS security topics:

• #ars-feedback
• #cfacts_community
• #cisab
• #cms-isso
• #cyber-risk-management
• #isso-as-a-service
• #security_community
• #cyber360
• #cra-help
• #cyber-training-support
• #ispg-sec_privacy-policy

ISSO training

People come to the ISSO role from many backgrounds and experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things work at CMS. We provide free training and resources to help you build your skills for this role.

The sections below will guide you to the training that is most relevant to your needs. Start with the first section — skills assessment — to determine what kind of training you should prioritize next.

Most of the training is available in the CMS Learning Management System (LMS), which requires a CMS login to access.

Skills assessment

Each of the skills assessments gives recommendations based on your score. This will help you decide what kind of training to take next. If your score on either assessment is low, the ISSO Support team (ISSO@cms.hhs.gov) can connect you with additional appropriate training.

Cybersecurity basics

Your scores on the assessments above will indicate whether you need to strengthen your knowledge in cybersecurity basics before moving on to other training. The ISSO Support team at CMS will connect you to foundational cybersecurity training if needed, before you enroll in ISSO-specific offerings such as the ISSO Boot Camp.

ISSO basics

CMS offers several ways for ISSOs to learn the fundamentals of the role.

Risk management

Managing risk in order to protect CMS information systems is a key part of the ISSO role. Learn the foundations of risk management and how it works at CMS.

CMS policies, standards, and guidance

As an ISSO, your job is to ensure your system(s) follow the requirements of CMS security and privacy policies and standards. Learn about these requirements and the guidance CMS provides for how to follow them.

CFACTS

ISSOs spend a lot of time using the CMS FISMA Continuous Tracking System (CFACTS) for risk management and compliance documentation. It’s essential to learn how CFACTS works so you can use it effectively.

Advanced training

Once you’ve gained the essential knowledge needed for your ISSO role, consider additional training to expand your skills.