SECTION C - Statement of Work_CUAS Base Requirements.pdf
PDF 513 KB Posted
- Attached to
- Counter-Unmanned Aircraft Systems (C-UAS) Draft Solicitation Federal contract opportunity
- Solicitation number
- 70RDA226R00000001
About this file
This document is a Base Requirements document for Counter-Unmanned Aircraft Systems (C-UAS) for the Department of Homeland Security (DHS). The solicitation seeks hardware, software, and services to address growing threats from unauthorized or malicious unmanned aircraft systems across diverse operational environments. The contract will support two primary technical tracks:
Track 1 covers hardware/software and ancillary services, including physical C-UAS components, standalone software, and related services such as training, maintenance, installation, and customization. Track 2 focuses on comprehensive services including vendor-operated turnkey solutions, system integration, research and development, and test and evaluation support. The C-UAS solutions must perform critical functions like detection (minimum 2 km range), tracking (simultaneously track at least 3 UAS), identification, and mitigation of UAS threats. The solutions are required to operate in various environments including fixed locations, mobile responses, aviation settings, and maritime contexts, with specific technical requirements for system resilience, safety, integration, and compliance with federal standards and cybersecurity protocols.
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| C-UAS Industry Day Slides Final_11.10.25.pdf | ||
| Questions for Industry.pdf | ||
| Questions and Comments Template.xlsx | XLSX spreadsheet | |
| SECTION L - Instructions to Offerors.pdf | ||
| Attachment 1 - Track 1 Pricing Schedule for Use Case Scenario.xlsx | XLSX spreadsheet | |
| Attachment 4 - Self Certification Technical Expertise Form.docx | DOCX document | |
| SECTION M - Evaluation Factors for Award.pdf | ||
| Attachment 2 - Pricing Schedule Track 2-Comprehensive Services.xlsx | XLSX spreadsheet | |
| Attachment 3 - Track 2 C-UAS IDIQ Labor Categories.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Counter-Unmanned Aircraft Systems (C-UAS) Base Requirements
Background The Department of Homeland Security (DHS) requires Counter-Unmanned Aircraft Systems (C-UAS) solutions to address the growing threats posed by unauthorized or malicious unmanned aircraft systems (UAS). These systems must support the detection, tracking, locating, classification, identification, and mitigation of UAS threats across diverse operational environments. This procurement will enable DHS components to acquire adaptable C-UAS capabilities tailored to their unique mission requirements, ensuring the protection of critical infrastructure, public safety, and national security.
As part of its mission, DHS is responsible for securing National Special Security Events (NSSE) and Special Event Assessment Rating (SEAR) events, which include high-profile gatherings such as presidential inaugurations, major sporting events, and other large-scale public events. These events often require specialized airspace security measures to address UAS threats and ensure the safety of attendees, critical infrastructure, and surrounding communities. C-UAS solutions procured under this effort will play a vital role in supporting DHS’s ability to secure these events and respond to evolving threats.
Scope This contract will provide DHS with access to a variety of C-UAS solutions in the form of hardware, software, or services that support a variety of operational use cases, system types, and capabilities. This contract will remain current with available market solutions and provide a full range of C-UAS solutions throughout its life. The following C-UAS use cases are expected:
• Fixed Location Security: Continuous airspace awareness and response capabilities for permanent installations, such as airports, government facilities, and critical infrastructure.
o Aviation Environments: Systems capable of operating in aviation environments, such as airports, airfields, or areas with high-density air traffic, where airspace safety and compliance with aviation regulations are critical.
o Maritime Environments: Systems capable of operating in maritime environments, such as ports and coastal areas, where environmental factors (e.g., saltwater exposure, high humidity) and maritime operational needs are key considerations.
• Mobile Response: Portable, rapidly deployable systems or services capable of operating in dynamic, geographically dispersed, or roaming environments. This can include handheld, backpack, trailer, vehicle, maritime or airborne mounted solutions.
o Aviation-Based Operations: Systems capable of being deployed on aircraft to support airborne operations, such as patrolling borders, monitoring large areas, or supporting disaster response from the air.
o Maritime Environments: Systems capable of operating in maritime environments, such as aboard vessels, where environmental factors (e.g., saltwater exposure, high humidity) and maritime operational needs are key considerations.
Technical Tracks The Contractor shall furnish a range of hardware, software, or services aligned with technical tracks to meet requirements of this contract and individual orders. All hardware and services must meet DHS policies, standards, and procedures as identified in individual orders. Each proposed solution will correspond to a specific technical category as defined below.
Track 1 – HARDWARE/ SOFTWARE & ANCILLARY SERVICES The Contractor shall provide material C-UAS solutions for end users to test, evaluate, or operate. These solutions shall include up to all physical components, associated or standalone software that meet the defined requirements and capabilities. Standalone software shall be able to be integrated into existing C- UAS hardware. This category includes all related ancillary services such as training, maintenance, installation, planning, customer support, and customization for the selected use case, enabling end users to sustain and operate their C-UAS solutions effectively.
Track 2 – COMPREHENSIVE SERVICES The Contractor shall provide services that meet defined requirements and capabilities to support vendor-operated turnkey solutions, system integration, research and development (R&D), and test and evaluation (T&E) support, to ensure effective and sustained operation of C-UAS systems.
The Contractor shall provide, as applicable, the following services:
o C-UAS as a Service: Vendor-operated turnkey solutions, where contractors provide any of the system types (Detection, Tracking, and Identification (DTI) Systems; Mitigation Systems; and Integrated Systems) as a fully managed service.
o System Integration: Provide technical expertise and tools to integrate C-UAS solutions with existing systems, platforms, and emerging technologies. Ensure DHS-wide interoperability through standardized data formats, APIs, secure communication protocols, and compatibility testing.
o Research and Development (R&D) and Test and Evaluation (T&E) Support: Provide equipment, tools, data, and expertise to facilitate R&D and T&E activities for C-UAS solutions. This includes C- UAS equipment, simulation tools, data collection and analysis tools, system reports, and lifecycle and upgradability assessments.
Functional Definitions and Requirements The contractor shall deliver solutions that perform the requirements outlined below. While not all requirements are applicable to every solution, any applicable capability provided by the system must comply with the corresponding requirement.
Scalability:
• Shall demonstrate ability to ramp up production to meet increased demand or surge requirements, including scalability of manufacturing processes, supply chain resilience, and workforce capacity due to future operational needs, increased UAS threats or expanded geographic coverage. This includes having contingency plans for addressing supply chain disruptions, ensuring timely delivery of systems and components under varying operational conditions.
Detect:
• System shall incorporate one or more of the following technologies to ensure robust and comprehensive operational capabilities: Radio Frequency Detection, Radio Detection and Ranging (RADAR), Optical sensors (cameras), Acoustic sensors, and Electro-Optical/Infrared (EO/IR) sensors and detail how they are utilized.
• Shall be able to detect a UAS at a minimum range of 2 km.
Track:
• Shall compile reports over time of where a Ground-based Control System (GCS) or Unmanned
Aircraft System (UAS) is located.
• Shall display tracking data as a line or sequence of dots in the system’s user interface.
• Shall provide track history with an update rate of ≤ 20 seconds.
• Shall simultaneously track a minimum of 3 UAS.
• Shall provide static estimated reports or displays of where a GCS or UAS is located.
• Shall achieve geolocation capabilities with the following thresholds:
o 60% probability of geolocating UAS in 3D (latitude/longitude/altitude).
o Overall geolocation error of less than 75 m for moving UAS and 50 m for hovering UAS.
o 80% probability of geolocating UAS Ground Control Stations (GCS) with an error of less than 50 m.
Identification:
• Shall assign detected UAS to high-level categories, such as UAS type, group, manufacturer, and/or protocol.
• Shall assign detected UAS to more specific categories, such as the physical/MAC address of the modem or the exact make/model and protocol of the UAS.
• Shall provide whitelist/blacklist management for known UAS.
Mitigate/Neutralize:
• Shall provide methods to remove or reduce the threat posed by a UAS.
• Shall mitigate UAS threats at a minimum range of 500 meters.
• Shall mitigate at least one simultaneous UAS threat without degradation in effectiveness.
Command and Control:
• The system shall support integration with Team Awareness Kit (TAK) or other existing situational awareness systems.
• The system shall comply with relevant standards, including the National Information Exchange
Model (NIEM), NIST SP 800-53, and DHS Management Directive 047-01.
• The system shall allow operators to access and extract detection, identification, classification, and tracking data to support post-mission analysis.
• The system shall store and maintain all system data (e.g., detection logs and reports) for at least
180 days.
• The system shall share graphical user interface (GUI) display information to external displays using HDMI, DisplayPort, or USB-C.
System Resiliency:
• The system shall have been evaluated against the following military standards to ensure durability, reliability, and survivability:
o MIL-STD-810H: For environmental durability, including temperature, humidity, shock, vibration, and other environmental conditions.
o MIL-STD-461G: For electromagnetic interference (EMI) and electromagnetic compatibility (EMC), ensuring reliable operation in environments with high electromagnetic interference.
o MIL-STD-464C: For electromagnetic environmental effects (E3), ensuring survivability and reliable operation in environments with electromagnetic threats, including electromagnetic pulse (EMP).
• The system shall comply with the NIST Cybersecurity Framework and include encrypted communications links.
• The system shall achieve an operational availability of at least 90% over a 12-month period.
Aircraft-Based Operations Requirements For systems intended for deployment on aircraft, the contractor shall ensure the following:
Airborne Integration:
o Systems shall be compatible with aircraft systems, including avionics, communication systems, and onboard sensors.
o Systems shall meet size, weight, and power constraints for airborne platforms.
Operational Functionality:
o Systems shall operate effectively at altitude and in varying atmospheric conditions.
o Systems shall integrate with onboard situational awareness tools and provide real-time data transmission to ground stations or other aircraft.
Safety and Certification:
o Systems shall comply with Federal Aviation Administration (FAA) regulations for onboard equipment.
o Systems shall be certified for electromagnetic compatibility to prevent interference with aircraft systems.
Deployment Scenarios:
o Systems shall support airborne operations, such as patrolling borders, monitoring large areas, or disaster response.
o Systems shall be capable of detecting, tracking, identifying, and mitigating UAS threats during flight.
Maritime Deployment Requirements For systems intended for deployment in maritime environments, the contractor shall ensure the following:
Maritime Integration:
o Systems shall be compatible with maritime platforms, including vessels, coastal installations, and port infrastructure.
o Systems must meet size, weight, and power constraints for maritime operations.
Operational Functionality:
o Systems shall operate effectively in maritime conditions, including high humidity, saltwater exposure, and dynamic movement aboard vessels.
o Systems shall integrate with onboard situational awareness tools and provide real-time data transmission to coastal command centers or other vessels.
Environmental Resilience:
o Systems shall be ruggedized to withstand maritime environmental factors, including corrosion resistance, waterproofing, and shock absorption.
o Systems shall have been evaluated against MIL-STD-810H standards for environmental durability, particularly for saltwater exposure and vibration.
Deployment Scenarios:
o Systems shall support maritime operations, such as securing ports, patrolling coastal areas, or responding to threats aboard vessels.
o Systems shall be capable of detecting, tracking, identifying, and mitigating UAS threats in maritime environments.
Technology Refresh Requirements The contractor shall ensure that their product/service catalog remains current and reflects the latest advancements in technology. DHS reserves the right to audit the contractor's catalog and technology refresh process to ensure compliance with this requirement.
Testing Requirements The contractor shall support testing activities, defined at the task order level, to ensure compliance with operational and technical requirements.
At a minimum, the contractor shall provide detailed testing reports as required to validate system functionality and performance. This shall include:
• Operational Test Reports: Submission of any existing operational test reports for the system, including results from prior deployments or evaluations.
• Pre-Deployment Testing: Testing in controlled environments to validate system functionality and performance. Pre-Deployment Testing shall include:
o Capturing results against MIL-STD-810H for environmental durability.
o Capturing results against MIL-STD-461G for electromagnetic interference (EMI) and electromagnetic compatibility (EMC).
o Capturing results against MIL-STD-464C for electromagnetic environmental effects
(E3), including survivability in environments with electromagnetic pulse (EMP).
o Testing of system capabilities, including detection, tracking, identification, and mitigation, under simulated operational conditions.
• Operational Testing: Testing scenarios that mimic real-world conditions, including:
o Urban environments with high RF interference.
o Remote areas with limited infrastructure.
o High-density events with multiple UAS threats.
o Aviation environments, including airports or airfields.
o Aircraft-based operations, including testing at altitude and integration with onboard systems.
o Maritime environments, including ports, coastal areas, or vessels.
• Acceptance Testing: Clear acceptance criteria, such as successful detection and mitigation of 95% of simulated UAS threats and seamless integration with DHS systems during testing.
Training Requirements The contractor shall provide training tailored to the operational needs of DHS Components, including system setup, operation, and maintenance, as defined at the task order level.
Training shall be conducted in person unless otherwise requested by DHS. At a minimum, the training shall cover the entire solution, including:
• System setup and calibration.
• Detection, tracking, classification, identification, and mitigation workflows.
• Troubleshooting and maintenance procedures.
Training shall be delivered at a train-the-trainer level to ensure DHS personnel can train others effectively.
Update and Maintenance Management The contractor shall provide the process for implementing system/software updates, threat library updates, and hardware updates with every task order. This shall include:
• Notification timelines for updates.
• Testing and validation procedures prior to deployment.
• Documentation of update impacts on system performance.
The contractor shall also provide their Maintenance Management Plan with every task order, including:
• Scheduled maintenance activities.
• Procedures for addressing unscheduled maintenance needs.
• Availability of spare parts and consumables.
Interoperability Declaration The contractor shall declare the file formats used by their system and provide documentation of existing interoperability with other systems, with every task order, including:
• DHS situational awareness platforms (e.g., TAK, DHS COP).
• Threat intelligence databases.
• Command and control (C2) systems.
Spectrum Analysis The contractor shall provide an analysis of their system’s impact on the RF spectrum, with every task order, including:
• Frequency bands utilized.
• Potential interference with other systems.
• Any associated approvals for spectrum utilization.
System Documentation The contractor shall provide detailed documentation of their system’s functionality, limitations, and maintenance procedures, with every task order, including, but not limited to:
• Size.
• Weight.
• Power requirements
• Deployment time.
• System setup and calibration.
• Concept of Operation.
• Assembly, Storage, and Transportation capabilities.
• Detection, tracking, classification, identification, and mitigation workflows.
• Troubleshooting and maintenance procedures
• Corrective actions to be taken if the system fails to meet defined parameters.
• Environmental constraints and performance degradation under specific conditions.
Compliance Documentation The contractor shall provide documentation demonstrating compliance with all applicable laws, regulations, and standards, with every task order, including, but not limited to:
• FAA and FCC regulations governing UAS operations.
• DHS cybersecurity standards (e.g., NIST SP 800-53, FedRAMP).
• "Buy America" provisions for hardware components.
• DHS Management Directives and policies.
Deliverables General Report Requirements All document deliverables shall be provided in Microsoft Office electronic format, unless indicated otherwise. Additional requirements may be specified at the task order level.
Deliverable Description Due Delivered To
Order Status Report Monthly report of the status of orders received during the previous month, orders received at the start of the month
Monthly by the 10th of the following month
IDIQ COR
IDIQ CO
IDIQ PM
Monthly Financial Report
Report of contract revenue during the previous month and contract revenue to date.
Monthly by the 10th of the following month
IDIQ COR
IDIQ CO
IDIQ PM
Transactional Data Reports
Quarterly Report of the specific order, pricing, and savings information during the previous government quarter.
Quarterly, no later than 15 days after the end of each Government Fiscal quarter.
Dedicated Government Email Box
(TBD)
Order Status report The Contractor shall deliver an Order Status Report to the COR and PM monthly, by the 10th of the month. Status changes may include changes to expected delivery dates or locations and changes to anticipated shipping dates.
Monthly Financial Report The Contractor shall submit a Monthly Financial report by the 10th day of the month following the previous reporting period. The Monthly Financial report shall provide the overall Contract financial status, including revenue from delivery orders during the reporting month as well as total Contract revenue to date.
Transactional Data Reporting Requirements The Contractor is required to provide comprehensive transactional data reports for all orders placed under the C-UAS contract. These reports are critical for supporting federal government category management initiatives and ensuring transparency in procurement activities. The specific requirements are as follows:
1. Frequency and Format:
• The Contractor shall provide a single group mailbox for all non-solicitation inquiries.
• The Contractor shall provide the transactional data report on a quarterly basis, no later than 15 days after the end of each fiscal quarter.
• The report must be submitted in electronic format, either .xls or .csv utilizing the DHS provided template, with the following column headers ordered from left to right: Award Vehicle, Contract Number (IDVPIID), Order Number (Award PIID), Modification Number (if applicable), Vendor Name, DUNS, Federal Department or Agency, Component or Office, Order Date/Date of Award, Delivery Date, Baseline Price Per Unit (Contract Ceiling Price), Baseline Price Per Unit (GSA or Commercial List Price), Award Price Per Unit, Quantity of Item Sold, Unit of Measure, Description of Deliverable, SKU/Part Number, and Manufacturer Name.
2. Data Elements:
• Award Vehicle (C-UAS): Identify the contract vehicle under which the order was placed.
• Contract Number (IDVPIID): Provide the contract number associated with the IDIQ vehicle.
• Order Number (Award PIID): Provide the unique order number for each transaction.
• Modification Number (if applicable): Include any modification numbers associated with the order.
• Vendor Name: Identify the name of the vendor fulfilling the order.
• UEI: Unique Entity ID
• Federal Department or Agency: Specify the federal department or agency placing the order.
• Component or Office: Specify the component or office within the agency that issued/placed the order.
• Order Date/Date of Award: Provide the date when the order was placed or awarded.
• Delivery Date: Provide the date when this item was delivered.
• Baseline Price Per Unit (Contract Ceiling Price): Include the contract ceiling price per unit.
• Baseline Price Per Unit (GSA or Commercial List Price): Include the GSA or commercial list price per unit.
• Award Price Per Unit: Provide the awarded price per unit.
• Quantity of Item Sold: Include the quantity of each item sold.
• Unit of Measure: Specify the unit of measure for each item.
• Description of Deliverable: Provide a brief description of each deliverable.
• SKU/Part Number: Include the SKU or part number for each item.
• Manufacturer Name: Provide the name of the manufacturer for each item.
3. Submission Process:
• The Contractor shall submit the transactional data report to the designated DHS email address (TBD). This email address is a dedicated, non-personal address for data reporting purposes.
• The Contractor is responsible for ensuring the accuracy and completeness of the data provided in each report.
• Zero transactional data for the quarter shall be submitted as well.
4. Non-Compliance and Remedies:
• Failure to submit the required transactional data reports on time or providing incomplete or inaccurate data may result in contractual remedies.
• The Contractor must address any discrepancies or omissions identified by the Government within 3 days of notification.
5. Review and Verification:
• The Government reserves the right to review and verify the transactional data reports for accuracy and completeness.
• The Contractor shall cooperate with any Government audits or reviews related to the transactional data reporting requirements.
1.1.1 General Report Requirements
The Contractor shall provide all written reports in electronic format with read/write capability using applications compatible with DHS standard applications (e.g. Windows 10/11, Microsoft Office Applications/Office 365; Adobe portable document format [PDF]).
4 APPLICABLE DOCUMENTS
4.1 Compliance Documents
The following documents provide specifications, standards, or guidelines that must be complied with in order to meet the requirements of this contract.
• FAA and FCC regulations governing UAS operations.
• DHS cybersecurity standards (e.g., NIST SP 800-53, FedRAMP).
• "Buy America" provisions for hardware components.
• DHS Management Directives and policies.
• MIL-STD-810H
• MIL-STD-461G
• MIL-STD-464C
5 GOVERNMENT FURNISHED ITEMS
The Government will furnish no working space, equipment, or supplies in support of this Contract.
6 TRAVEL
Contractor travel may be required to customer sites (e.g. equipment installation or repair).
7 HOURS OF OPERATION
Hours of Operation will be determined at the order level.
8 COMPLIANCE WITH DHS SECURITY POLICY
All unclassified hardware, software, and services provided under this contract shall be compliant with DHS Sensitive System Policy Directive 4300A.
All classified collateral hardware, software, and services provided under this contract shall be compliant with DHS National Security Systems Policy Directive.
The Contractor shall comply with federal regulations, such as NIST SP 800-171, to safeguard Controlled Unclassified Information (CUI) through access controls, encryption, and incident response measures. The Contractor shall also address Foreign Ownership, Control, or Influence (FOCI) risks, implement physical and cybersecurity protections, comply with export control laws, and ensure secure data handling within approved locations. The Contractor shall report all security incidents and flow-down all clauses for subcontractors.
9 Sensitive But Unclassified Systems Requirements
The Contractor will have access to unclassified and Sensitive But Unclassified (SBU) Information under this SOW. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination.
OCIO has determined that performance of this contract requires the Contractor access to SBU information. SBU is unclassified information for official use only. Contractor employees that do not have a security clearance and require access to SBU information will be given a suitability determination.
• Data Security - SBU systems shall be protected from unauthorized access, modification, and denial of service. The Contractor shall ensure that all aspects of data security requirements (i.e., confidentiality, integrity, and availability) are included in the functional requirements and system design and ensure that they meet the minimum requirements as set forth in the DHS IT and cybersecurity policies and procedures. These requirements include:
ο Integrity - The computer systems used for processing SBU data shall have data integrity controls to ensure that data is not modified (intentionally or unintentionally) or repudiated by either the sender or the receiver of the information. A risk analysis and vulnerability assessment shall be performed to determine what type of data integrity controls (e.g., cyclical redundancy checks, message authentication codes, security hash functions, and digital signatures, etc.) shall be used.
ο Confidentiality - Controls shall be included to ensure that SBU information collected, stored, and transmitted by the system is protected against compromise. A risk analysis and vulnerability assessment shall be performed to determine if threats to the SBU information or data exist. If it exists, data encryption shall be used to mitigate such threats.
ο Availability - Controls shall be included to ensure that the system is continuously working and that all services are fully available within a timeframe commensurate with the availability needs of the user community and the criticality of the information processed.
• Data Labeling - The Contractor shall ensure that documents and media are labeled consistent with the DHS Sensitive Systems Policy for systems and services delivered and operated by the Contractor.
• Controlled Unclassified Information (CUI) – Execution of orders under this IDIQ will incorporate the requirements of HSAR 3052.204-72, Safeguarding of Controlled Unclassified Information commensurate to the categories of CUI used by the quoter for that given task order.
10. Encryption Compliance
If encryption is required, the following methods are acceptable for encrypting sensitive information:
1. FIPS 197 (Advanced Encryption Standard (AES)) 256 algorithm and cryptographic modules that have been validated under FIPS 140-2.
2. National Security Agency (NSA) Type 2 or Type 1 encryption.
3. Public Key Infrastructure (PKI) (Section 5 of DHS Sensitive Systems
Policy Directive 4300A).
4. National Security Systems requiring encryption shall comply with the following standards:
a. Products using FIPS 197 AES algorithms with at least 256-bit encryption that have been validated under FIPS 140-2 (Note: The use of Triple Data Encryption Standard (3DES) and FIPS 140-1 is no longer permitted. If AES cannot currently be used, the Program Manager will obtain the necessary waiver or exception.)
b. NSA Type 2 or Type 1 encryption
11. Security Review
The Government may elect to conduct periodic reviews to ensure that the security requirements contained in this contract are being implemented and enforced. The Contractor shall afford DHS, including the organizations of the DHS Office of the Chief Information Officer, the Office of the Inspector General, authorized COR, and other Government oversight organizations, access to the
Contractor’s facilities, installations, operations, documentation, databases, and personnel used in the performance of this contract.
The Contractor shall contact the DHS Chief Information Security Officer to coordinate and participate in the review and inspection activity of Government oversight organizations external to DHS. Access shall be provided to the extent necessary for the Government to carry out a program of inspection, investigation, and audit to safeguard against threats and risks to the confidentiality, integrity, and availability of DHS data or the function of information systems operated on behalf of DHS, and to preserve evidence of a computer crime.
12. Interconnection Security Agreement
An Interconnection Security Agreement (ISA) between DHS and non-DHS information systems shall be established only through controlled interfaces and via approved service providers. The controlled interfaces shall be accredited at the highest security level of information on the network. Connections with other Federal agencies shall be documented based on interagency agreements, memoranda of understanding, service level agreements or interconnect service agreements.
13. OCIO CISO CYBER-SUPPLY CHAIN RISK MANAGEMENT (C-SCRM)
a. Definitions
i. Component: a unit defined by the supplier that connects to and functions as part of the product.
For software products, a component is a unit of software defined by a supplier at the time the component is built, packaged, or delivered. For hardware, a component is one hardware unit designed to connect to and function as part of a larger product.
ii. End-of-Life (EOL): means that an ICT product has reached the final stage of the product life cycle in which that version of the ICT product will no longer be supported nor manufactured (e.g., no patches will be developed, no security improvements will be made, and, sometimes, no troubleshooting technical assistance will be offered).
iii. End-of-Support (EOS): means that an ICT product will no longer be supported (e.g., no patches will be developed, no security improvements will be made, and, sometimes, no troubleshooting technical assistance will be offered).
iv. Information and Communications Technology (ICT): encompasses the capture, storage, retrieval, processing, display, representation, presentation, organization, management, security, transfer, and interchange of data and information; includes all categories of ubiquitous technology used for the gathering, storing, transmitting, retrieving, or processing of information (e.g., microelectronics, printed circuit boards, computing systems, software, signal processors, mobile telephony, satellite communications, and networks).
v. Product: part of the equipment (hardware, software and materials) for which usability is to be specified or evaluated.
b. Original Equipment Manufacturer (OEM) End-use Information and Communications Technology (ICT) Product
i. The contractor shall provide new equipment unless otherwise formally approved by the Government, in writing. The contractor shall provide only Original Manufacturer (OEM) end-use products to the Government. In the event that a shipped OEM product, or part or component of that product, fails, all replacements must be new (i.e., non-refurbished, not previously used)
OEM.
ii. The contractor may provide previously-used OEM products only with written Government approval. Such parts shall be procured from their original source and shipped only from the manufacturer's authorized shipment points.
c. Accounting of Components in ICT Products
i. The contractor shall provide and maintain a list of components for each product used in performance of the contract, including through subcontracts or other arrangements. This list for each product shall provide the component manufacturer's name, address, state, and/or domain of registration, and, where applicable, the Unique Entity Identifier (UEI) number, for all components comprising the ICT products.
ii. The contractor shall notify the Government when a new contractor/subcontractor/service provider is introduced to the ICT provided on this contract, or when suppliers of components or products are changed. If a software component used in the performance of the contract is updated with a new build or release, the contractor must update the list provided in accordance with (i) above to reflect the new version of the software. This includes software builds to integrate an updated component or dependency.
iii. For software products, the contractor shall provide all OEM software updates, and patches to correct defects, for the life of the product [i.e., until the "End of Life" (EoL) or "End of Support" (EoS)]. Software updates and patches shall be made available to the government for all products procured under this Contract and replaced when End of Support (EoS) is reached.
iv. A contractor using team members in performance of the contract (e.g., subcontractors or other service providers) shall ensure that the standards for the accounting of components in this subsection are met by team members.
d. Supply-Chain Transport
i. The contractor shall use formal, documented and accountable transit, storage, and delivery procedures (i.e., the possession of the end-use product to be delivered is documented at all times from initial shipping point to final destination, and every transfer of the product from one custodian to another is fully documented and accountable) for all information and communication technology (ICT) shipments to fulfill this contract.
ii. The contractor shall maintain all records pertaining to the transit, storage, and delivery of ICT deliverables under this contract through at least 6 months after acceptance and make available for inspection upon request of the Government.
iii. The contractor shall make use of tamper-proof or tamper-evident packaging for all shipments.
iv. The contractor shall provide a packing slip for each container or package with the information identifying the contract or order number, a description of the hardware/software enclosed (Manufacturer name, model number, serial number), and the customer point of contact.
v. The contractor shall provide a shipping notification to the intended government recipient; with a copy transmitted to the Contracting Officer, or other designated representative. This shipping notification shall be provided electronically and identify the contract or order number, a description of the hardware/software being shipped (manufacturer name, model number, serial number), initial shipper, shipping date and identifying (tracking) number.
e. Changes to Ownership and Control
The Contractor shall immediately notify the Contracting Officer and Contracting Officer's Representative regarding any significant changes to corporate ownership or control from contract award through final delivery or the end of the period of performance. A significant change would be one in which a change occurs in the individuals or entities who, directly or indirectly, either
(1) exercises substantial control over an entity, or (2) owns or controls at least 25 percent of the ownership interests of an entity.
14. DHS Enterprise Architecture Compliance
All solutions and services shall meet DHS Enterprise Architecture policies, standards, and procedures. Specifically, the contractor shall comply with the following HLS EA requirements:
- All developed solutions and requirements shall be compliant with the HLS EA.
- All IT hardware and software shall be compliant with the HLS EA Technical Reference Model (TRM) Standards and Products Profile.
- Description information for all data assets, information exchanges and data standards, whether adopted or developed, shall be submitted to the Enterprise Architecture Division (EAD) for review, approval and insertion into the DHS Data Reference Model and Mobius.
- Development of data assets, information exchanges and data standards will comply with the DHS Data Management Policy MD 103-01 and all data-related artifacts will be developed and validated according to DHS data management architectural guidelines.
- Applicability of Internet Protocol Version 6 (IPv6) to DHS-related components (networks, infrastructure, and applications) specific to individual acquisitions shall be in accordance with the DHS Enterprise Architecture (per OMB Memorandum M-05-22, August 2, 2005) regardless of whether the acquisition is for modification, upgrade, or replacement. All EA-related component acquisitions shall be IPv6 compliant as defined in the U.S. Government Version 6 (USGv6) Profile (National Institute of Standards and Technology (NIST) Special Publication 500-267) and the corresponding declarations of conformance defined in the USGv6 Test Program.
15. Artificial Intelligence / Machine Learning Requirements
Definitions: Artificial Intelligence (AI) includes the following: (1) Any artificial system that performs tasks under varying and unpredictable circumstances without significant human oversight, or that can learn from experience and improve performance when exposed to data sets.
(2) An artificial system developed in computer software, physical hardware, or other context that solves tasks requiring human-like perception, cognition, planning, learning, communication, or physical action. (3) An artificial system designed to think or act like a human, including cognitive architectures and neural networks. (4) A set of techniques, including machine learning, that is designed to approximate a cognitive task. (5) An artificial system designed to act rationally, including an intelligent software agent or embodied robot that achieves goals using perception, planning, reasoning, learning, communicating, decision making, and acting.
Requirements: The 2019 National Defense Authorization Act (NDAA) and Executive Order (EO) 13960 require that AI used in the Federal Government foster public trust and confidence while protecting privacy, civil rights, civil liberties, and American values. All federal employees, contractors, and subcontractors, when designing, developing, acquiring, and/or using AI for or within DHS, will adhere to the following 9 principles.
1. Lawful and respectful of our Nation's values: Agencies shall design, develop, acquire, and use AI in a manner that exhibits due respect for our Nation's values and is consistent with the Constitution and all other applicable laws and policies, including those addressing privacy, civil rights, and civil liberties.
2. Purposeful and performance-driven: Agencies shall seek opportunities for designing, developing, acquiring, and using AI, where the benefits of doing so significantly outweigh the risks, and the risks can be assessed and managed.
3. Accurate, reliable, and effective: Agencies shall ensure that their application of AI is consistent with the use cases for which that AI was trained, and such use is accurate, reliable, and effective.
4. Safe, secure, and resilient: Agencies shall ensure the safety, security, and resiliency of their AI applications, including resilience when confronted with systematic vulnerabilities, adversarial manipulation, and other malicious exploitation.
5. Understandable: Agencies shall ensure that the operations and outcomes of their AI applications are sufficiently understandable by subject matter experts, users, and others, as appropriate.
6. Responsible and traceable: Agencies shall ensure that human roles and responsibilities are clearly defined, understood, and appropriately assigned for the design, development, acquisition, and use of AI. Agencies shall ensure that AI is used in a manner consistent with these Principles and the purposes for which each use of AI is intended. The design, development, acquisition, and use of AI, as well as relevant inputs and outputs of particular AI applications, should be well documented and traceable, as appropriate and to the extent practicable.
7. Regularly monitored: Agencies shall ensure that their AI applications are regularly tested against these Principles. Mechanisms should be maintained to supersede, disengage, or deactivate existing applications of AI that demonstrate performance or outcomes that are inconsistent with their intended use or this order.
8. Transparent: Agencies shall be transparent in disclosing relevant information regarding their use of AI to appropriate stakeholders, including the Congress and the public, to the extent practicable and in accordance with applicable laws and policies, including with respect to the protection of privacy and of sensitive law enforcement, national security, and other protected information.
9. Accountable: Agencies shall be accountable for implementing and enforcing appropriate safeguards for the proper use and functioning of their applications of AI, and shall monitor, audit, and document compliance with those safeguards. Agencies shall provide appropriate training to all agency personnel responsible for the design, development, acquisition, and use of
AI.
16. Cloud and FedRAMP Requirements
(a) Cloud computing. All use of cloud computing products or services that process unclassified information must comply with the FedRAMP Authorization Act, 44 U.S.C. Section 3607 et. seq.
The following requirements apply when using cloud computing to provide information systems or services in the performance of the contract.
i. Cloud computing security requirements. The Contractor shall implement and maintain administrative, technical, and physical safeguards and controls with the security level and services required in accordance with FedRAMP Security Authorization Requirements unless notified by the Contracting Officer that this requirement has been waived by the Agency Chief Information Officer.
ii. Cloud computing continuous monitoring. The Contractor shall maintain an adequate continuous monitoring capability based on the FedRAMP Security Authorization Requirements including processes described in the NIST Special Publication (SP) 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations and governed by the FedRAMP Continuous Monitoring Strategy Guide.
iii. Cloud computing services cyber incident reporting. The Contractor shall report all cybersecurity incidents that are related to the cloud computing service provided under this contract. Reports shall be submitted according to FedRAMP Security Authorization Requirements, published FedRAMP Incident Communications Procedures, and Federal Incident Notification Guidelines for submitting incident notifications to CISA using the CISA incident reporting form (https://us-cert.cisa.gov/report).
17 HSPD-12 Requirements
Procurements for products, systems, services, hardware, or software involving controlled facility or information system shall be PIV-enabled by accepting HSPD-12 PIV credentials as a method of identity verification and authentication.
https://us-cert.cisa.gov/report
Procurements for software products or software developments shall be compliant by PIV by accepting PIV credentials as the common means of authentication for access for federal employees and contractors.
PIV-enabled information systems must demonstrate that they can correctly work with PIV credentials by responding to the cryptographic challenge in the authentication protocol before granting access.
If a system is identified to be non-compliant with HSPD-12 for PIV credential enablement, a remediation plan for achieving HSPD-12 compliance shall be required for review, evaluation, and approval by the CISO.
The Homeland Security Presidential Directive 12 (HSPD-12) requires the use of the Personal Identity Verification (PIV) credentials as the common means of authentication for access to DHS facilities, networks, and information systems. Personal Identity Verification (PIV) credentials shall be used as the primary means of logical authentication for DHS sensitive systems. The Contractor must use his or her federal issued Personal Identity Verification (PIV) credentials to access DHS resources to include IT applications and physical facility.
The DHS Office of the Chief Security Officer shall be notified of all terminations/resignations within five (5) days of occurrence. The Contractor shall return to the Contracting Officer Representative (COR) all DHS issued Personal Identity Verification (PIV) credentials/identification cards and building passes that have either expired or have been collected from terminated employees. If a PIV credential/identification card or building pass is not available to be returned, a report shall be submitted to the COR, referencing the PIV credential, pass or card number, name of individual to who it was issued and the last known location and disposition of the PIV credential, pass or card. The Contractor or contractor personnel's failure to return all DHS issued identification cards and building passes upon expiration, upon the contractor personnel's removal from the contract, or upon demand by DHS may subject the contractor personnel and the Contractor to civil and criminal liability.
18 SECTION 508 COMPLIANCE
18.1 Section 508 Requirements
Order solicitations shall include Section 508 requirements in the Statement of Work (SOW), Statement of Objectives (SOO), Performance Work Statement (PWS), or the Description of Requirements (DOR) when the solicitation requires the purchase of information and communications technology (ICT) and include the following language generated by the DART
2.1 (required to obtain Section 508 Requirements for solicitations).
Common situations include:
• New Solicitations
• Task Orders under existing contracts (including contracts managed by other agencies)
• ICT that will be provided to the public & internally
• ICT COTS/GOTS licenses https://www.dhs.gov/xlibrary/oast/DART/ https://www.dhs.gov/xlibrary/oast/DART/
• ICT approved on the TRM
• ICT proof of concepts, pilot efforts, and MVPs
• ICT provided as a service (example – SaaS, PaaS)
• ICT provided through open-source arrangements
• ICT that has an authorized 508 exception
• Services to develop, modify, configure, install, maintain, and host ICT
• Services that produce ICT in support of other deliverables (ex. Electronic forms)
Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) (codified at 29 U.S.C. § 794d) requires that when Federal agencies develop, procure, maintain, or use information and communications technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public with disabilities must be afforded access to and use of information and data comparable to that of Federal employees and members of the public without disabilities.
All products, platforms and services delivered as part of this work statement that, by definition, are deemed ICT shall conform to the revised regulatory implementation of Section 508 Standards, which are located at 36 C.F.R. § 1194.1 & Appendix A, C & D, and available at https://www.gpo.gov/fdsys/pkg/CFR-2017-title36-vol3/pdf/CFR-2017-title36-vol3-part1194.pdf.
In the revised regulation, ICT replaced the term electronic and information technology (EIT) used in the original 508 standards. ICT includes IT and other equipment.
Exceptions for this work statement have been determined by DHS and only the exceptions described herein may be applied. Any request for additional exceptions shall be sent to the Contracting Officer and a determination will be made according to DHS Directive 139-05, Office of Accessible Systems and Technology, dated November 12, 2018, and DHS Instruction 139-05-001, Managing the Accessible Systems and Technology Program, dated November 20, 2018, or any successor publication.
18.2 Section 508 Requirements for Technology Services
1. When developing or modifying ICT, the Contractor is required to validate ICT deliverables for conformance to the applicable Section 508 requirements. Validation shall occur on a frequency that ensures Section 508 requirements is evaluated within each iteration and release that contains user interface functionality.
2. When modifying, installing, configuring, or integrating commercially available or government- owned ICT, the Contractor shall not reduce the original ICT Item’s level of Section 508 conformance.
3. When developing or modifying web based and electronic content components, except for electronic documents and non-fillable forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria) by conducting testing using the DHS Trusted Tester for Web Methodology Version 5.0 or successor versions, and https://www.gpo.gov/fdsys/pkg/CFR-2017-title36-vol3/pdf/CFR-2017-title36-vol3-part1194.pdf https://www.gpo.gov/fdsys/pkg/CFR-2017-title36-vol3/pdf/CFR-2017-title36-vol3-part1194.pdf shall ensure testing is conducted by individuals who are certified by DHS on version 5.0 or successor versions (e.g. “DHS Certified Trusted Testers”). The Contractor shall provide the Trusted Tester Certification IDs to DHS upon request. Information on the DHS Trusted Tester for Web Methodology Version 5.0, related test tools, test reporting, training, and tester certification requirements is published at https://www.dhs.gov/trusted-tester.
4. When developing or modifying electronic documents and forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable to the applicable Section 508 standards (including WCAG Level A and AA Level 2.0 Success Criteria) by conducting testing using the test methods published under “Accessibility Tests for Documents” at https://www.dhs.gov/compliance-test-processes.
5. When developing or modifying software functions of ICT, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including the requirements in Chapter 5 and WCAG 2.0 Level A and AA Success Criteria). When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall demonstrate conformance to the Functional Performance Criteria specified in Chapter
3. The Contractor shall use a test process capable of validating conformance to all applicable Section 508 standards for software functionality delivered pursuant to this contract. The Contractor may utilize the DHS Trusted Tester Methodology for Web and Software Version
4.0 as a component of the overall test process used. This version of the test process provides partial test coverage of the Section 508 standards that apply to software. If the Contractor uses this test process, the Contractor shall address the test coverage gaps through additional test procedures.
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .