CMS Acceptable Risk Safeguards (ARS)

Access the ARS

Current version of the ARS:

ARS 5.1

About the ARS

The Centers for Medicare & Medicaid Services (CMS) Information Security and Privacy Acceptable Risk Safeguards (ARS) provides the standard to CMS and its contractors as to the minimum acceptable level of required security and privacy controls.

The ARS also provides supplemental controls and control enhancements for Business Owners to consider. Many of the mandatory and supplemental controls are customizable (tailorable) by the Business Owner when necessary to meet missions or business functions, threats, security and privacy risks (including supply chain risks), type of system, or risk tolerance. Business Owners must review all controls since all are relevant and should be considered – even if they are not required to implement – because these controls may help to reduce overall risk.

How ARS works at CMS

CMS has an information security and privacy program managed by the Information Security and Privacy Group (ISPG) under the leadership of the CMS Chief Information Security Officer (CISO) and Senior Official for Privacy (SOP). Per the Department of Health and Human Services (HHS) Information Systems Security and Privacy Policy (IS2P), the CMS Chief Information Officer (CIO) designates the CISO as the CMS authority for implementing the CMS- wide information security program. HHS IS2P also designates the SOP as the CMS authority for implementing the CMS-wide privacy program.

Through the ARS, the CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate. All CMS stakeholders must comply with and support the ARS to ensure compliance with federal requirements and programmatic policies, standards, procedures, and information security and privacy controls.

ISPG is responsible for ensuring the information security and privacy program defines baselines that are compliant with authoritative legislation, statute, directives, mandates, and overarching policies. The program must also provide:

Cyber Risk Advisor (CRA) and Privacy Advisor (PA) services to Business Owners and Information System Security Officers (ISSOs)
A process for Authority to Operate (ATO)
A process for Plan of Actions and Milestones (POA&M)
A common set of security and privacy controls (e.g., policy) that can be inherited across CMS (i.e., Office of the Chief Information Security Officer [OCISO] control catalog)
An inheritable (common) control process that facilitates control inheritance from CMS control providers

The CMS CISO or SOP must review any waivers or deviations from the published baselines and make appropriate recommendations to the CIO for risk acceptance.

How is ARS used?

The goal of the ARS is to define a baseline of minimum information security and privacy assurance. These 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 (CIA) for all of CMS’ information and information systems is the primary purpose of the CMS information security and privacy assurance program. In compliance with the CMS Information Systems Security and Privacy Policy (IS2P2), the ARS provides a defense-in-depth security architecture along with a least-privilege, need-to-know basis for all information access.

Incorporating controls cataloged in the ARS will ensure that CMS and CMS contractor systems meet a minimum level of information security and privacy assurance. CMS systems are also subject to technical security protections defined under CMS’ other governance documents, including:

CMS Technical Reference Architecture (TRA)
Applicable TRA Supplements
CIO/CTO/CISO Memorandums
CMS Target Life Cycle (TLC)

These documents, managed under the Office of the CMS CIO, describe architecture and lifecycle standards required of CMS systems.

The controls within the ARS are not intended to be an all-inclusive list of information security and privacy requirements nor are they intended to replace a Business Owner’s due diligence and due care to incorporate additional controls to mitigate risk. The ARS controls are the minimum security and privacy requirements to be considered and employed where applicable throughout the risk management process and the CMS TLC.

Who needs to follow ARS?

All CMS employees, contractors, sub-contractors, and their respective facilities supporting CMS business missions and performing work on behalf of CMS must observe the baseline policy statements described in the CMS IS2P2. The ARS controls provide a roadmap to compliance with the CMS IS2P2 and serve as a guideline to be used throughout the TLC to ensure that CMS information systems are adequately secured and CMS information is appropriately protected.

The Business Owner, assisted by the Information System Owner and System Developer/Maintainer, has primary responsibility for evaluating the ARS, determining the appropriateness of each control for their system, and ensuring their proper implementation and effectiveness.

Business Owners must review both the non-mandatory (CMS recommended) controls and enhancements listed in the ARS and controls and enhancements under NIST SP 800-53 that were not selected (i.e., those that CMS did not pre-select for inclusion into the ARS as mandatory controls and enhancements, or that CMS selected for inclusion in the ARS but only as non-mandatory controls and enhancements) to determine if any of the controls and/or enhancements would assist in reducing risks to the system.

How is ARS structured?

The information security and privacy controls have a well-defined organization and structure. They are organized into 20 control families for ease of use in the control selection and specification process. The families are established by NIST SP 800-53. Each family contains controls that are related to the specific topic of the family. A two-character identifier uniquely identifies each control family (e.g., AC for Access Control). Security and privacy controls may involve aspects of policy, oversight, supervision, manual processes, organizationally defined parameters, and automated mechanisms that are implemented by systems or actions by individuals.

Control Requirements Structure

The CMS-tailored information security and privacy controls include and encompass the NIST and HHS IS2P control baselines – and serve as the starting point for organizations in determining the appropriate controls and countermeasures necessary to protect their information systems.

Many of the baseline controls may be customized (tailored) to the needs of specific missions, business, information system operations, and operating environments.

The term “organization” is used throughout the control requirements and associated elements. NIST SP 800-53 defines an organization as “…an entity of any size, complexity, or positioning within an organizational structure (e.g., a federal agency or, as appropriate, any of its operational elements)”. CMS extends and clarifies this to include applicable supporting organizations (that is, “…operational elements”) – including contractor organizations.

When assigning minimum roles and responsibilities within control requirements, text may refer to organizational leaders such as the CIO. For the purposes of control requirements, these terms are to be interpreted as follows:

For roles preceded by the term CMS, such as “approved by the CMS CIO”: These roles and responsibilities are to be interpreted to refer to the CMS agency official that holds that role or title. In this case, the CMS CIO is the CIO for the Centers for Medicare & Medicaid Services.
For roles not preceded by the term CMS, such as “approved by the CIO”: These roles and responsibilities are to be interpreted to refer to the local official that holds that equivalent role or title. In the case of a contractor organization, the CIO might refer to a corporate Chief Information Officer, Chief Technology Officer, or Director of Information Technology for Medicare Programs. The “CIO” must be understood to be whatever corporate/organizational role is the equivalent of the “Chief Information Officer” within the applicable organizational structure and scope. Within the CMS government organizational structure, “CIO” will always refer to the CMS CIO.

Security and privacy controls

A security or privacy control is the concise statement specifying specific activities or actions needed to protect an aspect of the CMS information or information system at the applicable system security level. Controls are mandatory when defined under the baseline associated with each FIPS 199 security categorization. However, security or privacy controls may be selected by the Business Owner to strengthen the level of protection provided if deemed appropriate to mitigate or reduce risk.

The CMS privacy program is responsible for managing the risk and ensuring information systems processing PII are in compliance with security requirements. When a system processes PII, there is a shared responsibility or collaboration between the security and privacy programs in implementing controls. Security or privacy controls within the ARS are identified by security control family identifier and convey CMS policy, which are based on minimum federal requirements. They employ and correlate directly to NIST SP 800-53 numbering (e.g., AC-1, AC-2, …). The control enhancements are structured the same as the base controls, following the same security control family identifier and correlating directly to NIST SP 800-53 (e.g. AC-2(1), AC- 2(2), AC-2(3)). Each security or privacy control and enhancement section includes the following:

Control Family
Control Number
Control Name
CMS ARS 5.0 Control
CMS ARS Redline
Implementation Standards (not available for all controls)
- When an implementation standard is indicated, it is associated with a security or privacy control or control enhancement. The purpose of the implementation standard is to provide a common standard for implementation across CMS for the associated control or control enhancement.
Responsibility (suggested control responsibility)
- A control or control enhancement may be implemented at the Enterprise (OCISO), Infrastructure/Control Provider or the System levels or a combination of two or more of these entities. Organizations designate the responsibility for control development, implementation, assessment, and monitoring. They implement controls selected in whatever manner satisfies organizational mission or business needs consistent with law, regulation, and policy. Organizations have the flexibility to implement their selected controls and control enhancements in the most cost-effective and efficient manner while simultaneously complying with the intent of the controls or control enhancements, so the indication that a certain control or control enhancement is implemented by just a system or by an organization is notional.
Control Review Frequency
- Frequency in which the ISSO must review or evaluate the control. Evidence of this review may be requested during an assessment.
Assessment Frequency
- Frequency in which the control must be assessed by a third-party assessor.
CMS Baseline
CMS Discussion
- The ARS may include additional Discussion to explain the intent of the control or control enhancement. Information within the Discussion may refer to NIST and other federal publications for further guidance. It is a recommended security practice to refer to the guidance and procedures for additional information. This results in a clearer and more detailed understanding of requirement specifics to assist the organization meeting the CMS security requirements.
Priority
Related Controls
- Many (but not all) controls and control enhancements are related to one or more other controls and control enhancements. Additionally, the related controls and control enhancements may provide additional safeguards that can be leveraged to better meet requirements. When addressing some controls, it may be important that their implementation documentation during an assessment or audit be consistent with one or more related controls. At the very least, organizations must take care to ensure that related control implementations do not conflict.
Reference Policy
- The references section identifies the section or paragraph designations of the federal source documents which are the basis for the applicable control requirements.
Assessment Procedures
- Assessment Objective
- Assessment Methods and Objects (These help determine if the security and privacy control implementations in the information system are effective (i.e., implemented correctly, operating as intended, and producing the desired outcome). They provide a foundation to support the security and privacy assessment and authorization process. The “Assessment Procedure” section consists of two sub-sections that are designated to achieve one or more objectives by applying methods to assessment objects.)
Major Change designation and explanations

Each of the above sections of each security or privacy control may contain, in this order: a general statement; a statement concerning systems that contain PII; a statement concerning systems that contain PHI; and a statement concerning systems that are HVAs. Not all controls will contain all statements.

How can ARS be customized?

The security and privacy controls and control enhancements are broadly designed for applicability to the entire CMS organization. Following Section 3 of NIST SP 800-53, the process is:

Categorize the system using FIPS 199 (i.e., High, Moderate, or Low)
Select the control baseline and determine applicability of controls within the baseline
Identify inheritable common security and privacy controls (e.g., through the Infrastructure/Control Provider and the OCISO inheritable control catalogs)
Identify and select overlay controls for systems designated as High Value Asset (HVA), or Privacy (It is recommended that the base control associated with these enhancements should be implemented alongside.)
Customize/tailor controls as appropriate by applying additional controls, providing compensation for controls that cannot be met, and defining parameters/values/attributes. Ensure the implemented controls and control enhancements are effective within your environment.

CMS recognizes that some programs are subject to authorities, both internal and external to CMS, that impose additional requirements on information systems and business processes. Controls and control enhancements that are not listed within the baselines may be selected and implemented as needed by individual systems to meet these requirements. Additionally, Business Owners must review all controls since all are relevant and should be considered, even if they are not mandatory to implement, because these controls may help to reduce overall risk.

A Business Owner may choose to strengthen the control beyond the minimum requirement defined within the ARS to provide the best possible protection of CMS’ information and information systems. In some cases, a Business Owner may not need to directly implement some specific controls if they can adequately demonstrate (i.e., show the implementation is effective within their environment) and document that the requirement is satisfied by a parent system (inherited).

Sometimes Business Owners will be unable to implement information security and privacy controls, even at a minimum level, due to design, resource issues such as funding restrictions, personnel constraints, or hardware/software/facility limitations. Under these circumstances, Business Owners may use compensating controls to reduce the risk to CMS’ information, information systems, assets, and reputation. Business Owners must consider implementation of compensating controls as part of a risk-based decision process. These decisions must go through the risk acceptance and risk management processes as a part of the CMS security assessment and authorization program.

The compensating controls must be documented in the System Security and Privacy Plan (SSPP), and any remaining risk must be documented in accordance with current risk assessment procedure within the Information Security Risk Assessment (ISRA), and approved by the Authorizing Official (AO) (i.e., the CMS CIO) or his/her designated representative using appropriate policy waiver mechanisms.

Any security and privacy control and control enhancement customization must be documented within the SSPP to address the system’s mission and operational environment. Business Owners wishing to tailor information security or privacy controls must:

Identify the set of controls that would be applicable to that FISMA system
Identify which controls they wish to tailor
Select and implement alternative or compensating controls, when needed
Impose stronger or more restrictive parameters on the implementation of controls
Assign specific values to organization-defined (i.e., FISMA System) information security and privacy control parameters via explicit assignment and selection statements
Supplement baselines with additional security controls and control enhancements in response to mission requirements, security objectives, technology-driven needs, and other considerations

However, while tailoring implementation may make selected controls and control enhancements more stringent, tailoring may not be used to make the controls and control enhancements identified as part of the CMSR baselines less stringent without appropriate documentation (within the SSPP and ISRA) and approval from the Authorizing Official (i.e., the CMS CIO).

CMS tailoring example 1

Identifying Controls and Control Enhancements Customizations to a System Environment

System specific customizing of the system implementations within the SSPP is reflected within CFACTS. Examples of customizing controls are provided below:

This is an extraction from Control AC-2 (Account Management) and associated FIPS 199 Implementation Standards, and provides an example on how tailoring may be leveraged to better meet mission/system needs. This example is for a fictitious program known as CMS XYZ that provides an interface for beneficiaries and providers.

Control from ARS

The organization:

a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: individual, group, system, application, guest/anonymous, emergency, and temporary;

. . .c. Establishes conditions for group and role membership;

. . .e. Requires approvals by defined personnel or roles (defined in the applicable security plan) for requests to create information system accounts;

. . .j. Reviews accounts for compliance with account management requirements at least every 90 days for High and Moderate systems or 365 days for Low systems; and

k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.

Implementation Standards (High, Moderate, & Low):

. . .STD.3 Regulate the access provided to contractors and define security requirements for contractors.

. . .STD.6 Notify account managers within an organization-defined timeframe when temporary accounts are no longer required or when information system users are terminated or transferred or information system usage or need-to-know/need-to-share changes.

Tailored control implementation (e.g., private implementation details)

The CMS XYZ Program:

a. Requires the following types of information system accounts to support CMS XYZ Program missions/business functions:

Individual/Organizational user accounts (federal and contractor employees),
System accounts (required by underlying operating system),
Application accounts (required by installed applications),
Guest/anonymous accounts (general users such as beneficiaries and providers)

Emergency and Temporary accounts (to provide emergency/temporary access) Shared/group accounts are not permitted under the XYZ Program. . ..

c. The following group and role memberships apply to the CMS XYZ Program;

Group/roles associated with individual/organizational users:
- a. Employee I (maintaining/managing system)
- b. Employee II (elevated privileges for maintaining/managing system)
- c. Organizational Administration
- d. Application Administration
System group/roles (required by underlying Operating System)
Application group/roles (required by installed applications)
Guest/Anonymous (required for general user accounts for beneficiaries and providers). . .

e. Except for the general user account, the CMS XYZ Program Information System Security Officer (ISSO) or designee must approve all requests and modifications for an information system account before an account is created or group and role memberships are modified.

Emergency accounts may be authorized by the ISSO via phone. Approval must be logged within the Program XYZ system log book.
All approvals are logged.
The general user account is created by the general user (i.e., beneficiaries and providers) and is subject to the guidance defined under NIST SP 800-63 (latest) and Program XYZ processes and procedures for creating a general user account;. .

j. Reviews non-general user accounts for compliance with account management requirements no less often than every 30 days; and

General user accounts are reviewed every 90 days in accordance with NIST SP 800-63 (latest) and Program XYZ processes and procedures;

k. Not applicable: Processes associated with shared/group account credentials are not applicable since shared/group accounts are not permitted.

Program XYZ Customizations of Implementation Standards:

STD.3 All Program XYZ contractors and subcontractors are subject to CMS acquisition and contractor personnel requirements.

. . .STD.6 All Program XYZ systems will notify account managers within 24 hours when temporary accounts are no longer required or when information system users are terminated or transferred or information system usage or need-to-know/need-to-share changes.

The clauses listed in the bottom row have been customized to better describe how account management is implemented within the example program. In some cases, the implementation customizations defer to external processes and procedures. In another case, the customization is requiring a more frequent review cycle than CMS specified within the ARS. The customized implementation of the control and implementation standards would be included within the CMS XYZ Program SSP. Both the risk and deployed compensations associated with guest/anonymous accounts (e.g., for beneficiaries and providers) would be discussed within the XYZ Program ISRA.

CMS tailoring example 2

Identifying Controls and Control Enhancements as Not Applicable to a System Environment

Below provides three examples of controls being identified as not applicable in the example environment. The first two are security controls: Control AC-18 (Wireless Access) and PE- 13 (Emergency Lighting). This same process applies to control enhancements. As was stated in the previous section, the examples are for a fictitious program known as CMS XYZ that provides an interface for beneficiaries and providers.

Security control from ARS	The organization monitors for unauthorized wireless access to information systems and prohibits the installation of wireless access points (WAP) to information systems unless explicitly authorized, in writing, by the CMS CIO or his/her designated representative. If wireless access is authorized, the organization: a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; b. Authorizes wireless access to the information system prior to allowing such connections; c. The organization ensures that: The CMS CIO must approve and distribute the overall wireless plan for his or her respective organization; Organizations adhere to the HHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN); and Mobile and wireless devices, systems, and networks are not connected to wired HHS/CMS networks except through appropriate controls (e.g., VPN port) or unless specific authorization from HHS/CMS network management has been received.
Control implementation (e.g., allocation status & private implementation details)	Not Applicable: The CMS XYZ Program does not permit the use of wireless technology within its facilities.
Security control from ARS	The organization employs and maintains automatic emergency lighting for the information system that activates in the event of a power outage or disruption and covers emergency exits and evacuation routes within the facility.
Control implementation (e.g., allocation status & private implementation details)	Inherited: The CMS XYZ Program is entirely housed within Baltimore Data Center (BDC) facilities. All lighting is managed and maintained by BDC. It should be noted that BDC performs regular (quarterly) tests to ensure emergency lighting is operational.

Control mapping

ARS control mapping (from 3.1 to 5.0)

Eleven controls from ARS 3.1 map to the most recent version of the ARS 5.0.

Control	Maps to
MP-CMS-01 - Media Related Records	MP-6, MP-6(1), MP-7
SC-CMS-01 - Electronic Mail	SC-08
SC-CMS-02 - Website Usage	AC-14, AC-22, PL-4
AP-CMS-01 - Authority and Purpose Control Family Policy and Procedures	PT-1
AR-CMS-01 - Accountability, Audit, and Risk Management Control Family Policy and Procedures	AU-1, RA-1, PT-1
DI-CMS-01 - Data Quality and Integrity Control Family Policy and Procedures	PT-1, SI-1
DM-CMS-01 - Data Minimization and Retention Control Family Policy and Procedures	PT-1, (PM-25, CM-13, MP-6(1), SI-12)
IP-CMS-01 - Individual Participation and Redress Control Family Policy and Procedures	PT-1, IR-7
SE-CMS-01 - Security Control Family Policy and Procedures	PT-1
TR-CMS-01 - Transparency Control Family Policy and Procedures	PT-1
UL-CMS-01 - Use Limitation Control Family Policy and Procedures	PT-1

Privacy control mapping

NIST SP 800-53, Revision 4 (Appendix J) Privacy Controls Comparison to Revision 5

This table is intended to support organizations who have been using the privacy controls in Appendix J in NIST Special Publication (SP) 800-53, Security and Privacy Controls for Information Systems and Organizations, Revision 4, to transition to the integrated control catalog in Revision 5. The Revision 5 column indicates the controls that in NIST's determination most directly address the elements of Appendix J controls.

Very few of the Appendix J controls were transferred to Revision 5 in their entirety. In most cases, elements of Appendix J controls were distributed among multiple Revision 5 controls to improve the integration – and the text was changed to conform to the standardized control format or to enable the controls to be more usable within a risk management program. Organizations can use the Related Controls section for each Revision 5 control to identify other controls that may also support the transition.

Note: This table is only intended to provide pointers to how Appendix J controls evolved in the integrated catalog of security and privacy controls for Revision 5. It is not intended to provide an example of a complete control selection plan for a privacy program. More information on selecting controls can be found in the following resources:

NIST SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
SP 800-53, Security and Privacy Controls for Information Systems and Organizations
SP 800-53B, Control Baselines for Information Systems and Organizations

800-53 Rev. 4 (Appendix J) Control	800-53 Rev. 5 Controls
AP-1: Authority to Collect	PT-2: Authority to Process Personally Identifiable Information
AP-2: Purpose Specification	PT-3: Personally Identifiable Information Processing Purposes
AR-1: Governance and Privacy Program	PM-3: Information Security and Privacy Resources PM-18: Privacy Program Plan PM-19: Privacy Program Leadership Role
AR-2: Privacy Impact and Risk Assessment	RA-3: Risk Assessment RA-8: Privacy Impact Assessment
AR-3: Privacy Requirements for Contractors and Service Providers	SA-1: Policies and Procedures SA-4: Acquisition Process SA-9: External System Services
AR-4: Privacy Monitoring and Auditing	CA-2: Control Assessments
AR-5: Privacy Awareness and Training	AT-1: Policies and Procedures AT-2: Literacy Training and Awareness AT-3: Role-based Training PL-4: Rules of Behavior
AR-6: Privacy Reporting	PM-27: Privacy Reporting
AR-7: Privacy-Enhanced System Design and Development	No specific control reflects AR-7, but there are discretionary control enhancements that relate to automation.
AR-8: Accounting of Disclosures	PM-21: Accounting of Disclosures
DI-1: Data Quality	PM-22: Personally Identifiable Information Quality Management SI-18: Personally Identifiable Information Quality Operations
DI-2: Data Integrity and Data Integrity Board	PM-24: Data Integrity Board SI-1: Policies and Procedures
DM-1: Minimization of Personally Identifiable Information	SA-8(33): Security and Privacy Engineering Principles \| Minimization PM-5(1): System Inventory \| Inventory of Personally Identifiable Information SI-12(1): Information Management and Retention \| Limit Personally Identifiable Information Elements
DM-2: Data Retention and Disposal	MP-6: Media Sanitization SI-12: Information Management and Retention SI-12(3): Information Management and Retention \|Information Disposal
DM-3: Minimization of PII used in Testing, Training, and Research	PM-25: Minimization of Personally Identifiable Information used in Testing, Training, and Research SI-12(2): Information Management and Retention \| Minimize Personally Identifiable Information in Testing, Training and Research
IP-1: Consent	PT-4: Consent
IP-2: Individual Access	AC-1: Policies and Procedures AC-3(14): Access Enforcement \| Individual Access PM-20: Dissemination of Privacy Program Information PT-5: Privacy Notice PT-6: System of Records Notice
IP-3: Redress	PM-22: Personally Identifiable Information Quality Management SI-18: Personally Identifiable Information Quality Operations SI-18(4): Personally Identifiable Information Quality Operations \| Individual Requests SI-18(5): Personally Identifiable Information Quality Operations \| Notice of Correction or Deletion
IP-4: Complaint Management	PM-26: Complaint Management
SE-1: Inventory of Personally Identifiable Information	PM-5(1): System Inventory \| Inventory of Personally Identifiable Information
SE-2: Privacy Incident Response	IR-8: Incident Response Plan IR-8(1): Incident Response Plan \| Breaches
TR-1: Privacy Notice	PT-5: Privacy Notice PT-5(1): Privacy Notice \| Just-In-Time Notice
TR-2: System of Records Notices and Privacy Act Statements	PT-5(2): Privacy Notice \| Privacy Act Statements PT-6: System of Records Notice
TR-3: Dissemination of Privacy Program Information	PM-20: Dissemination of Privacy Program Information
UL-1: Internal Use	PT-3: Personally Identifiable Information Processing Purposes
UL-2: Information Sharing With Third Parties	AC-21: Information Sharing AT-3(5): Role Based Training \| Processing Personally Identifiable Information AU-2: Event Logging PT-2: Authority to Process Personally Identifiable Information PT-3: Personally Identifiable Information Processing Purposes