Checked Baggage BAA Call 70RSAT23RB00000001 Amendment 2 2.2.23.pdf

Broad Agency Announcement (BAA) Call Solicitation 70RSAT23RB00000001

Amendment 2 Under BAA 70RSAT22RB00000001

Project: Checked Baggage Technology Development

1.Introduction

This BAA Call solicitation (70RSAT23RB00000001) is a Call issued against Department of Homeland Security (DHS), Science & Technology (S&T), 5-Year Broad Agency Announcement (BAA), 70RSAT22RB00000001 “Screening and Speed Program.” All terms and conditions of the DHS S&T 5-Year BAA 70RSAT22RB00000001 apply to this solicitation unless otherwise noted herein.

This Call has a two phased structure. Phase 1 is White Paper submission. Phase 2 is Full Proposal submission. Offerors must complete Phase 1 in order to participate in Phase 2. A separate Call will not be issued for Phase 2. The Government may award more than one contract for each Technical Topic Area. Alternately the Government may, at its discretion, award no contracts in a Technical Topic Area.

The Department of Homeland Security (DHS) Science and Technology Directorate (S&T) Checked Baggage Technology Development Program pursues transformative Research and Development (R&D) activities that advance aviation security while decreasing false alarm rates and improving throughput. To enable this vision, the Checked Baggage Technology Development Program is considering the development of solutions to improve screening capabilities and improve training and certification processes for Transportation Security Officers (TSOs).

This R&D Acquisition seeks to develop two components of improved screening and alarm resolution and one component of an improved officer training and certification system.

• The first effort, under Technical Topic Area (TTA) #1, Level 1.5 Screening, seeks to augment current CT-based Explosives Detection Systems (EDS) screening through technology designed to work independently of or in conjunction with an EDS.

Technology may be X-ray or non-X-ray-based. Both X-ray and non-X-ray based technology are of interest to the Government under this TTA.

• The second effort, under TTA #2, Non-Trace-Based Detection Approaches, seeks to design and develop bulk threat detection technology to screen items found in checked baggage for explosives. S&T is not interested in technologies based on trace detection or x-ray-based methodologies for the purposes of this Call.

• The third effort, under TTA #3, Officer Evaluation Tool, seeks to develop a universal certification and training platform for the Transportation Security Agency (TSA).

2.Project Description/Scope

BAA Call solicitation 70RSAT23RB00000001 will develop system concept designs and subsystems to explosives detection, alarm resolution, and officer training and certification.

The primary technical focus is to develop concepts that allow DHS S&T to assess the viability of the concept and to develop a research and development strategy to mature and transition this capability.

This BAA Call solicits responses to the following three Technical Topic Areas:

• Level 1.5 Screening

• Non-Trace-Based Detection Approaches

• Officer Evaluation Tool

DHS S&T may make multiple awards for each TTA (Topic Areas 1-3) under this BAA Call pending the quality of proposals received and the availability of funds. S&T reserves the right to make multiple, one, or no awards from this BAA Call.

Central to this R&D acquisition will be the use of collaborative, multi-faceted research and development teams to achieve the desired end goals for the DHS, S&T and the TSA.

Candidate team members may consist of, but are not limited to, Original Equipment Manufacturers (OEMs), university researchers, national laboratories, third party innovators of algorithms, and component manufacturers in the supply chain. The formation of strong systems development teams, combining practical industry engineering experience with fundamental and applied research capabilities in multi-disciplinary fields including mathematics, x-ray physics, explosive/materials chemistry, and information science, provides the greatest potential for developing and transitioning enhanced capabilities to TSA for deployment in aviation security environments.

Each TTA is discussed in detail below and specific objectives for each TTA are also provided. Of particular note, it is anticipated that both metrics and analysis techniques to measure the development progress will evolve during the project.

3.Technical Topic Areas

TTA #1 Level 1.5 Screening

This effort seeks to develop of ways of augmenting current CT-based EDS) screening.

Technology may be designed either to work independently of the EDS system or in conjunction with it. The objectives of this research will be (1) to lower the number of false alarms requiring on-screen on in-person resolution by a TSO), and (2) to provide further material identification and discrimination to TSOs to assist with revolving alarms not cleared by the technology.

Technology must be able, in final development, to interrogate luggage at belt speeds typical of baggage handling systems (20-30 cm/sec) and to return results rapidly, before TSO adjudication would be instigated, with an initial/protype target of 120 seconds. S&T is interested in both later Technology Readiness Level (TRL) solutions which can provide a prototype in 24 months, and in solutions at an earlier development stage which may not meet all at-speed requirements.

Methodologies in which S&T are interested include, but are not limited to:

• Neutron imaging

• Nuclear Quadrupole Resonance

• Improved processing of EDS images, including Machine Learning

Proposals should discuss how the technology will be envisioned to be incorporated into existing airport spaces. baggage handling systems in current airports are often space-constrained and outside of TSA authority.

Proposals for technologies at the prototype level which require coordination with an EDS should discuss how they intend to demonstrate that coordination. Proposals for all technologies may assume that a DICOS (Digital Imaging and Communications in Security) CT image would be available in any fielded implementation.

The developed solution will be deployed within the Electronic Baggage Screening Program system architecture, after initial EDS screening. The technology will serve to reduce false alarms and, if applicable, provide material identification to downstream TSOs. Specifics of implementation may vary from airport to airport.

The development efforts under this TTA shall have formal design reviews such as, Preliminary Design Review (PDR) and Test Readiness Review (TRR). These reviews will act as key go-/no-go decision points and will be further defined if a request for Full Proposal is made by the Government. Offerors should include a process for incorporating human factors and human performance design principles throughout the development of the equipment. PDR and TRR should contain subject matter expert design inputs for Human Factors (HF) or Human Systems Integration (HSI).

An initial project management plan will be due fifteen (15) days after award. Offerors must include personnel, test facilities & capabilities, and initial project timelines in the plan.

Section 5 contains the anticipated key deliverables and milestones for this TTA.

TTA #2 Non-Trace-Based Detection Approaches

TSA has identified a gap in the screening of checked baggage for explosives using primary alarm resolution technology. Current alarm resolution capabilities lack the ability to accurately resolve all alarms generated in primary screening. Furthermore, future primary screening capability enhancements in checked baggage screening will generate alarms that existing alarm resolution procedures and countermeasures cannot resolve. Additionally, effective Explosive Trace Detection (ETD) screening is highly dependent on several variables, such as the area of interest chosen for screening, the amount of pressure applied during the sampling process, and the amount of trace materials present. ETD sampling also serves as the primary screening method of checked baggage at low volume airports that do not possess an Explosives Detection System (EDS). At these airports, the capability gap is even wider, as they cannot obtain the same level of automated explosive detection as larger airports.

S&T seeks proposals to design and develop Bulk Threat Detection Technology (BTDT) to screen items found in checked baggage. At final development, such technology should be capable of:

• Accurately detecting explosive threats detected with the current primary screening method

• Screening Stream of Commerce (SOC) powders, solids, and liquids

• Screening containers composed of metal, opaque plastic, and colored glass

• Providing information needed to resolve alarms with no further procedures required

• Reducing the number of alarms elevated to Advanced Alarm Resolution (AAR) for resolution

S&T is not interested in technologies based on trace detection or x-ray-based methodologies for the purposes of TTA #2.

TSOs will use the developed solution to screen items from checked baggage in the Checked Baggage Resolution Area (CBRA). The technology will serve as either primary or secondary screening depending on the makeup of the airport.

Airports without EDS will use the developed technology as a primary screening method in conjunction with physical search of checked baggage. Items unable to be cleared with visual inspection will be removed from the baggage and screened for explosives using the developed technology.

Airports with EDS will use the developed technology for screening of alarmed items during a targeted search. The alarming item will be removed from the checked baggage and screened separately using the determined technology.

It is expected that the technology developed for checked baggage could be used to inform Alarm Resolution for both checkpoint and checked baggage, but proposals should focus on the checked baggage applications.

The development efforts under this TTA shall have formal design reviews such as, PDR and TRR. These reviews will act as key go-/no-go decision points and will be further defined if a request for Full Proposal is made by the Government. Offerors should include a process for incorporating human factors and human performance design principles throughout the development of the equipment. PDR and TRR should contain subject matter expert design inputs for Human Factors (HF) or Human Systems Integration (HSI).

An initial project management plan will be due fifteen (15) days after award. Offerors must

TTA #3 Officer Evaluation Tool

This effort seeks to develop a universal certification and training platform for the TSA. The platform must allow TSA to train, certify, and evaluate TSO performance and proficiency across a variety of Transportation Security Equipment (TSE) in a dynamic environment. The platform must also align recurrent training to individual TSO needs. The platform must be able to interact with all forms of TSE in a live TSA environment to collect performance data.

The Government anticipates that data characterizing the platform architecture and functions will be a deliverable under this TTA.

Currently, TSA trains and certifies TSOs on TSE using a variety of instructor-led and online training platforms, each unique to the OEM. Changes to these materials often lag behind changes to TSA’s standard operating procedures for screening. Additionally, TSA lacks the ability to seamlessly evaluate performance in a live environment and align recurrent training to the individual TSO needs.

The end user of this platform would be able to complete certification and training for TSE through an online system separate from the TSE (e.g., computer based in a lab). Once the TSO completes initial certification, the TSO would complete recurrent training online using the platform as well as on the TSE in a live environment.

The platform should be able to receive real time inputs from TSE. TSE performance data inputs from live screening (e.g., Threat Image Projection (TIP) data collected from the X- Ray/CT) will inform recurrent training for TSOs. Additional inputs from offline evaluations would also be helpful such as results of threat injection testing. Preferably, the platform would overlay onto existing TSE interface and present a common interface for all TSE regardless of OEM.

The solution should be software (SW) based and deployable on existing TSA IT equipment (desktop/laptops). If the platform requires a separate computer, then the computer must be Commercial Off The Shelf (COTS) and ideally would be able to host other TSA training programs and needs. The SW overlay onto the TSE should not impact current TSE operation.

The platform must be able to track TSOs locally and nationally (up to 1 million active and inactive users combined). Image files must be able to be uploaded from a host location (HQ) as well as from end point locations (airports). File formats supported must include OEM-specific formats as well as DICOS.

The platform should produce real time reports on individual and bulk TSO certification, training, and proficiency data through an online interface. Session-specific performance of the TSO should be available at the end of a screening session on the TSE. The platform should track active TSO certifications and recurrent training requirements. The platform should provide enough fidelity (resemble stream of commerce images) to qualify as ongoing recurrent certification (i.e., the TSO evaluates TIP images, meets a minimum threshold of reviewed images, meets a predetermined detection score, then the TSO has met the recurrent certification requirements). Offerors should propose the thresholds and standards that they will be able to meet. The thresholds will ultimately be subject to negotiation, may include referenced TSA standards at the time of award, and should be included in the final negotiated statement of work.

The platform needs to be easily updateable so as to reflect changes to TSA Standard Operating Procedures (SOPs) and training requirements. The relevant SOPs and training requirements will be included in the statement of work at time of award.

The development efforts under this TTA shall have formal design reviews such as, PDR and TRR. These reviews will act as key go-/no-go decision points and will be further defined if a request for Full Proposal is made by the Government. Offerors should include a process for incorporating human factors and human performance design principles throughout the development of the equipment. PDR and TRR should contain subject matter expert design inputs for Human Factors (HF) or Human Systems Integration (HSI).

An initial project management plan will be due fifteen (15) days after award. Offerors must

4.Project Structure

The Checked Baggage Technology Development BAA Call is structured into three distinct TTAs that aim to 1) augment current CT-based EDS, 2) design and develop BTDT to screen items in checked baggage for explosives, and 3) develop a universal certification and training platform for

TSA.

5.Project Schedule/Milestones

The deliverables and milestones below are anticipated under each TTA. Offerors should describe proposed deliverables similar to the ones in the relevant table below in their Technical Proposals.

The Government highly desires a period of performance not to exceed 24 months for creating a transitionable product. However, longer periods of performance may be acceptable based on the specific work proposed. Generally, a transitionable product is desired after 24 months, but if follow-on work from that effort is envisioned, it may be proposed and competed at that time.

The potential for such follow-on work should be discussed in the proposal timeline.

TTA#1 Level 1.5 Screening and TTA#2 Non-Trace-Based Detection Technology

DELIVERABLES DUE DATE

Project Management Plan 15 days after award Monthly Status Reports Due monthly until end of project Major milestone reviews and materials (SCR, PDR, CDR Test Readiness Reviews (TRR) and Quarterly Status Reviews (QSR), etc.)

Meeting materials (i.e., slides/presentation package) due 5 day prior to review Final Due at Review meeting

Data Collection and Test Plans Due 30 days prior to Test start Data Collection and Test Reports Due 15 days after Test end Project Final Report – Including all analysis and raw data

Up to 24 months after award

TTA#3 Officer Evaluation Tool

DELIVERABLES DUE DATE

Project Management Plan 15 days after award Monthly Status Reports Due monthly until end of project Major milestone reviews and materials (SCR, PDR, CDR Test Readiness Reviews (TRR) and Quarterly Status Reviews (QSR), etc.)

Read ahead due 5 day prior to review Final Due at Review meeting

Data Collection and Test Plans Due 30 days prior to Test start Data Collection and Test Reports Due 15 days after Test end Project Final Report and Tool Delivery (proposals should indicate specific hardware and software that will be delivered)

Up to 24 months after award

6.Special Instructions/Notifications

Response Dates

Event Time Due Date or Date Due Questions Due 12:00 PM Eastern Time 11/29/2022 Answers Posted N/A 12/8/2022 White Papers Due (Phase 1)

12:00 PM Eastern Time 1/17/2023

Notification of White Paper Evaluation Results

N/A on or before 2/9/23

Proposals Due (Phase 2) 12:00 PM Eastern Time 03/07/2023 Notification of Proposal Evaluation Results

04/05/2023

Contractual or Technical Inquiries

All contractual or technical questions regarding this BAA Call solicitation must be emailed to the Contracting Officers and Contract Specialist.

Contracting Officer: Jennifer Koons – Jennifer.Koons@hq.dhs.gov

Alternate Contracting Officer: Carolyn Lethert - Carolyn.Lethert@hq.dhs.gov

Alternate Contracting Officer: Andrew Jones – Darin.Jones@hq.dhs.gov

Contract Specialist: Frances Gray – Frances.Gray@hq.dhs.gov

General Instructions and Information

Only Offerors that have submitted under a white paper under 70RSAT23RB00000001 may submit a full proposal. Full proposal instructions are listed below.

Phase 2 (Full Proposals): This submission includes both a Technical Proposal and a Cost Proposal. The Technical Proposal page limit is 40 pages. The Technical Proposal may include narrative, pictures, figures, tables, and charts in a legible size. Technical Proposals shall discuss in detail the Offeror’s technical and management approach as well as the Offeror’s relevant capabilities and experience. Technical proposals shall include the Offeror’s proposed deliverables based on the sample deliverables in Section 5. This submission shall include the assertion of data rights described in Section 9.5 of 70RSAT22RB00000001. The Cost Proposal does not have a page limit but should not include technical information. Cost Proposals should specify the Offeror’s preferred contract type (i.e., cost plus fixed fee, firm fixed price). Offerors should also specify the contract vehicle that they think is most appropriate for their proposed work (i.e., FAR-based contract, interagency agreement, other transaction). Cost proposals should include all applicable information specified under “Price/Cost Proposal” in Section 9.5 of

70RSAT22RB00000001.

Note that Offerors must complete the company/organization portal registration PRIOR to submitting a White Paper for the first time. Ensure adequate time to complete the company/organization registration as delays in this process will not be authorization for late submissions of White Papers. Company/organization registration information is in Section 10.1 of BAA 70RSAT22RB00000001 In addition, each subsequent White Paper requires registration in the portal. Information regarding White Paper registration is in paragraph 10.2 of 70RSAT22RB00000001.

White Papers also must comply with the information in BAA 70RSAT22RB00000001 paragraph 11.4 regarding Company-to-Company Agreements.

mailto:Carolyn.Lethert@hq.dhs.gov mailto:Darin.Jones@hq.dhs.gov mailto:Frances.Gray@hq.dhs.gov

For the purposes of this Call, the Noblis, Inc. point of contact for agreements is Dr.

Michelle Weinberger (Michelle.Weinberger@associates.hq.dhs.gov). Emails to Dr.

Weinberger shall include the Contracting Officer and Contract Specialist on the cc line of the email.

To be considered for award, Offerors MUST submit White Papers and Company to Company Agreements with Noblis, Inc. compliant with the response dates listed in the Response Dates table above, in accordance with the requirements in DHS BAA 70RSAT23RB00000001. Submissions not in compliance with both BAA 70RSAT22RB00000001 and BAA Call 70RSAT23RB00000001 may be rejected (note:

the cover page created by the DHS S&T BAA Portal must be included but does not count against the page count). White Papers will only be accepted via the portal. No emailed White Paper submissions will be accepted for review. No classified White Papers will be accepted.

White Papers will be evaluated and Offerors will either be encouraged or not encouraged to submit a Full Proposal. Offerors who are not encouraged to submit a Full Proposal are still permitted to do so. Offerors must submit a White Paper in order to be able to submit a Full Proposal. Feedback regarding the evaluation findings of submitted White Papers will not be provided.

Procedures for submission of Full Proposals can be found in Section 8 of BAA 70RSAT22RB00000001. Invitations to submit Full Proposals will be extended based on White Paper evaluation results in accordance with the date identified in the “Response Dates” table above. Full Proposals must be received by the due date identified in the “Response Dates” table above. Full Proposals are not being requested at this time. In accordance with Section 8 of BAA 70RSAT22RB00000001, Offerors must submit a fully compliant White Paper that to be considered for participation in the submission of proposals.

DHS has a strong preference for open-source licensing of software for all software developed and delivered, and the licenses for all proposed software deliverables will have to be identified in all submitted Full Proposals. However, as an alternative to open-source release, Offerors may also offer a strong technical transition plan for deployment of the technologies developed.

All software developed and delivered is subject to security auditing; therefore, the Offeror’s technical approach must identify how security auditing will occur. DHS expects Offerors to follow industry best practices on software design

Evaluation

As stated in BAA 70RSAT22RB00000001 DHS S&T reserves the right to select for award and to fund all, some, or none of the proposals received in response to this BAA Call solicitation.

The Evaluation Criteria in Section 11 of 70RSAT22RB00000001 apply to this Call. The mailto:Michelle.Weinberger@associates.hq.dhs.gov

Evaluation Criteria will be used for both Phase 1 and Phase 2. The Government expects Phase 2 proposals to contain considerably more detail than Phase 1 and will evaluate based on this expectation.

DHS S&T intends to use the following ratings to evaluate White Papers and Full Proposals:

Criterion I and Criterion II

Excellent (E) - A very convincing demonstration that the BAA requirements are met by the Offeror’s display of the highest levels of innovation, technical competence, and managerial ability. The White Paper/Full Proposal fully and completely meets the expectations of the BAA and sets forth plans, approaches, and analyses that show a high probability of meeting DHS requirements.

Very Good (VG) - Analyses, approaches, and planning considerations demonstrate that the Offeror is able to interpret goals and project them into plans, analyses, etc., in a clear, concise manner. By this analysis, the Offeror demonstrates an acute awareness of the subtle interactions influencing system design; technical and planning efforts show strong promise of meeting DHS requirements.

Good (G) - Plans, approaches, and analyses are provided to the extent requested, and the key or pivotal points raised by the applicable factors have been satisfactorily covered in the White Paper/Full Proposal. The Offeror has presented an orderly plan to meet the stated goals, but the White Paper/Full Proposal does not necessarily demonstrate any exceptional features, innovations, analysis, or originality. The technical analyses satisfactorily meet requirements and are technically sound.

Fair (F) - The White Paper/Full Proposal indicates minimal understanding of the problem.

The technical analyses meet the goals and are technically sound, but the Offeror fails to demonstrate a reasonable probability of successfully achieving the desired outcome of the topic area.

Unacceptable (U) - The White Paper/Full Proposal does not meet the BAA’s requirements.

Criterion III

Reasonable (R) – White Paper/Full Proposal cost information appears reasonable based on the proposed time/level of effort and materials needed to successfully complete tasks associated with this effort. The Government has few, if any, questions on costs.

Likely Reasonable with Questions (Q) – White Paper/Full Proposal cost information may be reasonable after the Government receives additional information to evaluate costs.

Not Reasonable (N) – White Paper/Full Proposal cost information does not appear reasonable. Costs are not adequately tied to technical approach or are not logical.

Company to Company Agreements

White Papers must comply with the information in BAA 70RSAT22RB0000001 paragraph

11.4 regarding Company-to-Company Agreements.

Important Note: DHS intends to use Noblis, Inc. for routine administrative support during the evaluation process of both White Papers and Full Proposals. All Offerors, Prime Contractors only (this applies to all Offerors, whether or not the Offeror is a company) must submit an executed Company to Company Agreement with Noblis, Inc., found in Appendix A, along with their White Paper submission. Company to Company Agreements must be dated this year (2022). The Agreement found in Appendix A shall not be altered. Submissions that do not include an executed Agreement will be considered non-responsive and will not be considered. For the purpose of this Call, the Noblis point of contact is Dr. Michelle Weinberger (Michelle.Weinberger@associates.hq.dhs.gov). Offerors are encouraged to allow sufficient time to permit agreement execution.

Foreign Participation

Offerors are reminded that foreign participation may occur as defined in BAA 70RSAT22RB00000001, Section 1.3. Offerors, including those located outside the continental United States, should provide full costs (delivery costs included) for any deliverables not anticipated for delivery in a softcopy format. All materials submitted in response to this solicitation shall be in the English language. White Papers, and Full Proposals, received in other than English shall be rejected. Offerors invited to submit proposals shall do so only in terms of U.S. dollars. Proposals received in other than U.S.

dollars shall be rejected.

Export Control Requirements

Offerors are reminded of the export control markings required by BAA 70RSAT22RB00000001, Section 12.5.

Travel

For purposes of estimating costs for Full Proposals, Offerors should anticipate travel to three (3) project meetings per year at DHS S&T Headquarters in Washington DC. Travel will be reimbursed in accordance with the limitations set forth in FAR 31.205-46, Travel Costs, and the Federal Travel Regulation. Local travel within a 50-mile radius from the Contractor’s facility or the Contractor’s assigned duty station will not be reimbursed.

This includes travel, subsistence, and associated labor charges for travel time. Travel performed for personal convenience or daily travel to and from work at the Contractor’s facility or local Government facility (i.e., designated work site) shall not be reimbursed hereunder. The Contractor shall not be reimbursed for moving or relocation expenses for the Contractor or Contractor employees, and/or subcontractors.

mailto:Michelle.Weinberger@associates.hq.dhs.gov

Order of Precedence

In the event that any of the terms and conditions contained in this solicitation conflict with terms and conditions included in BAA 70RSAT22RB00000001, the terms and conditions in this Call shall take precedence.

7. Sensitive Information Depending on an Offeror’s specific proposal and the TTA proposed under, Offerors may have access to sensitive information in awards under this BAA Call. DHS S&T will comply with the requirements of HSAR Class Deviation 15-01 and the HSAM Appendix G Sensitive Information Checklist for individual awards under this BAA. Accordingly, the clauses below may apply to individual awards under this BAA. Awards under 70RSAT23RB00000001 are likely to require access to sensitive information. Accordingly, the clauses listed below will generally be included in awards under this Call.

DHS has and will exercise full control over granting, denying, withholding, or terminating unescorted Government facility, Government systems and/or sensitive Government information access for Contractor employees, based upon the results of a DHS fitness (suitability) investigation. DHS may, as it deems appropriate, authorize and make a favorable Entry Of Duty (EOD) decision based on preliminary security checks.

The favorable EOD decision would allow the contactor to commence work temporarily prior to the completion of the full investigation. The granting of a favorable EOD decision shall not be considered as assurance that a full employment contractor fitness (suitability) authorization will follow as a result thereof. The granting of a favorable EOD decision or a full contractor fitness (suitability) authorization determination shall in no way prevent, preclude, or bar the withdrawal or termination of any such access by DHS, at any time during the term of the task order. No employee of the contractor shall be allowed unescorted access to a Government facility, access to any sensitive information or access to DHS Systems without a favorable EOD decision or contractor fitness (suitability) determination by the DHS Office of Security. Contract employees assigned to the task order not needing access to sensitive DHS information, DHS systems or access to DHS facilities will not be subject to security contractor fitness (suitability) screening. Contract employees waiting an EOD decision may not begin work on the task order. Limited access to Government buildings is allowable prior to the EOD decision if the contractor is escorted by a Government employee. This limited access is to allow contractors to attend briefings, nonrecurring meetings, and begin transition work.

Classified information is Government information which requires protection in accordance with Executive Order 13526, National Security Information (NSI) as amended and supplemental directives. If the contractor has access to classified information at a DHS owned or leased facility, it shall comply with the security requirements of DHS and the facility. If the contractor is required to have access to classified information at another Government facility, it shall abide by the requirements set forth by the agency.

HSAR 15-01 Safeguarding of Sensitive Information (MAR 2015)

(a) Applicability. This clause applies to the Contractor and its contractors, its subcontractors, and their employees (hereafter referred to collectively as “Contractor”). The Contractor shall insert the substance of this clause in all subcontracts.

(b) Definitions. As used in this clause—

“Personally Identifiable Information (PII)” means information that can be used to distinguish or trace an individual's identity, such as name, social security number, or biometric records, either alone, or when combined with other personal or identifying information that is linked or linkable to a specific individual, such as date and place of birth, or mother’s maiden name. The definition of PII is not anchored to any single category of information or technology. Rather, it requires a case-by-case assessment of the specific risk that an individual can be identified.

In performing this assessment, it is important for an agency to recognize that non-personally identifiable information can become personally identifiable information whenever additional information is made publicly available—in any medium and from any source—that, combined with other available information, could be used to identify an individual.

PII is a subset of sensitive information. Examples of PII include, but are not limited to: name, date of birth, mailing address, telephone number, Social Security number (SSN), email address, zip code, account numbers, certificate/license numbers, vehicle identifiers including license plates, uniform resource locators (URLs), static Internet protocol addresses, biometric identifiers such as fingerprint, voiceprint, iris scan, photographic facial images, or any other unique identifying number or characteristic, and any information where it is reasonably foreseeable that the information will be linked with other information to identify the individual.

“Sensitive Information” is defined in HSAR clause 3052.204-71, Contractor Employee Access, as any information, which if lost, misused, disclosed, or, without authorization is accessed, or modified, could adversely affect the national or homeland security interest, the conduct of Federal programs, or the privacy to which individuals are entitled under section 552a of Title 5, United States Code (the Privacy Act), but which has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept secret in the interest of national defense, homeland security or foreign policy. This definition includes the following categories of information:

(1) Protected Critical Infrastructure Information (PCII) as set out in the

Critical Infrastructure Information Act of 2002 (Title II, Subtitle B, of the Homeland Security Act, Public Law 107-296, 196 Stat. 2135), as amended, the implementing regulations thereto (Title 6, Code of Federal Regulations, Part 29) as amended, the applicable PCII Procedures Manual, as amended, and any supplementary guidance officially communicated by an authorized official of the Department of Homeland Security (including the PCII Program Manager or his/her designee);

(2) Sensitive Security Information (SSI), as defined in Title 49, Code of Federal Regulations, Part 1520, as amended, “Policies and Procedures of Safeguarding and Control of SSI,” as amended, and any supplementary guidance officially communicated by an authorized official of the Department of Homeland Security (including the Assistant Secretary for the Transportation Security Administration or his/her designee);

(3) Information designated as “For Official Use Only,” which is unclassified information of a sensitive nature and the unauthorized disclosure of which could adversely impact a person’s privacy or welfare, the conduct of Federal programs, or other programs or operations essential to the national or homeland security interest; and

(4) Any information that is designated “sensitive” or subject to other controls, safeguards or protections in accordance with subsequently adopted homeland security information handling procedures.

“Sensitive Information Incident” is an incident that includes the known, potential, or suspected exposure, loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or unauthorized access or attempted access of any Government system, Contractor system, or sensitive information.

“Sensitive Personally Identifiable Information (SPII)” is a subset of PII, which if lost, compromised or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. Some forms of PII are sensitive as stand-alone elements. Examples of such PII include: Social Security numbers (SSN), driver’s license or state identification number, Alien Registration Numbers (A-number), financial account number, and biometric identifiers such as fingerprint, voiceprint, or iris scan. Additional examples include any groupings of information that contain an individual’s name or other unique identifier plus one or more of the following elements:

(1) Truncated SSN (such as last 4 digits)

(2) Date of birth (month, day, and year)

(3) Citizenship or immigration status

(4) Ethnic or religious affiliation

(5) Sexual orientation

(6) Criminal History

(7) Medical Information

(8) System authentication information such as mother’s maiden name, account passwords or personal identification numbers (PIN)

Other PII may be “sensitive” depending on its context, such as a list of employees and their performance ratings or an unlisted home address or phone number. In contrast, a business card or public telephone directory of agency employees contains PII but is not sensitive.

(c) Authorities. The Contractor shall follow all current versions of Government policies and guidance accessible at http://www.dhs.gov/dhs-security-and-training-requirements-contractors, or available upon request from the Contracting Officer, including but not limited to:

(1) DHS Management Directive 11042.1 Safeguarding Sensitive But Unclassified (for Official Use Only) Information

(2) DHS Sensitive Systems Policy Directive 4300A

(3) DHS 4300A Sensitive Systems Handbook and Attachments

(4) DHS Security Authorization Process Guide

(5) DHS Handbook for Safeguarding Sensitive Personally Identifiable Information

(6) DHS Instruction Handbook 121-01-007 Department of Homeland Security Personnel Suitability and Security Program

(7) DHS Information Security Performance Plan (current fiscal year)

(8) DHS Privacy Incident Handling Guidance

(9) Federal Information Processing Standard (FIPS) 140-2 Security Requirements for Cryptographic Modules accessible at http://csrc.nist.gov/groups/STM/cmvp/standards.html

(10) National Institute of Standards and Technology (NIST) Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations accessible at http://csrc.nist.gov/publications/PubsSPs.html

(11) NIST Special Publication 800-88 Guidelines for Media Sanitization accessible at http://csrc.nist.gov/publications/PubsSPs.html

(d) Handling of Sensitive Information. Contractor compliance with this clause, as well as the policies and procedures described below, is required.

(1) Department of Homeland Security (DHS) policies and procedures on Contractor personnel security requirements are set forth in various Management Directives (MDs), Directives, and Instructions. MD 11042.1, Safeguarding Sensitive But Unclassified (For Official Use Only) Information describes how Contractors must handle sensitive but unclassified information. DHS uses the term “FOR OFFICIAL USE ONLY” to identify sensitive but unclassified information that is not otherwise categorized by statute or regulation. Examples of sensitive information that are categorized by statute or regulation are PCII, SSI, etc.

The DHS Sensitive Systems Policy Directive 4300A and the DHS 4300A Sensitive Systems Handbook provide the policies and procedures on security for Information Technology (IT) resources. The DHS Handbook for Safeguarding Sensitive Personally Identifiable Information provides guidelines to help safeguard SPII in both paper and electronic form. DHS Instruction Handbook 121-01-007 Department of Homeland Security Personnel Suitability and Security Program establishes procedures, program responsibilities, minimum standards, and reporting protocols for the DHS Personnel Suitability and Security Program.

(2) The Contractor shall not use or redistribute any sensitive information processed, stored, and/or transmitted by the Contractor except as specified in the contract.

(3) All Contractor employees with access to sensitive information shall execute DHS Form 11000-6, Department of Homeland Security Non- Disclosure Agreement (NDA), as a condition of access to such information. The Contractor shall maintain signed copies of the NDA for all employees as a record of compliance. The Contractor shall provide copies of the signed NDA to the Contracting Officer’s Representative (COR) no later than two (2) days after execution of the form.

(4) The Contractor’s invoicing, billing, and other recordkeeping systems maintained to support financial or other administrative functions shall not maintain SPII. It is acceptable to maintain in these systems the names, titles and contact information for the COR or other Government personnel associated with the administration of the contract, as needed.

(e) Authority to Operate. The Contractor shall not input, store, process, output, and/or transmit sensitive information within a Contractor IT system without an

Authority to Operate (ATO) signed by the Headquarters or Component CIO, or designee, in consultation with the Headquarters or Component Privacy Officer.

Unless otherwise specified in the ATO letter, the ATO is valid for three (3) years.

The Contractor shall adhere to current Government policies, procedures, and guidance for the Security Authorization (SA) process as defined below.

(1) Complete the Security Authorization process. The SA process shall proceed according to the DHS Sensitive Systems Policy Directive 4300A (Version 11.0, April 30, 2014), or any successor publication, DHS 4300A Sensitive Systems Handbook (Version 9.1, July 24, 2012), or any successor publication, and the Security Authorization Process Guide including templates.

(i) Security Authorization Process Documentation. SA documentation shall be developed using the Government provided Requirements Traceability Matrix and Government security documentation templates. SA documentation consists of the following: Security Plan, Contingency Plan, Contingency Plan Test Results, Configuration Management Plan, Security Assessment Plan, Security Assessment Report, and Authorization to Operate Letter. Additional documents that may be required include a Plan(s) of Action and Milestones and Interconnection Security Agreement(s). During the development of SA documentation, the Contractor shall submit a signed SA package, validated by an independent third party, to the COR for acceptance by the Headquarters or Component CIO, or designee, at least thirty

(30) days prior to the date of operation of the IT system. The Government is the final authority on the compliance of the SA package and may limit the number of resubmissions of a modified SA package. Once the ATO has been accepted by the Headquarters or Component CIO, or designee, the Contracting Officer shall incorporate the ATO into the contract as a compliance document. The Government’s acceptance of the ATO does not alleviate the Contractor’s responsibility to ensure the IT system controls are implemented and operating effectively.

(ii) Independent Assessment. Contractors shall have an independent third party validate the security and privacy controls in place for the system(s). The independent third party shall review and analyze the SA package, and report on technical, operational, and management level deficiencies as outlined in

NIST Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations. The Contractor shall address all deficiencies before submitting the SA package to the Government for acceptance.

(iii) Support the completion of the Privacy Threshold Analysis (PTA) as needed. As part of the SA process, the Contractor may be required to support the Government in the completion of the PTA. The requirement to complete a PTA is triggered by the creation, use, modification, upgrade, or disposition of a Contractor IT system that will store, maintain and use PII, and must be renewed at least every three (3) years. Upon review of the PTA, the DHS Privacy Office determines whether a Privacy Impact Assessment (PIA) and/or Privacy Act System of Records Notice (SORN), or modifications thereto, are required. The Contractor shall provide all support necessary to assist the Department in completing the PIA in a timely manner and shall ensure that project management plans and schedules include time for the completion of the PTA, PIA, and SORN (to the extent required) as milestones. Support in this context includes responding timely to requests for information from the Government about the use, access, storage, and maintenance of PII on the Contractor’s system, and providing timely review of relevant compliance documents for factual accuracy. Information on the DHS privacy compliance process, including PTAs, PIAs, and SORNs, is accessible at http://www.dhs.gov/privacy-compliance.

(2) Renewal of ATO. Unless otherwise specified in the ATO letter, the ATO shall be renewed every three (3) years. The Contractor is required to update its SA package as part of the ATO renewal process. The Contractor shall update its SA package by one of the following methods:

(1) Updating the SA documentation in the DHS automated information assurance tool for acceptance by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls; or (2) Submitting an updated SA package directly to the COR for approval by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls. The 90-day review process is independent of the system production date and therefore it is important that the Contractor build the review into project schedules. The reviews may include onsite visits that involve physical or logical inspection of the

Contractor environment to ensure controls are in place.

(3) Security Review. The Government may elect to conduct random periodic reviews to ensure that the security requirements contained in this contract are being implemented and enforced. The Contractor shall afford DHS, the Office of the Inspector General, and other Government organizations access to the Contractor’s facilities, installations, operations, documentation, databases and personnel used in the performance of this contract. The Contractor shall, through the Contracting Officer and COR, contact the Headquarters or Component CIO, or designee, to coordinate and participate in review and inspection activity by Government organizations external to the DHS. Access shall be provided, to the extent necessary as determined by the Government, for the Government to carry out a program of inspection, investigation, and audit to safeguard against threats and hazards to the integrity, availability and confidentiality of Government data or the function of computer systems used in performance of this contract and to preserve evidence of computer crime.

(4) Continuous Monitoring. All Contractor-operated systems that input, store, process, output, and/or transmit sensitive information shall meet or exceed the continuous monitoring requirements identified in the Fiscal Year 2014 DHS Information Security Performance Plan, or successor publication. The plan is updated on an annual basis. The Contractor shall also store monthly continuous monitoring data at its location for a period not less than one year from the date the data is created. The data shall be encrypted in accordance with FIPS 140-2 Security Requirements for Cryptographic Modules and shall not be stored on systems that are shared with other commercial or Government entities. The Government may elect to perform continuous monitoring and IT security scanning of Contractor systems from Government tools and infrastructure.

(5) Revocation of ATO. In the event of a sensitive information incident, the Government may suspend or revoke an existing ATO (either in part or in whole). If an ATO is suspended or revoked in accordance with this provision, the Contracting Officer may direct the Contractor to take additional security measures to secure sensitive information. These measures may include restricting access to sensitive information on the Contractor IT system under this contract. Restricting access may include disconnecting the system processing, storing, or transmitting the sensitive information from the Internet or other networks or applying additional security controls.

(6) Federal Reporting Requirements. Contractors operating information systems on behalf of the Government or operating systems containing sensitive information shall comply with Federal reporting requirements.

Annual and quarterly data collection will be coordinated by the Government. Contractors shall provide the COR with requested information within three (3) business days of receipt of the request.

Reporting requirements are determined by the Government and are defined in the Fiscal Year 2014 DHS Information Security Performance Plan, or successor publication. The Contractor shall provide the Government with all information to fully satisfy Federal reporting requirements for Contractor systems.

(f) Sensitive Information Incident Reporting Requirements.

(1) All known or suspected sensitive information incidents shall be reported to the Headquarters or Component Security Operations Center (SOC) within one hour of discovery in accordance with 4300A Sensitive Systems Handbook Incident Response and Reporting requirements. When notifying the Headquarters or Component SOC, the Contractor shall also notify the Contracting Officer, COR, Headquarters or Component Privacy Officer, and US-CERT using the contact information identified in the contract. If the incident is reported by phone or the Contracting Officer’s email address is not immediately available, the Contractor shall contact the Contracting Officer immediately after reporting the incident to the Headquarters or Component SOC. The Contractor shall not include any sensitive information in the subject or body of any e-mail. To transmit sensitive information, the Contractor shall use FIPS 140-2 Security Requirements for Cryptographic Modules compliant encryption methods to protect sensitive information in attachments to email.