PR_31512_-_Cells_and_Reagents_Ordering_System_Software_RFQ.pdf

REQUEST FOR QUOTATIONS

(THIS IS NOT AN ORDER)

THIS RFQ IS IS NOT A SMALL BUSINESS SET-ASIDE.

PAGE OF PAGES

1 34

1. REQUEST NO.

75D301-19-Q-70223

2. DATE ISSUED

05/21/2019

3. REQUISITION/PURCHASE REQUEST NO.

000HCVLH-2019-31512

4. CERT. FOR NAT. DEF.

UNDER BDSA REG. 2

AND/OR DMS REG. 1

RATING

5a. ISSUED BY

Centers for Disease Control and Prevention (CDC)

Office of Acquisition Services (OAS)

2900 Woodcock Blvd, MS TCU-4

Atlanta GA 303414004

6. DELIVERY BY (Date)

5b. FOR INFORMATION CALL (No collect calls)

NAME TELEPHONE NUMBER

AREA CODE NUMBER

Keeshia L. Pettis (770) 729-4280 x

8. TO: 9. DESTINATION

a. NAME b. COMPANY a. NAME OF CONSIGNEE

c. STREET ADDRESS b. STREET ADDRESS

c. CITY

d. CITY e. STATE f. ZIP CODE d. STATE e. ZIP CODE

10. PLEASE FURNISH QUOTATIONS TO

THE ISSUING OFFICE IN BLOCK 5a ON OR BEFORE CLOSE OF BUSINESS (Date)

IMPORTANT: This is a request for information, and quotations furnished are not offers. If you are unable to quote, please so indicate on this form and return it. This request does not commit the Government to pay any costs incurred in the preparation of the submission of this quotation or to contract for supplies or services.

Supplies are of domestic origin unless otherwise indicated by quoter. Any representations and/or certifications attached to this Request for Quotations must be completed by the quoter.

11. SCHEDULE (Include applicable Federal, State and local taxes)

ITEM NO.

(a)

SUPPLIES/SERVICES

(b)

QUANTITY

(c)

UNIT

(d)

UNIT PRICE

(e)

AMOUNT

(f)

For additional information please contact

Keeshia Pettis @ 770-729-4280

12. DISCOUNT FOR PROMPT PAYMENT

a. 10 CALENDAR DAYS

b. 20 CALENDAR DAYS

c. 30 CALENDAR DAYS

d. CALENDAR DAYS

NUMBER PERCENTAGE

NOTE: Additional provisions and representations are are not attached.

13. NAME AND ADDRESS OF QUOTER 14. SIGNATURE OF PERSON AUTHORIZED TO

SIGN QUOTATION

15. DATE OF

QUOTATION

a. NAME OF QUOTER

b. STREET ADDRESS 16. SIGNER

a. NAME (Type or print) b. TELEPHONE

c. COUNTY AREA CODE

d. CITY e. STATE f. ZIP CODE c. TITLE (Type or print) NUMBER

AUTHORIZED FOR LOCAL REPRODUCTION STANDARD FORM 18 (REV. 6-95)

Previous edition not usable Prescribed by GSA FAR (48 CFR) 53.215-1(a)

7. DELIVERY

FOB

DESTINATION

OTHER

(See Schedule)

Line Items

ITEM SUPPLIES / SERVICES QTY / UNIT UNIT PRICE EXTENDED PRICE

0001 Build System Framework

40 Hours

0002 Build Tracking and Ordering System

400 Hours

0003 Support for Local Installation

1 Each

0004 Annual Support

1 Each

0005 Other Features and Mods

100 Hours

Statement of Work

Title of Project:

Ordering System for Cells and Reagents (OSCaR)

BACKGROUND AND NEED

The Reagents, Cell Lines, and Media Team (RCLM) in the Reagent and Diagnostic Services Branch (RDSB) is responsible for the production of buffers, stains, dyes, cell lines, and microbiological and cell culture media for CDC laboratories. These products are used in fulfillment of their surveillance, diagnostic, and outbreak response missions.

In order to fulfill our mission, we must be able receive, track, and produce orders for these products with high efficiency and quality. Our current Biologics Information and Ordering System is built with antiquated technology and does not support the full array of functions that are required to ensure current expectations for security and quality are consistently met. We need a modern and secure web based ordering, production, quality, and reporting system.

PROJECT OBJECTIVES

The purpose of the purchase is to provide the Branch with a web based database system to fulfil our obligations to our customers for high quality buffers, stains, dyes, cell lines, and microbiological and cell culture media. In addition to complying with ITSO security standards, the web based database system would decrease turnaround time and reduce human errors for the production of these products and help us to better serve our customers.

SCOPE OF WORK

The RCLM Team in RDSB is currently facing a data management shortfall with respect to its ability to receive, produce, track, release, and create reports for its orders. The existing web based system is antiquated (~20 years old), requires frequent and costly maintenance and updates, and is no longer able to accept new formulations or modifications to existing ones. Management of rush orders for outbreaks, new formulations, and other core functions must take place through workarounds and fixes external to the existing system. The inability to produce reports based on important criteria exacerbates the difficulties of using the current system and is having a negative impact on the Team’s ability to respond appropriately to pathogen outbreaks and surveillance. The inability to track order assignments from within the system has resulted in confusion and duplication of efforts within the Team. The current system is also unable to provide costing information to either customers or the Branch, resulting in further workarounds to perform basic accounting tasks. The Team needs to be able to receive production requests electronically, integrate these requests into laboratory workflows, store and manage the products through quality and quantity assessment, quality control, and data analysis, deliver resultant products and data reports to the customers, as well as allow them to track their production requests through different stages of production. In addition, customers need the capability to get pricing information during the ordering process, and RDSB management needs the ability to adjust pricing based on changing resource and raw materials costs. These capabilities will provide greater transparency of the production processes and workflows, better communication, improved laboratory efficiency, and automate processes that will reduce administrative burden and increase the satisfaction of customers. In addition to the requirements below, there are additional requirements associated with this project that are contained in process maps, output documents, and screen mockups.

1) TECHNICAL REQUIREMENTS

a) The System must be a web-based system hosted within CDC

b) The System must not require software to be installed on the customer’s or Lab user’s computers.

c) The System must allow hosting on a Linux based server.

d) The System must be able to serve at-least 500 simultaneous connections

e) The System must be able to allow authentication through CDC-AD or LDAP servers.

f)

2) FUNCTIONAL REQUIREMENTS

a) General Requirements

i) The System must support Role Based Authentication and Access Control.

ii) The System must accommodate the following Roles (but not limited to):

Production Scientist, Orderer, Quality, Order Manager, and Administrator

iii) The System must be able to track/retrieve all information associated with each order, formulation, container, etc.

iv) The System must be able to generate a “Device History Record” for each product ordered and each cell line pool

v) The System must be able to update status of order (Submitted, In Process, In

Review, Released, Cancelled).

vi) The System must be able to generate the below pre-canned and customized reports.

(1) Data Dump

(2) Overdue report

(3) Raw material usage report

(4) DDR Report

(5) In Process Report

(6) In Review Report

(7) EPR Report

(8) Released Report

(9) Audit Report

(10) Notifications Report

(11) Estimated time required report

(12) Active cell lines

(13) Orders assigned to Production Scientist

vii) The System must be able to track orders that are remade but display only the released/final information to the customer viii)The System must be able to track, allow for review and approval, and prioritize rush orders.

ix) The System must be able to produce email notifications including:

(1) Order placed

(2) Order cancelled

(3) Lot released

(4) DDR Pending

(5) DDR

(6) Lot in review

(7) EPR Order Placed

(8) EPR Status Update

(9) Order has been modified

x) The System must be able to generate an audit trail.

xi) The System must be able to create an itemized invoice for customers.

xii) The System must be able to generate pricing before an order is placed.

xiii)The System must be able to calculate updating pricing in real time upon changing of one of the pricing parameters including:

(1) Raw material cost

(2) Stock production cost

(3) Container cost

(4) Labor cost

(5) Quality cost

(6) Surcharge

xiv) The System must be able to conduct searches of orders based on the below parameters:

(1) Order Number

(2) Lot Number

(3) Product Number

(4) Product Description

(5) Category

(6) Status

(7) EPR

(8) Date Submitted (Order)

(9) Date Under Review (Lot)

(10) Date Released (Lot)

(11) Date Released (Order)

(12) Production Scientist

(13) Orderer User ID

(14) Backup Contact User ID

(15) Customer User ID

(16) Customer Name

(17) Customer Admin Code

xv) The System searches should be able to return the below parameters:

(1) Order #

(2) Date Submitted

(3) Product Name

(4) Product #

(5) Container

(6) # of containers

(7) Fill Volume

(8) Concentration

(9) Date Needed

(10) Date Released

(11) Orderer

(12) Backup contact

(13) Customer

(14) Prodn Scientist

(15) Pooled?

(16) Status

xvi) The System must allow for the creation, storage, and maintenance of the following product parameters:

(1) Product ID

(2) Product Description

(3) Category

(4) Shelf Life

(5) Initial pH

(6) Final pH

(7) Osmolality

(8) Conductivity

(9) QC Instructions

(10) Safety Instructions

(11) Ingredients

(12) Directions

b) Cell Line Specific Requirements

i) The System must be able to pool orders of a single, or in some cases, varying cell types into a single pool for production.

c) Reagents and Media Specific Requirements

i) The System must be able to calculate the appropriate quantity of raw materials based on the final build volume of the product requested and adjusted by the Production Scientist.

d) Orderer Interface Requirements

i) The System must allow the customer to place a new order.

ii) The System must be able to populate predefined fields such as name, organization, phone number, email, name of PI, etc. based on information pulled from the MISO database

iii) The System must allow the customer to choose the type of order in the beginning and guide the user with correct prompts to place the appropriate order.

iv) The System must allow the customer to choose from pre-populated options based on the order (container type, fill volume, etc.)

v) The System must allow individual/multiple items in each order but assign a unique tracking number to each item ordered.

vi) The System must validate each item for correctness and prompt the user to correct any mistakes.

vii) The System must allow the customer to modify or cancel a pending order so long as it remains in Submitted status

viii) The System must allow the customer to view the status of the order.

ix) The System must allow the customer to view order history.

x) The System must allow the customer to clone previous orders and modify them before final order submission.

xi) The System must allow the customer to view or print final release forms.

xii) The System must allow a customer to view (or copy) the orders for their lab member but not the ability to modify them.

xiii) The System must require the orderer to specify a backup contact and allow the orderer to specify a customer to whom the order will be charged.

xiv) The System must allow the customer to specify the following parameters depending on order type:

(1) Product Number

(2) Container

(3) Fill Volume (ml)

(4) Number of Containers

(5) Closure

(6) Insert

(7) Sterilize?

(8) Concentration

(9) Special Instructions

(10) Date Needed

(11) Order requires early production?

(12) Early Production Request Details

(13) CAN

(14) Backup Contact User ID

(15) Backup Contact Name

(16) Customer ID, if not person placing order

e) Order Manager Interface

i) The System must notify the order manager when a rush order is submitted via an email.

ii) The System must allow for the assignment of an order to an individual or to several production scientists.

f) Administration Interface

i) The System must allow admin to view audit trail.

ii) The System must allow admin all rights, including the creation, modification, and deletion of products, containers, and inserts, the addition and deletion users to the various roles, the adjustment of all pricing parameters, the adjustment of delivery timelines, etc.

iii) The System must allow publication of guides and FAQs as links or web pages.

iv) The System must allow admin to add, modify or delete guides and FAQs as needed.

v) The System must allow admin to add, modify or delete the pre-populated options.

vi) The System must allow the admin to designate certain order related fields as internal and hidden from customers.

g) Production Scientist Interface

i) The System must allow the Production Scientist to create DHRs for Cell Lines and for all other products

h) Quality Interface

i) The System must allow for the review, release, rejection, or recall of lots and orders.

i) Reporter Interface

i) The System must allow a reporter role that has read access only.

ii) The Reporter should be able to create pre-canned and customized reports.

iii) The Reporter should be able to generate reports on periodic usage (weekly, monthly, yearly), per account usage, orders by type etc.

iv) These reports should be available in csv, xls, xlsx and pdf.

3) TRAINING REQUIREMENTS

a) The System training must be able to be conducted in the following formats: by video teleconference or WebEx and/or onsite instructor led.

4) IMPLEMENTATION REQUIREMENTS

a) Vendor shall provide system requirements documents detailing the minimum and recommended computer system requirements for their system.

b) The Vendor shall provide phone and/or onsite technical support for the installation and customization of the software.

5) SUPPORT REQUIREMENTS

a) Vendor shall provide phone/email support for urgent requests on 24/7 basis

b) Vendor shall provide maximum 48 hour turnaround for non-urgent requests

c) Vendor shall provide support for bug fixes and system errors.

6) SECURITY CONSIDERATIONS

The below information complies with CDC Security and Privacy compliance requirements for E-Government Act of 2002 (FISMA 2002) and Federal Information Security Modernization Act of 2014 (FISMA 2014)

Security Compliance

� If the contractor will host or create an information system on behalf of the CDC, provide IT services to the CDC, or provide IT products to the CDC, then the contractor shall comply with the applicable IT security references below (Standards 1

- 3).

Standard-1: Procurements Requiring Information Security and/or Physical Access

Security

A. Baseline Security Requirements

1) Applicability. The requirements herein apply whether the entire contract or order

(hereafter “contract”), or portion thereof, includes either or both of the following:

a. Access (Physical or Logical) to Government Information: A Contractor (and/or any subcontractor) employee will have or will be given the ability to have, routine physical

(entry) or logical (electronic) access to government information.

b. Operate a Federal System Containing Information: A Contractor (and/or any subcontractor) employee 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.

2) Safeguarding Information and Information Systems. In accordance with the Federal

Information Processing Standards Publication (FIPS)199, Standards for Security

Categorization of Federal Information and Information Systems, the Contractor (and/or any subcontractor) shall:

a. Protect government information and information systems in order to ensure:

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

b. Provide security for any Contractor systems, and information contained therein, connected to an HHS network or operated by the Contractor on behalf of HHS regardless of location. In addition, if new or unanticipated threats or hazards are discovered by either the agency or contractor, or if existing safeguards have ceased to function, the discoverer shall immediately, within one (1) hour or less, bring the situation to the attention of the other party.

c. Adopt and implement the policies, procedures, controls, and standards required by the

HHS 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 the HHS Information Security

Program security requirements, outlined in the HHS Information Security and Privacy

Policy (IS2P), by contacting the CO/COR or emailing fisma@hhs.gov.

d. Comply with the Privacy Act requirements and tailor FAR clauses as needed.

3) Information Security Categorization. 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, Appendix C, and based on information provided by the ISSO, CISO, or other security representative, the risk level for each Security Objective and the Overall Risk Level, which is the highest watermark of the three factors (Confidentiality, Integrity, and Availability) of the information or information system are the following:

Confidentiality: [ X ] Low [ ] Moderate [ ] High Integrity: [ ] Low [ X ] Moderate [ ] High Availability: [ ] Low [ X ] Moderate [ ] High

Overall Risk Level: [ ] Low [ X ] Moderate [ ] High

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

[ X ] No PII [ ] Yes PII

Complete this section using the information obtained from the Security and Privacy Checklist in

Appendix A, parts A and B.

4) Personally Identifiable Information (PII). Per the Office of Management and Budget (OMB)

Circular A-130, “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.

PII Confidentiality Impact Level has been determined to be: [ X ] Low [ ] Moderate [ ] High

5) Controlled Unclassified Information (CUI). CUI is defined 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 32

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.

All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, shall be:

a. marked appropriately;

b. disclosed to authorized personnel on a Need-To-Know basis;

c. protected in accordance with NIST SP 800-53, Security and Privacy Controls for Federal

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

d. returned to HHS control, destroyed when no longer needed, or held until otherwise directed. Destruction of information and/or data shall be accomplished in accordance with NIST SP 800-88, Guidelines for Media Sanitization.

6) 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) shall protect all government information that is or may be sensitive in accordance with OMB Memorandum M-06-16, Protection of Sensitive Agency Information by securing it with a FIPS 140-2 validated solution.

7) 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 shall be used only for the purpose of carrying out the provisions of this contract and shall 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 shall ensure that all work performed by its employees and subcontractors shall 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 shall 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 shall be protected in accordance with HHS and [CDC] policies. Unauthorized disclosure of information will be subject to the HHS/[CDC] sanction policies and/or governed by the following laws and regulations:

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

b. 18 U.S.C. 1905 (Criminal Code: Disclosure of Confidential Information); and

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

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

9) 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 shall 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, the HTTPS is not required, but it is highly recommended.

10) Contract Documentation. The Contractor shall use provided templates, policies, forms and other agency documents to comply with contract deliverables as appropriate.

See Appendix D for baseline deliverables.

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

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

b. 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 FIPS 140-

2 validated encryption solution.

c. Secure all devices (i.e.: desktops, laptops, mobile devices, etc.) that store and process government information and ensure devices meet HHS and CDC-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).

d. Verify that the encryption solutions in use have been validated under the Cryptographic

Module Validation Program to confirm compliance with FIPS 140-2. The Contractor shall provide a written copy of the validation documentation to the COR.

e. 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. Encryption keys shall be provided to CDC Office of Chief Information Security Officer (OCISO).

12) Contractor Non-Disclosure Agreement (NDA). Each Contractor (and/or any subcontractor) employee having access to non-public government information under this contract shall complete the CDC non-disclosure agreement, as applicable. A copy of each signed and witnessed NDA shall be submitted to the Contracting Officer (CO) and/or CO Representative

(COR) prior to performing any work under this acquisition.

See Appendix C for the Contractor Non-Disclosure Agreement.

13) Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA) – The Contractor shall assist the CDC Senior Official for Privacy (SOP) or designee with conducting a PTA for the information system and/or information handled under this contract in accordance with HHS policy and OMB M-03-22, Guidance for Implementing the Privacy Provisions of the E-

Government Act of 2002.

a. The Contractor shall assist the CDC SOP or designee in reviewing the PIA at least every three years throughout the system development lifecycle (SDLC)/information lifecycle, or when determined by the CDC SOP that a review is required based on a major change to the system (e.g., new uses of information collected, changes to the way information is shared or disclosed and for what purpose, or when new types of PII are collected that could introduce new or increased privacy risks), whichever comes first.

B. Training

1) Mandatory Training for All Contractor Staff. All Contractor (and/or any subcontractor) employees assigned to work on this contract shall complete the applicable HHS/CDC

Contractor Information Security Awareness, Privacy, and Records Management training

(provided upon contract award) before performing any work under this contract.

Thereafter, the employees shall complete CDC Security Awareness Training (SAT), Privacy, and Records Management training at least annually, during the life of this contract. All provided training shall be compliant with HHS training policies.

2) 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 (RBT) within 60 days of assuming their new responsibilities. Thereafter, they shall complete RBT at least annually in accordance with HHS policy and the HHS Role-Based

Training (RBT) of Personnel with Significant Security Responsibilities Memorandum.

All HHS employees and contractors with SSR who have not completed the required training within the mandated timeframes shall have their user accounts disabled until they have met their RBT requirement.

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

C. Rules of Behavior

1) The Contractor (and/or any subcontractor) shall ensure that all employees performing on the contract comply with the HHS Information Technology General Rules of Behavior.

2) 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 CDC 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.

D. Incident Response

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. The HHS Policy for IT Security and Privacy Incident Reporting and Response further defines incidents as events involving cybersecurity and privacy threats, such as viruses, malicious user activity, loss of, unauthorized disclosure or destruction of data, and so on.

A privacy breach is a type of incident and is defined by Federal Information Security Modernization Act (FISMA) as 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.

OMB Memorandum M-17-12, “Preparing for and Responding to a Breach of Personally

Identifiable Information” (03 January 2017) states:

Definition of an Incident:

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.

Definition of a Breach:

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.

It further adds:

A breach is not limited to an occurrence where a person other than an authorized user potentially accesses PII by means of a network intrusion, a targeted attack that exploits website vulnerabilities, or an attack executed through an email message or attachment. A breach may also include the loss or theft of physical documents that include PII and portable electronic storage media that store PII, the inadvertent disclosure of PII on a public website, or an oral disclosure of PII to a person who is not authorized to receive that information. It may also include an authorized user accessing PII for an other than authorized purpose.

The HHS Policy for IT Security and Privacy Incident Reporting and Response further defines a breach as “a suspected or confirmed incident involving PII”.

Contracts with entities that collect, maintain, use, or operate Federal information or information systems on behalf of CDC shall include the following requirements:

1) The contractor shall cooperate with and exchange information with CDC officials, as deemed necessary by the CDC Breach Response Team, to report and manage a suspected or confirmed breach.

2) All contractors and subcontractors shall properly encrypt PII in accordance with OMB

Circular A-130 and other applicable policies, including CDC-specific policies, and comply with

HHS-specific policies for protecting PII. To this end, all contractors and subcontractors shall protect all sensitive information, including any PII created, stored, or transmitted in the performance of this contract so as to avoid a secondary sensitive information incident with

FIPS 140-2 validated encryption.

3) All contractors and subcontractors shall participate in regular training on how to identify and report a breach.

4) All contractors and subcontractors shall report a suspected or confirmed breach in any medium as soon as possible and no later than 1 hour of discovery, consistent with applicable

CDC IT acquisitions guidance, HHS/CDC and incident management policy, and United States

Computer Emergency Readiness Team (US-CERT) notification guidelines. To this end, the

Contractor (and/or any subcontractor) shall respond to all alerts/Indicators of Compromise

(IOCs) provided by HHS Computer Security Incident Response Center (CSIRC) or CDC

Computer Incident Response Team (CSIRT) within 24 hours via email at csirt@cdc.gov or telephone at 866-655-2245, whether the response is positive or negative.

5) All contractors and subcontractors shall be able to determine what Federal information was or could have been accessed and by whom, construct a timeline of user activity, determine methods and techniques used to access Federal information, and identify the initial attack vector.

6) All contractors and subcontractors shall allow for an inspection, investigation, forensic analysis, and any other action necessary to ensure compliance with HHS/CDC Policy and the

HHS/CDC Breach Response Plan and to assist with responding to a breach.

7) Cloud service providers shall use guidance provided in the FedRAMP Incident

Communications Procedures when deciding when to report directly to US-CERT first or notify CDC first.

8) Identify roles and responsibilities, in accordance with HHS/CDC Breach Response Policy and the HHS/CDC Breach Response Plan. To this end, the Contractor shall NOT notify affected individuals unless and until so instructed by the Contracting Officer or designated representative. If so instructed by the Contracting Officer or representative, all notifications must be pre-approved by the appropriate CDC officials, consistent with HHS/CDC Breach

Response Plan, and the Contractor shall then send CDC- approved notifications to affected individuals; and,

9) Acknowledge that CDC will not interpret report of a breach, by itself, as conclusive evidence that the contractor or its subcontractor failed to provide adequate safeguards for PII.

E. 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 requiring activity representative, in conjunction with Personnel Security, shall use the OPM

Position Sensitivity Designation automated tool (https://www.opm.gov/investigations/) to determine the sensitivity designation for background investigations. After making those determinations, include all applicable position sensitivity designations.

F. Homeland Security Presidential Directive (HSPD)-12

The Contractor (and/or any subcontractor) and its employees shall comply with Homeland Security Presidential Directive (HSPD)-12, Policy for a Common Identification Standard for Federal

Employees and Contractors; OMB M-05-24; FIPS 201, Personal Identity Verification (PIV) of

Federal Employees and Contractors; HHS HSPD-12 policy; and Executive Order 13467, Part 1 §1.2.

For additional information, see HSPD-12 policy at: https://www.dhs.gov/homeland-security-presidential-directive-12)

Roster. The Contractor (and/or any subcontractor) shall 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 shall be submitted to the COR and/or CO by the effective date of this contract. Any revisions to the roster as a result of staffing changes shall be submitted immediately upon 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 shall provide a position description and the Government will determine the appropriate suitability level.

G. Contract Initiation and Expiration

1) General Security Requirements. The Contractor (and/or any subcontractor) shall 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 shall follow the HHS EPLC framework and methodology and in accordance with the HHS Contract Closeout Guide

(2012).

2) System Documentation. Contractors (and/or any subcontractors) must follow and adhere to

NIST SP 800-64, Security Considerations in the System Development Life Cycle, at a minimum, for system development and provide system documentation at designated intervals (specifically, at the expiration of the contract) within the EPLC that require artifact review and approval.

3) Sanitization of Government Files and Information. As part of contract closeout and at expiration of the contract, the Contractor (and/or any subcontractor) shall provide all required documentation 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.

4) Notification. The Contractor (and/or any subcontractor) shall notify the CO and/or COR and system ISSO before an employee stops working under this contract.

5) Contractor Responsibilities Upon Physical Completion of the Contract. The contractor

(and/or any subcontractors) shall 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 shall 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 CDC policies.

6) The Contractor (and/or any subcontractor) shall perform and document the actions identified in the CDC Out-Processing Checklist

(http://intranet.cdc.gov/od/hcrmo/pdfs/hr/Out_Processing_Checklist.pdf) when an employee terminates work under this contract. All documentation shall be made available to the CO and/or COR upon request.

H. Records Management and Retention

The Contractor (and/or any subcontractor) shall 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 policies and shall not dispose of any records unless authorized by HHS.

In the event that a contractor (and/or any subcontractor) accidentally disposes of or destroys a record without proper authorization, it shall be documented and reported as an incident in accordance with HHS policies.

HHS EA requirements may be located here: https://www.hhs.gov/ocio/ea/documents/proplans.html CDC EPC Requirements: https://www2a.CDC.gov/CDCup/library/other/eplc.htm

Standard-2: Requirements for Procurements Involving Privacy Act Records

A. Privacy Act

It has been determined that this contract is not subject to the Privacy Act of 1974, because this contract does provide for the design, development, or operation of a system of records on individuals.

Standard-3: Procurements Involving Government Information Processed on GOCO or COCO Systems

A. Security Requirements for GOCO and COCO Resources

1) Federal Policies. The Contractor (and/or any subcontractor) shall comply with applicable federal directives that include, but are not limited to, the HHS Information Security and

Privacy Policy (IS2P), the CDC Protection of Information Resources policy; 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, Security and Privacy

Controls for Federal 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.

2) Security Assessment and Authorization (SA&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) shall work with the agency and supply the deliverables required to complete the ATO prior to any use of the system in a production capacity, i.e., its intended users able to collect, store, process or transmit data to fulfill the system’s function.

The Contractor shall conduct the SA&A requirements in accordance with HHS IS2P/ CDC

Protection of Information Resources; the CDC IT Security Program Implementation

Standards; the CDC Security Assessment and Authorization (SA&A) Standard Operating

Procedure; and NIST SP 800-37, Guide for Applying the Risk Management Framework to

Federal Information Systems: A Security Life Cycle Approach (latest revision).

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

a. SA&A Package Deliverables - The Contractor (and/or any subcontractor) shall provide an

SA&A package to the C/I/O Information System Security Officer (ISSO) in accordance with the timeline, process and formats proscribed for a Full system authorization in the

CDC Security Assessment and Authorization Standard Operating Procedure (CDC SA&A

SOP). The following SA&A deliverables are required to complete the SA&A package:

• Baseline System Information (BSI) – The Contractor will document a system overview, in accordance with the timeline, process and formats described in the

CDC SA&A SOP. The BSI will include information concerning: system identification and ownership; system data, information types, impact levels and system categorization; system functional description / general purpose; system authorization boundary and environment; system user descriptions; and system interconnections and dependencies. The Contractor shall update the BSI at least annually thereafter.

• Privacy Threshold Analysis / Privacy Impact Analysis – The Contractor (and/or any subcontractor) shall provide a PTA/PIA (as appropriate), in accordance with the timeline, process and formats described in the CDC SA&A SOP, if applicable. Also see the sections of this contract concerning “Privacy Threshold Analysis (PTA)/Privacy

Impact Assessment (PIA)” and “Requirements for Procurements Involving Privacy

Act Records.”

NOTE: If social security numbers (SSN) are expected to be handled by the system, the program and Contractor must include a SSN Elimination or Usage Approval Request along with the PTA/PIA. That request will be processed in accordance with the OCISO

Standard for Limiting the Use of Social Security Numbers in CDC Information Systems.

• System Security Plan (SSP) – The SSP must be provided in a digital format supporting copy or export of all content into the HHS/CDC automated SA&A tool.

The SSP shall 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 Federal 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 CDC policies and other guidance. The SSP shall 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 shall provide an overview of the system environment (including an inventory of all devices and software contained within the system boundary) 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 shall update the SSP at least annually thereafter.

• Risk Assessment Report (RAR) The initial security assessment shall be conducted by the Contractor in conjunction with the program’s Information System Security

Officer, consistent with NIST SP 800-53A, NIST SP 800-30, and HHS and CDC policies.

The assessor will document and submit the assessment results in the RAR, in accordance with the process and formats described in the CDC SA&A SOP. The

Contractor shall address all “High” deficiencies before submitting the package to the

Government for acceptance. All remaining deficiencies must be documented in a system Plan of Actions and Milestones (POA&M) for CDC OCISO approval in accordance with the CDC SA&A SOP. Thereafter, the Contractor, in coordination with CDC shall conduct an assessment of the security controls and update the RAR within 365 days.

POA&M –The POA&M shall be documented consistent with the HHS Standard for

Plan of Action and Milestones and CDC policies. Identified risks stemming from deficiencies related to the security control baseline implementation, assessment, continuous monitoring, vulnerability scanning, and other security reviews and sources, as documented in the Security Assessment Report (SAR), shall be documented and tracked by the Contractor for mitigation in the POA&M document.

Depending on the severity of the risks, CDC may require designated POAM weaknesses to be remediated before an ATO is issued. Thereafter, the POA&M shall be updated at least quarterly.

• Contingency Plan and Contingency Plan Test –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 CDC policies. Upon acceptance by the System Owner, the Contractor, in coordination with the System

Owner, shall 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 shall update and test the Contingency Plan at least annually.

• E-Authentication Assessment – The contractor (and/or any subcontractor) shall collaborate with government personnel to ensure that an E-Authentication

Threshold Analysis (E-auth TA) is completed to determine if a full E-Authentication

Risk Assessment (E-auth RA) is necessary. System documentation developed for a system using E-auth TA/E-auth RA methods shall follow OMB 04-04; NIST SP 800-63, Digital Identity Guidelines; the OCISO Standard for Electronic Authentication (E-

Authentication); and the CDC SA&A SOP.

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

b. 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, shall 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, and

HHS IS2P. The following are the minimum requirements for ISCM:

• Annual Assessment/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 may involve penetration testing conducted by the agency or independent third-party). In addition, review all relevant SA&A documentation (SSP, POA&M, Contingency Plan, etc.) and provide updates by specified due date.

• 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-owned information/data. It is anticipated that this inventory information will be required to be produced at least annually. IT asset inventory information shall include IP address, machine name, operating system level, security patch level, and SCAP-compliant format information. The contractor shall maintain a capability to provide an inventory of 100% of its IT assets using SCAP-compliant automated tools.

• Configuration Management - Use available SCAP-compliant automated tools, per

NIST IR 7511, for authenticated scans to provide visibility into the security configuration compliance status of all IT assets, (computers, servers, routers, databases, operating systems, application, etc.) that store and process government information. Compliance will be measured using IT assets and standard HHS and government configuration baselines at least annually. The contractor shall maintain a capability to provide security configuration compliance information for 100% of its

IT assets using SCAP-compliant automated tools.

• Vulnerability Management - Use SCAP-compliant automated tools for authenticated scans to scan information system(s) and detect any security vulnerabilities in all assets (computers, servers,…