Attachment J-2 SOO.pdf

Statement of Objectives (SOO) Medicare.gov User Experience Research and Transformation

Objectives

Product Vision

The Centers for Medicare & Medicaid Services (CMS) seek to fundamentally transform Medicare.gov into a trusted, user-centric digital platform that serves as the primary gateway for Medicare beneficiaries, caregivers, and healthcare stakeholders. The underlying business goal is to increase user engagement, improve digital literacy adoption, and create seamless pathways for Medicare users to access critical healthcare information and services.

What we're trying to accomplish:

• Increase logged-in users and overall site engagement on Medicare.gov

• Transform Medicare.gov from an information repository into an interactive, personalized user experience

• Enable Medicare beneficiaries to confidently navigate complex healthcare decisions through improved digital tools

• Create a comprehensive understanding of user journeys that spans the entire Medicare ecosystem

• Address the needs of diverse user populations, including caregivers, dual-eligible beneficiaries, and users with varying health complexity and digital literacy levels

Attributes of successful outcomes:

• Primary: Measurable increase in user engagement metrics, session duration, and successful task completion rates

• Secondary: Development of actionable user personas and experience maps that drive future platform enhancements

• Tertiary: Establishment of a research-driven foundation for ongoing Medicare.gov modernization efforts

• Strategic: Creation of scalable research methodologies and internal capabilities for continuous user experience optimization

Priority: This research serves as Phase 1 of Medicare.gov's digital transformation, with immediate application to inform platform redesign and long-term strategic planning for enhanced beneficiary services.

Context

Organizational Background: CMS administers healthcare programs serving over 68 million Medicare beneficiaries nationwide. Medicare.gov currently serves as the primary digital touchpoint for beneficiaries seeking plan information, provider directories, and healthcare guidance. The platform's user experience directly impacts healthcare access, decision-making, and overall satisfaction with Medicare services.

Current System State: Recent internal assessments and user feedback have identified several critical areas for improvement:

• Complex navigation structures that challenge users across varying digital literacy levels

• Information architecture misalignment with user mental models and decision-making processes

• Limited personalization and dynamic content delivery capabilities

• Gaps in addressing diverse user populations, including caregivers, dual-eligible beneficiaries, and users with varying health status and engagement levels

Key Stakeholders:

• Primary Users: Medicare beneficiaries (68+ million), caregivers, and family members

• Secondary Users: Healthcare brokers, insurance agents, and healthcare providers

• Internal Stakeholders: CMS Office of Communications (OC), Medicare program offices, and digital services teams

• External Dependencies: Medicare Administrative Contractors (MACs), Medicare Advantage plans, and healthcare provider networks

Business Drivers:

• Increasing demand for digital-first healthcare interactions

• Growing complexity of Medicare options requiring sophisticated decision-support tools

• Demographic shifts toward more digitally-native Medicare populations

• Regulatory requirements for improved accessibility and user experience in federal digital services

• Strategic alignment with broader OC digital transformation initiatives

Technical Environment: The current Medicare.gov ecosystem includes multiple integrated systems with varying levels of modernization. The platform must operate within government constraints and data governance requirements while delivering user experiences comparable to commercial healthcare platforms.

Statement of Need

Technical Problem: CMS requires comprehensive user research to understand the complex, multi-touchpoint journeys that Medicare users navigate when interacting with Medicare.gov and the broader Medicare ecosystem. Current analytics and user feedback indicate significant gaps in understanding user motivations, pain points, and the emotional context surrounding healthcare decision-making.

Unfulfilled Needs:

1. Deep User Understanding: Comprehensive personas reflecting the diversity of Medicare users, including varying digital literacy levels, health complexity, and caregiver relationships

2. Journey Mapping: Complete understanding of how users move between digital and offline touchpoints, including interactions with brokers, call centers, and healthcare providers

3. Emotional Context: Insight into emotional and psychological factors influencing user behavior during critical healthcare decisions

4. Ecosystem Integration: Understanding of how Medicare.gov fits within users' broader healthcare management workflows

5. Government-Specific Constraints: Research recommendations that account for the unique constraints and complexities of government digital platforms

Product Objectives:

• Develop comprehensive user personas representing the full spectrum of Medicare users

• Create end-to-end experience maps capturing both digital and offline touchpoints

• Identify specific moments of friction and opportunity within current user journeys

• Establish baseline metrics for measuring future user experience improvements

• Generate actionable recommendations that account for government platform constraints and capabilities

Technology Objectives:

• Inform technical requirements for Medicare.gov platform modernization and other critical interoperability initiatives as directed by the Administration

• Identify integration opportunities with existing CMS systems and external partners

• Establish user experience principles that guide future development priorities

• Create research methodologies that can be replicated for ongoing user insight generation

• Ensure data governance compliance with government AI and proprietary data requirements

Why This Matters:

Medicare decisions directly impact health outcomes and financial security for 68 million Americans. Improving the digital experience can reduce barriers to healthcare access, improve decision-making quality, and ultimately contribute to better health outcomes across the Medicare population.

Approach

Assumptions

Team Composition and Methodology: CMS envisions a research team leveraging a vendor agency with a proven mixed-methods approach, combining a quantitative platform with deep ethnographic research capabilities. The team should include:

• Core Research Team: Dedicated qualitative research pods with expertise in healthcare user research

• Quantitative Analysis: Data scientists and specialists with an understanding of research methodology as well as government data governance compliance

• Synthesis Team: Real-time analysis capabilities with embedded Mission Control for live research readouts

• OC Partnership: Close collaboration with Office of Communications team to ensure alignment with government constraints

Research Methodology Expectations: Based on the vendor agency’s demonstrated capabilities and OC requirements:

• Mixed-Methods Approach: Integration of quantitative insights with ethnographic fieldwork

• Government Compliance: Adherence to federal data governance and AI usage requirements

• Geographic Diversity: Research conducted across multiple markets for representative sampling

• In-Person Emphasis: Recognition that healthcare decisions require face-to-face research methods

• Ecosystem Integration: Inclusion of secondary interviews with brokers, caregivers, and call center representatives

Communication and Collaboration:

• Close OC Partnership: Embedded collaboration with Office of Communications team throughout research phases

• Weekly sprint planning sessions with CMS digital services team

• Real-time insight sharing through dynamic dashboards and live readouts

• Stakeholder continuity with decision-making group throughout project lifecycle

• Government-specific considerations for data sharing and proprietary AI usage

Cost Drivers and Level of Effort:

• Research scope covering multiple geographic markets with diverse demographic representation

• Comprehensive deliverable package including personas, journey maps, and strategic recommendations

Technical Targets:

• Development of research artifacts that directly inform Medicare.gov redesign requirements

• Creation of user personas compatible with existing CMS design and development workflows

• Establishment of user experience metrics and success criteria for future platform iterations

• Integration planning with existing OC analytics platforms and technical infrastructure

Constraints

Government-Specific Constraints:

• Data Governance: All research activities must comply with federal privacy regulations and CMS data governance requirements

• AI and Proprietary Tools: Guardrails related to government data and proprietary AI usage, requiring close OC partnership

• Platform Limitations: Recognition that government sites have unique constraints compared to private sector platforms

• Regulatory Compliance: Research findings must support evidence-based policy and technical decision-making

Timeline and Integration Constraints:

• Very time-sensitive initiative (8-10 weeks completion time) as it will inform not only Medicare.gov but a number of key Administration initiatives, such as those related to interoperability

• Research must be completed within established timeline to inform upcoming platform development cycles (i.e. initiatives with OKRs due by EOY)

• Results must inform comprehensive implementation roadmap development

• Coordination required with ongoing Medicare.gov development and maintenance schedules

• Strategic alignment with broader OC digital transformation initiatives

Scalability and Sustainability Requirements:

• Internal Capability Building: Plan for developing permanent user research capabilities within OC

• Governance Structure: Establish framework for ongoing experience optimization

• Technology Integration: Explore opportunities to integrate JourneyAI insights with existing OC analytics platforms

• Long-term Partnership: Consider ongoing research capabilities with TripTK for continuous user feedback integration

Success Metrics:

• Delivery of actionable user personas that drive measurable improvements in user experience design and inform both Medicare.gov user experience as well as other key CMS/HHS initiatives

• Creation of comprehensive journey maps identifying specific technical and process improvement opportunities

• Establishment of baseline user experience metrics trackable over time

• Development of research insights directly contributing to increased user engagement and task completion rates

• Creation of comprehensive implementation roadmap for scaling successful interventions across Medicare.gov platform

APPENDIX A

1. Baseline Security Requirements

a. Applicability. The requirements herein apply whether the entire contract or modification (hereafter "contract"), or portion thereof, includes either or both of the following:

i. Access (Physical or Logical) to Government Information: A Contractor (and/or any subcontractor) will have or will be given the ability to have, routine physical (entry) or logical (electronic) access to government information.

ii. Operate a Federal System Containing Information: A Contractor (and/or any subcontractor) will operate a federal system and information technology containing data that supports the HHS mission. In addition to the Federal Acquisition Regulation (FAR) Subpart 2.1 definition of "information technology" (IT), the term as used in this section includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources.

b. Safeguarding Information and Information Systems. All government information and information systems must be protected in accordance with HHS/ CMS policies and level of risk. At a minimum, the Contractor (and/or any subcontractor) must:

i. Protect the:

▪ Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary information;

▪ Integrity, which means guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity; and

▪ Availability, which means ensuring timely and reliable access to and use of information.

ii. Categorize all information owned and/or collected/managed on behalf of HHS/CMS and information systems that store, process, and/or transmit HHS information in accordance with FIPS 199 and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. Based on information provided by the ISSO, CISO, CMS http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf

SOP, or other representative, the impact level for each Security Objective (Confidentiality, Integrity, and Availability) and the Overall Impact Level, which is the highest watermark of the three factors of the information or information system are the following:

▪ Confidentiality: [ ] Low [ ] Moderate [ ] High

▪ Integrity: [ ] Low [ ] Moderate [ ] High

▪ Availability: [ ] Low [ ] Moderate [ ] High

▪ Overall Impact Level: [ ] Low [ ] Moderate [ ] High

iii. Based on the agreed-upon level of impact, implement the necessary safeguards to protect all information systems and information collected and/or managed on behalf of HHS/CMS regardless of location or purpose.

iv. Report any discovered or unanticipated threats or hazards by either the agency or contractor, or if existing safeguards have ceased to function immediately after discovery, within one (1) hour or less, to the government representative(s).

v. Adopt and implement all applicable policies, procedures, controls, and standards required by the HHS/CMS Information Security Program to ensure the confidentiality, integrity, and availability of government information and government information systems for which the Contractor is responsible under this contract or to which the Contractor may otherwise have access under this contract.

Obtain all applicable security and privacy policies by contacting the CO/COR or HHS/CMS security and/or privacy officials.

c. Privacy Act. Comply with the Privacy Act requirements (when applicable), and tailor FAR and HHSAR clauses as needed.

d. Privacy Compliance. Comply with the E-Government Act of 2002, NIST SP 800-53, and applicable HHS/CMS privacy policies, and complete all the requirements below:

i. Per the Office of Management and Budget (OMB) Circular A-130, Personally Identifiable Information (PII), is "information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual." Examples of PII include, but are not limited to the following: Social Security number, date and place of birth, mother's maiden name, biometric records, etc.

ii. Based on information provided by the ISSO, system/data owner, or other security or privacy representative, it has been determined that this solicitation/contract involves:

[ ] No PII [ X ] PII

iii. The Contractor must support the agency with conducting a Privacy Threshold Analysis (PTA) for the information system and/or information handled under this contract to determine whether or not a full Privacy Impact Assessment (PIA) needs to be completed.

▪ If the results of the PTA show that a full PIA is needed, the Contractor must support the agency with completing a PIA for the system or information within [CMS to insert contract-specific timeline] after completion of the PTA and in accordance with HHS policy and OMB M-03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002.

▪ The Contractor must support the agency in reviewing the PIA at least every three years throughout the system development lifecycle (SDLC)/information lifecycle, or when determined by the agency that a review is required based on a major change to the system, or when new types of PII are collected that introduces new or increased privacy risks, whichever comes first.

e. Controlled Unclassified Information (CUI). Executive Order 13556 defines CUI as "information that laws, regulations, or Government-wide policies require to have safeguarding or dissemination controls, excluding classified information." The Contractor (and/or any subcontractor) must comply with Executive Order 13556, Controlled Unclassified Information, (implemented at 3 CFR, part 2002) when handling CUI. 32 C.F.R. 2002.4(aa) As implemented the term "handling" refers to "…any use of CUI, including but not limited to marking, safeguarding, transporting, disseminating, re-using, and disposing of the information." 81 Fed. Reg. 63323. The requirements below apply only to nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components. All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, must be:

i. Marked appropriately;

ii. Disclosed to authorized personnel on a Need-To-Know basis;

iii. Protected in accordance with NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations applicable baseline if handled by a Contractor system operated on behalf of the agency, or NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations if handled by internal Contractor system; and

iv. Returned to HHS control, destroyed when no longer needed, or held until otherwise directed. Information and/or data must be disposed of in accordance with NIST SP 800-88, Guidelines for Media Sanitization.

f. Protection of Sensitive Information. For security purposes, information is or may be sensitive because it requires security to protect its confidentiality, integrity, and/or availability. The Contractor (and/or any subcontractor) must protect all government information that is or may be sensitive by securing it with a solution that is validated with current FIPS 140 validation certificate from the NIST CMVP.

g. Confidentiality and Nondisclosure of Information. Any information provided to the contractor (and/or any subcontractor) by HHS or collected by the contractor on behalf of HHS must be used only for the purpose of carrying out the provisions of this contract and must not be disclosed or made known in any manner to any persons except as may be necessary in the performance of the contract. The Contractor assumes responsibility for protection of the confidentiality of Government records and must ensure that all work performed by its employees and subcontractors must be under the supervision of the Contractor. Each Contractor employee or any of its subcontractors to whom any HHS records may be made available or disclosed must be notified in writing by the Contractor that information disclosed to such employee or subcontractor can be used only for that purpose and to the extent authorized herein.

The confidentiality, integrity, and availability of such information must be protected in accordance with HHS and CMS policies. Unauthorized disclosure of information will be subject to the HHS/CMS sanction policies and/or governed by the following laws and regulations:

i. 18 U.S.C. 641 (Criminal Code: Public Money, Property or Records);

ii. 18 U.S.C. 1905 (Criminal Code: Disclosure of Confidential

Information); and

iii. 44 U.S.C. Chapter 35, Subchapter I (Paperwork Reduction Act).

h. Internet Protocol Version 6 (IPv6). All procurements using Internet Protocol must comply with OMB Memorandum M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6).

i. Information and Communications Technology (ICT). ICT products and services from prohibited entities/sources must not be used/acquired in compliance with Public Law 115-232, Section 889 Parts A and B, FAR 4.21, FAR 52.204.23, FAR 52.204.24, and FAR 52.204.25. The contractor (and/or any subcontractor) must notify the government if they identify prohibited ICT products and/or services are used during the contract performance.

j. Government Websites. All new and existing public-facing government websites must be securely configured with Hypertext Transfer Protocol Secure (HTTPS) using the most recent version of Transport Layer Security (TLS). In addition, HTTPS must enable HTTP Strict Transport Security (HSTS) to instruct compliant browsers to assume HTTPS at all times to reduce the number of insecure redirects and protect against attacks that attempt to downgrade connections to plain HTTP. For internal-facing websites, HTTPS is not required, but it is highly recommended. Consult the HHS Policy for Internet and Email Security for additional information.

k. Contract Documentation. The Contractor must use provided templates, policies, forms and other agency documents found at https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS- Information-Technology/InformationSecurity/Information-Security-Library to comply with contract deliverables as appropriate.

Standard for Encryption. The Contractor (and/or any subcontractor) must:

i. Comply with the HHS Standard for Encryption of Computing Devices and Information to prevent unauthorized access to government information.

ii. Encrypt all sensitive federal data and information (i.e., PII, protected health information [PHI], proprietary information, etc.) in transit (i.e., email, network connections, etc.) and at rest (i.e., servers, storage devices, mobile devices, backup media, etc.) with encryption solution that is validated with current FIPS 140 validation certificate from the

NIST CMVP.

iii. Secure all devices (i.e.: desktops, laptops, mobile devices, etc.) that store and process government information and ensure devices meet HHS and CMS-specific encryption standard requirements. Maintain a complete and current inventory of all laptop computers, desktop computers, and other mobile devices and portable media that store or process sensitive government information (including PII).

iv. Verify that the encryption solutions in use have been validated under the Cryptographic Module Validation Program to confirm compliance with current FIPS 140 validation certificate from the NIST CMVP. The Contractor must provide a written copy of the validation documentation to the COR [CMS-provided delivery date].

v. Use the Key Management system on the HHS personal identification verification (PIV) card or establish and use a key recovery mechanism to ensure the ability for authorized personnel to encrypt/decrypt information and recover encryption keys http://csrc.nist.gov/publications/. Encryption keys must be provided to the COR upon request and at the conclusion of the contract.

l. Contractor Non-Disclosure Agreement (NDA). Each Contractor (and/or any subcontractor) employee having access to non-public government information under this contract must complete the CMS non-disclosure agreement. Contractors (and/or subcontractors) must submit a copy of each signed and witnessed NDA to the Contracting Officer (CO) and/or CO Representative (COR) prior to performing any work under this acquisition.

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library http://csrc.nist.gov/publications/

2. Training Requirements

a. Mandatory Training for All Contractor Staff. All Contractor (and/or any subcontractor) employees assigned to work on this contract must complete the applicable HHS/CMS Contractor Information Security Awareness, Privacy, and Records Management training (provided upon contract award) before performing any work under this contract. Thereafter, the employees must complete CMS Information Security Awareness, Privacy, and Records Management training at least annually, during the life of this contract. All provided training must be compliant with HHS training policies.

b. Role-based Training. All Contractor (and/or any subcontractor) employees with significant security responsibilities (as determined by the program manager) must complete role-based training annually commensurate with their role and responsibilities in accordance with HHS policy and the HHS Role-Based Training (RBT) of Personnel with Significant Security Responsibilities Memorandum.

c. Training Records. The Contractor (and/or any subcontractor) must maintain training records for all its employees working under this contract in accordance with HHS policy. A copy of the training records must be provided to the CO and/or COR within 30 days after contract award and annually thereafter or upon request.

3. Rules of Behavior

a. The Contractor (and/or any subcontractor) must ensure that all employees performing on the contract comply with the HHS Information Technology General Rules of Behavior, and HHS Rules of Behavior for Privileged Users.

b. All Contractor employees performing on the contract must read and adhere to the Rules of Behavior before accessing Department data or other information, systems, and/or networks that store/process government information, initially at the beginning of the contract and at least annually thereafter, which may be done as part of annual CMS Information Security Awareness Training. If the training is provided by the contractor, the signed ROB must be provided as a separate deliverable to the CO and/or COR per defined timelines above.

4. Incident Response

a. The Contractor (and/or any subcontractor) must respond to all alerts/Indicators of Compromise (IOCs) provided by HHS Computer Security Incident Response Center (CSIRC)/ CMS IRT teams within 24 hours, whether the response is positive or negative.

FISMA defines an incident as "an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. In accordance with OMB M-17- 12, Preparing for and Responding to a Breach of Personally Identifiable

Information (PII), an incident is "an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies" and a privacy breach is "the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where (1) a person other than an authorized user accesses or potentially accesses personally identifiable information or (2) an authorized user accesses or potentially accesses personally identifiable information for an other than authorized purpose." For additional information on the HHS breach response process, please see the HHS Policy and Plan for Preparing for and Responding to a Breach of Personally Identifiable Information (PII)."

b. In the event of a suspected or confirmed incident or breach, the Contractor (and/or any subcontractor) must:

i. Protect all sensitive information, including any PII created, stored, or transmitted in the performance of this contract, with encryption solution that is validated with current FIPS 140 validation certificate from the NIST CMVP.

ii. NOT notify affected individuals unless so instructed by the Contracting Officer or designated representative. If so instructed by the Contracting Officer or representative, the Contractor must send CMS approved notifications to affected individuals in accordance with the CMS Breach Analysis Team (BAT) instruction.

iii. Report all suspected and confirmed information security and privacy incidents and breaches to the CMS Incident Response Team (IRT) via the CMS Help Desk (410) 786-2580 or CMS IT Service Desk (cms_it_service_desk@cms.hhs.gov), COR, CO, CMS SOP (or his or her designee), and other stakeholders, including breaches involving PII, in any medium or form, including paper, oral, or electronic, as soon as possible and without unreasonable delay, no later than one

(1) hour, and consistent with the applicable CMS and HHS policy and procedures, NIST standards and guidelines, as well as US-CERT notification guidelines. The types of information required in an incident report must include at a minimum: company and point of contact information, contact information, impact classifications/threat vector, and the type of information compromised. In addition, the Contractor must:

▪ Cooperate and exchange any information, as determined by the Agency, necessary to effectively manage or mitigate a suspected or confirmed breach;

▪ Not include any sensitive information in the subject or body of any reporting e-mail; and

▪ Encrypt sensitive information in attachments to email, media, etc.

iv. Comply with OMB M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information, and HHS/CMS privacy breach response policies when handling PII breaches.

v. Provide full access and cooperate on all activities as determined by the Government to ensure an effective incident response, including providing all requested images, log files, and event information to facilitate rapid resolution of sensitive information incidents. This may involve disconnecting the system processing, storing, or transmitting the sensitive information from the Internet or other networks or applying additional security controls. This may also involve physical access to contractor facilities during a breach/incident investigation.

5. Position Sensitivity Designations All Contractor (and/or any subcontractor) employees must obtain a background investigation commensurate with their position sensitivity designation that complies with Parts 1400 and 731 of Title 5, Code of Federal Regulations (CFR). The following position sensitivity designation levels apply to this solicitation/contract:

6. Homeland Security Presidential Directive (HSPD)-12 The Contractor (and/or any subcontractor) and its employees must comply with Homeland Security Presidential Directive (HSPD)-12, Policy for a Common Identification Standard for Federal Employees and Contractors; OMB M-05-24; OMB M-19-17; FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors; HHS HSPD-12 policy; and Executive Order 13467, Part 1 §1.2.

7. Roster The Contractor (and/or any subcontractor) must submit a roster by name, position, e-mail address, phone number and responsibility, of all staff working under this acquisition where the Contractor will develop, have the ability to access, or host and/or maintain a government information system(s). The roster must be submitted to the COR and/or CO within a timeframe to be determined by CMS of the effective date of this contract. Any revisions to the roster as a result of staffing changes must be submitted within a timeframe to be determined by CMS of the change. The COR will notify the Contractor of the appropriate level of investigation required for each staff member.

If the employee is filling a new position, the Contractor must provide a position description and the Government will determine the appropriate suitability level.

8. Contract Initiation and Expiration

a. General Security Requirements. The Contractor (and/or any subcontractor) must comply with information security and privacy requirements, Enterprise Performance Life Cycle (EPLC) processes, HHS Enterprise Architecture requirements to ensure information is appropriately protected from initiation to expiration of the contract. All information systems development or enhancement tasks supported by the contractor must follow the HHS EPLC framework and methodology or the CMS SDLC, as amended and in accordance with the HHS Contract Closeout Guide (2012).

b. System Documentation. Contractors (and/or any subcontractors) must follow and adhere to HHS System Development Life Cycle requirements, at a minimum, for system development and provide system documentation at designated intervals (specifically, at the expiration of the contract) within the EPLC and CMS SDLC that require artifact review and approval.

c. Sanitization of Government Files and Information. As part of contract closeout and at expiration of the contract, the Contractor (and/or any subcontractor) must provide all required documentation in accordance with the CMS SDLC, as Amended to the CO and/or COR to certify that, at the government's direction, all electronic and paper records are appropriately disposed of and all devices and media are sanitized in accordance with NIST SP 800-88, Guidelines for Media Sanitization.

d. Notification. The Contractor (and/or any subcontractor) must notify the CO and/or COR and system ISSO within as soon as possible or as determined by CMS before an employee stops working under this contract.

e. Contractor Responsibilities upon Physical Completion of the Contract.

The contractor (and/or any subcontractors) must return all government information and IT resources (i.e., government information in non-government-owned systems, media, and backup systems) acquired during the term of this contract to the CO and/or COR. Additionally, the Contractor must provide a certification that all government information has been properly sanitized and purged from Contractor-owned systems, including backup systems and media used during contract performance, in accordance with HHS and/or CMS policies.

f. The Contractor (and/or any subcontractor) must perform and document the actions identified the COR when an employee terminates work under this contract within 30 calendar days of the employee's exit from the contract. All documentation must be available to the CO and/or COR upon request.

9. Records Management and Retention

a. The Contractor (and/or any subcontractor) must maintain all information in accordance with Executive Order 13556 -- Controlled Unclassified Information, National Archives and Records Administration (NARA) records retention policies and schedules and HHS Policy for Records Management and CMS policies and must not dispose of any records unless authorized by HHS/CMS.

b. In the event that a contractor (and/or any subcontractor) accidentally disposes of or destroys a record without proper authorization, he/she must document and report the incident in accordance with HHS/CMS policies.

High Value Asset (HVA) If a system is identified as HVA, the contractor must comply with the HHS Policy for the High Value Asset (HVA) Program and the DHS HVA Control Overlay in addition to the above requirements

Privacy Act

It has been determined that this contract is subject to the Privacy Act of 1974, because this contract provides for the design, development, or operation of a system of records about individuals from which records are retrieved by name or other identifying particular.

The System of Records Notice that is applicable to this contract is: 09-70-0535 1-800 Medicare (HELPLINE)

The system of records design, development, or operation work the Contractor is to perform is:

The disposition to be made of the Privacy Act records upon completion of contract performance is: [

1. Security Requirements for GOCO and COCO Resources

a. Federal Policies. The Contractor (and/or any subcontractor) must comply with applicable federal laws and HHS policies that include, but are not limited to, the HHS Information Security and Privacy Policy (IS2P), CMS Information Systems Security and Privacy Policy (IS2P2), Federal Information Security Modernization Act (FISMA) of 2014, (44 U.S.C. 101); National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, latest revision, Security and Privacy Controls for Information Systems and Organizations; Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource; and other applicable federal laws, regulations, NIST guidance, and Departmental policies.

b. Assessment and Authorization (A&A). A valid authority to operate (ATO) certifies that the Contractor's information system meets the contract's requirements to protect the agency data. If the system under this contract does not have a valid ATO, the Contractor (and/or any subcontractor) must work with the agency and supply the deliverables required to complete the ATO within the specified timeline(s) to be determined by CMS. The Contractor must conduct the A&A requirements in accordance with HHS IS2P/ CMS IS2P2, NIST SP 800-37, Guide for Applying the Risk Management Framework to Information Systems: A Security Life Cycle Approach (latest revision), NIST SP 800-53B, Control Baselines for Information Systems and Organizations, and the NIST SP 800-53A (latest revision).

CMS acceptance of the ATO does not alleviate the Contractor's responsibility to ensure the system security and privacy controls are implemented and operating effectively.

i. A&A Package Deliverables - The Contractor (and/or any subcontractor) must provide an A&A package within as determined by CMS to the CO and/or COR. The following A&A deliverables are required to complete the A&A package :

▪ System Security Plan (SSP) – due prior to the submission of the A&A package in order to request an ATO, based on the CFACTS format template. The SSP must comply with the NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems, the Federal Information Processing Standard (FIPS) 200, Recommended Security Controls for Information Systems, and NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations applicable baseline requirements, and other applicable NIST guidance as well as HHS and CMS policies and other guidance. The SSP must be consistent with and detail the approach to IT security contained in the Contractor's bid or proposal that resulted in the award of this contract. The SSP must provide an overview of the system environment and security requirements to protect the information system as well as describe all applicable security controls in place or planned for meeting those requirements. It should provide a structured process for planning adequate, cost-effective security protection for a system. The Contractor must review and update the SSP at least annually thereafter and if requested, provide a copy of the updated SSP.

▪ Security Assessment Plan/Report (SAP/SAR) - due prior to the ATO. The security assessment must be conducted by a third party assessor for High and Moderate systems, or by an independent assessor for Low systems and be consistent with NIST SP 800-53A, NIST SP 800-30, and HHS and CMS policies.

The assessor will document the assessment results in the SAR.

Thereafter, the Contractor, in coordination with CMS must assist in the assessment of the security controls initially and update the SAR at least annually. A copy of the updated SAR should be provided if requested.

▪ Independent Assessment – due as required by CMS. The Contractor (and/or subcontractor) must have an independent third-party validate the security and privacy controls in place for the system(s) commensurate with the risk levels per NIST SP 800-53B. The independent third party must review and analyze the Security Authorization package, and report on technical, operational, and management level deficiencies as outlined in NIST SP 800-53. The Contractor must address all "high" deficiencies before submitting the package to the Government for accreditation and/or acceptance and document all remaining deficiencies in a system Plan of Actions and Milestones (POA&M).

▪ POA&M – due within 30 days after the independent third-party assessment final report approval and must be created in CFACTS. All critical-risk weaknesses must be mitigated within 15 days, high-risk weaknesses must be mitigated within 30 days, medium weaknesses must be mitigated within 90 days, and low weaknesses must be mitigated 365 days, from the date the weaknesses are formally identified and documented. CMS will determine the risk rating of vulnerabilities. Identified risks stemming from deficiencies related to the security control baseline implementation, assessment, continuous monitoring, vulnerability scanning, flaws and security defect in a system (that require to create a patch for remediation), and other security reviews and sources, as documented in the SAR, must be documented and tracked by the Contractor for mitigation in the POA&M document consistent with the HHS Standard for Plan of Action and Milestones and CMS policies. Depending on the severity of the risks, CMS may require designated POA&M weaknesses to be remediated before an ATO is issued. Thereafter, continue to remediate weaknesses throughout the contract. The POA&M document must be updated at least quarterly in CFACTS.

▪ Contingency Plan and Contingency Plan Test – due prior to the ATO and updated annually thereafter. The Contingency Plan must be developed in accordance with NIST SP 800- 34, Contingency Planning Guide for Federal Information Systems, and be consistent with HHS and CMS policies. Upon acceptance by the System Owner, the Contractor, in coordination with the System Owner, must test the

Contingency Plan and prepare a Contingency Plan Test Report that includes the test results, lessons learned and any action items that need to be addressed. Thereafter, the Contractor must update and test the Contingency Plan at least annually.

▪ E-Authentication Questionnaire - The contractor (and/or any subcontractor) must collaborate with government personnel to ensure that the E-Authentication requirements are implemented in accordance with OMB 04-04 and NIST SP 800- 63 B.

Based on the level of assurance determined by the E-Auth, the Contractor (and/or subcontractor) must ensure appropriate authentication to the system, including remote authentication, is in-place in accordance with the assurance level determined by the E-Auth (when required) in accordance with HHS Guidance for Selection of e-Authentication Assurance Levels and any other applicable HHS/CMS policies.

ii. Information Security Continuous Monitoring. Upon the government issuance of an Authority to Operate (ATO), the Contractor (and/or subcontractor)-owned/operated systems that input, store, process, output, and/or transmit government information, must meet or exceed the information security continuous monitoring (ISCM) requirements in accordance with FISMA and NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, HHS ISCM Strategy, HHS IS2P and CMS IS2P2.

iii. Annual Assessment/Penetration (Pen) Test - Assess the system security and privacy controls (or ensure an assessment of the controls is conducted) at least annually to determine the implemented security and privacy controls are operating as intended and producing the desired results (this involves penetration testing conducted by the agency or independent third-party.) In addition, review all relevant A&A documentation (SSP, POA&M, Contingency Plan, etc.) and provide updates by specified due date to be determined by CMS.

iv. Asset Management - Using any available Security Content Automation Protocol (SCAP)-compliant automated tools for active/passive scans, provide an inventory of all information technology (IT) assets for hardware and software, (computers, servers, routers, databases, operating systems, etc.) that are processing HHS/CMS-owned information/data. It is anticipated that this inventory information will be required to be produced at least every 72 hours. IT asset inventory information must include IP address, machine name, operating system level, security patch level, and SCAP-compliant format information. The contractor must maintain a capability to provide an inventory of 100% of its IT assets using SCAP-compliant automated tools in accordance with the HHS Policy for Information Technology Asset Management (ITAM) and any other applicable HHS policy.

v. Configuration Management - Use available SCAP-compliant automated tools as per NIST IR 7511 and HHS Minimum Security Configurations Standards Guidance to scan all IT assets, including but not limited to: computers, servers, routers, databases, operating systems, application, etc., that store and process government information. Provide scan reports to HHS/CMS upon request. The contractor must maintain a capability to provide security configuration compliance information for 100% of its IT assets using SCAP-compliant automated tools.

vi. Vulnerability Management - Contractors must actively manage system vulnerabilities using automated tools and technologies where practicable and in accordance with HHS Policy for Vulnerability Management. Automated tools must be compliant with NIST-specified SCAP standards for vulnerability identification and management. The contractor must maintain a capability to provide security vulnerability scanning information for 100% of IT assets using SCAP-compliant automated tools and report to the agency at least every 72 hours.

vii. Patching and Vulnerability Remediation - Install vendor released security patches and remediate critical and high vulnerabilities in systems processing government information in an expedited manner, within vendor and CMS specified timeframes:

▪ Critical vulnerabilities require patching to be released and remediated within 15 days

▪ High vulnerabilities require patching to be released and remediated within 30 days

viii. Secure Coding - Follow the HHS Policy for Software Development Secure Coding Practices and secure coding best practice requirements, as directed by United States Computer Emergency Readiness Team (US-CERT) specified standards and the Open Web Application Security Project (OWASP), that will limit system software vulnerability exploits.

ix. Boundary Protection - The contractor must ensure that government information, other than unrestricted information, being transmitted from federal government entities to external entities is routed through a Trusted Internet Connection (TIC).

c. Government Access for Security Assessment. In addition to the Inspection Clause in the contract, the Contractor (and/or any subcontractor) must afford the Government access to the Contractor's facilities, installations, operations, documentation, information systems, and personnel used in performance of this contract to the extent required to carry out a program of security assessment (to include vulnerability testing), investigation, and audit to safeguard against threats and hazards to the confidentiality, integrity, and availability of federal data or to the protection of information systems operated on behalf of HHS/CMS, including but are not limited to:

i. At any tier handling or accessing information, consent to and allow the Government, or an independent third party working at the Government's direction, without notice at any time during a weekday during regular business hours contractor local time, to access contractor and subcontractor installations, facilities, infrastructure, data centers, equipment (including but not limited to all servers, computing devices, and portable media), operations, documentation (whether in electronic, paper, or other forms), databases, and personnel which are used in performance of the contract.

The Government includes but is not limited to the U.S. Department of Justice, U.S. Government Accountability Office, and the HHS Office of the Inspector General (OIG). The purpose of the access is to facilitate performance inspections and reviews, security and compliance audits, and law enforcement investigations. For security audits, the audit may include but not be limited to such items as buffer overflows, open ports, unnecessary services, lack of user input filtering, cross site scripting vulnerabilities, SQL injection vulnerabilities, and any other known vulnerabilities.

ii. At any tier handling or accessing protected information, fully cooperate with all audits, inspections, investigations, forensic analysis, or other reviews or requirements needed to carry out requirements presented in applicable law or policy. Beyond providing access, full cooperation also includes, but is not limited to, disclosure to investigators of information sufficient to identify the nature and extent of any criminal or fraudulent activity and the individuals responsible for that activity. It includes timely and complete production of requested data, metadata, information, and records relevant to any inspection, audit, investigation, or review, and making employees of the contractor available for interview by inspectors, auditors, and investigators upon request. Full cooperation also includes allowing the Government to make reproductions or copies of information and equipment, including, if necessary, collecting a machine or system image capture.

▪ Segregate Government protected information and metadata on the handling of Government protected information from other non-government information. Commingling of information is prohibited.