Attachment III SOW Terms and Conditions.pdf

BIOMETRIC EXAMINATION TOOL

Terms & Conditions

05/15/2026

1.0 Terms and Conditions

1.1 ITAR SME Cybersecurity Policy

All hardware, software, and services provided must be compliant with DHS Security Policy. The 4300 handbook is no longer in use. Reference Information Security Systems Program 4300A version 13.4, December 6, 2024.

ISO Terms and Conditions for Sensitive but Unclassified Requests

DHS Security Policy Requirement The following terms and conditions should be included in all acquisition documents. All hardware, software, and services provided under this task order must be compliant with DHS Information Security System Program 4300A version 13.4, December 6, 2024.

Encryption Compliance Requirement The following terms and conditions should be included in all IT procurement documents.

1. FIPS 197 (Advanced Encryption Standard (AES)) 256 algorithm and cryptographic modules that have been validated under FIPS 140-2 and / or FIPS 140-3.

2. National Security Agency (NSA) Type 2 or Type 1 encryption.

3. Public Key Infrastructure (PKI), key cards, biometrics, or in the case of multi-factor authentication, some combination therein (See Attachment U) Information Security Sensitive Systems Program Directive 4300A version 13.4, December 6, 2024.

Security Review Requirement The following requirements should be included in all acquisition documents.

Security Review The Government may elect to conduct periodic reviews to ensure that the security requirements contained in the contract are being implemented and enforced. The Government, at its sole discretion, may obtain assistance from other Federal agencies and/or third-party firms to aid in security review activities. The Contractor shall afford DHS, the Office of the Inspector General, other government organizations, and Contractors working in support of the Government access to the Contractor’s facilities, installations, operations, documentation, databases, networks, systems, and personnel used in the performance of this contract. The Contractor shall, through the Contracting Officer and Contracting Officer's Representative (COR), contact the Component or Headquarters CIO, or designee, to coordinate and participate in review and inspection activity by government organizations external to DHS. Access shall be provided, to the extent necessary as determined by the Government (including providing all requested images), 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.

Interconnection Security Agreement (ISA) The following requirements should be included if the service being supplied requires a connection to a non-DHS, contractor system, or DHS system of different sensitivity.

Interconnection Security Agreement Requirements Interconnections between DHS and non-DHS IT systems shall be established only through controlled interfaces and via approved service providers. Connections with other federal agencies shall be documented based on interagency agreements, memoranda of understanding, service level agreements or interconnect service agreements. The applicable network connectivity policy is located in the Access Control Section, for “Interconnection Security Agreements,” of the DHS 4300A, Attachment N.

Required Protections for DHS Systems Hosted in Non-DHS Data Centers The following requirements should be included when information systems are hosted, operated, maintained, and used on behalf of DHS at non-DHS facilities. Contractors are fully responsible and accountable for ensuring compliance with all Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST), Special Publication SP-800- 47, DHS Management Directive 140-01, “Information Technology Security Program,” Revision 2, May 5, 2017, Federal Information Processing Standard (FIPS) and related DHS security control requirements (to include configuration guides, hardening guidance, DHS Security Policy, Procedures, and Architectural guidance). The contractor security procedures shall be the same or greater than those that are provided by DHS Enterprise Data Center(s). Please note that all the subsections from Security Authorization to Log Retention must be included in this requirement to comply with 4300A Information Security Systems Program 4300A version 13.4, December 6, 2024.

Security Authorization A Security Authorization of any infrastructure directly in support of the DHS information system shall be performed as a general support system (GSS) prior to DHS occupancy to characterize the network, identify threats, identify vulnerabilities, analyze existing and planned security controls, determine likelihood of threat, analyze impact, determine risk, recommend controls, perform remediation on identified deficiencies, and document the results. The Security Authorization shall be performed in accordance with the DHS Security Policy and the controls provided by the hosting provider shall be equal to or stronger than the FIPS 199 security categorization of the DHS information system.

At the beginning of the contract, and annually thereafter, the contractor shall provide the results of an independent assessment and verification of security controls. The independent assessment and verification shall apply the same standards that DHS applies in the Security Authorization Process of its information systems. Any deficiencies noted during this assessment shall be provided to the COR for entry into the DHS’ Plan of Action and Milestone (POA&M) Management Process. The contractor shall use the DHS’ POA&M process to document planned remedial actions to address any deficiencies in information security policies, procedures, and practices, and the completion of those activities. Security deficiencies shall be corrected within the timeframes dictated by the DHS POA&M Management Process. Contractor procedures shall be subject to periodic, unannounced assessments by DHS officials. The physical aspects associated with contractor activities shall also be subject to such assessments.

The Government may elect to conduct periodic reviews to ensure that the security requirements contained in this contract are being implemented and enforced. The Government, at its sole discretion, may obtain assistance from other Federal agencies and/or third-party firms to aid in security review activities. Within ten working days’ notice, the Contractor shall afford DHS, the Office of the Inspector General, other government organizations, and Contractors working in support of the Government access to the Contractor’s facilities, installations, operations, documentation, databases, networks, systems, and personnel used in the performance of this contract. The Contractor shall, through the Contracting Officer and Contracting Officer’s Representative (COR), contact the Component or Headquarters Chief Information Officer, or designee, to coordinate and participate in the review and inspection activity of government organizations external to the DHS. Access shall be provided, to the extent necessary as determined by the Government (including providing all requested images), 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 to preserve evidence of computer crime.

1.2 ITAR SME Cybersecurity Supply Chain Risk Management ( C-SCRM )

Cybersecurity C-SCRM language is applicable for requirements for the use of supplies and services to include the following:

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.

1.3 ITAR SME Enterprise Architecture

https://usdhs.sharepoint.com/sites/dhsconnect/org/comp/mgmt/ocio/cto/Pages/ITAR·Submission· EA·Compliance.aspx

This is a list of EA Architecture Compliance language agreed upon between Components and HQ DHS to be used in preparing SOW, PWS & SOO for IT acquisitions & services. The following Components—CBP, TSA and USCG—have their own customized version listed below that must be used. All other Components must use the DHS Enterprise Architecture Compliance language that follows.

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.

DHS-TSA Enterprise Architecture Compliance [update as of December 2022]

a) The Contractor shall ensure that all architectural artifacts including but not limited to solutions, business, Data, IT elements for legacy Transportation Security Equipment (TSE), Information Systems Security Agreements (ISSAs), System Design documents (SDDs), https://usdhs.sharepoint.com/sites/dhsconnect/org/comp/mgmt/ocio/cto/Pages/ITAR%C2%B7Submission%C2%B7EA%C2%B7Compliance.aspx https://usdhs.sharepoint.com/sites/dhsconnect/org/comp/mgmt/ocio/cto/Pages/ITAR%C2%B7Submission%C2%B7EA%C2%B7Compliance.aspx deliverables, and services are aligned and compliant with the current DHS and TSA Enterprise Architecture, the Common Approach to Federal Enterprise Architecture, the Technology Business Management (TBM) Taxonomy, and Federal Information Technology Acquisition Reform Act (FITARA).

i. All solutions and services shall meet DHS and TSA Enterprise Architecture policies, standards, and procedures. Specifically:

a. DHS and TSA Enterprise Architecture policies, standards, and procedures.

b. Homeland Security Enterprise Architecture (HLS EA) and TSA EA requirements.

c. TSA and DHS IT Security, Cloud, Infrastructure (including Network), Application/Systems, Information/Data, Performance, and Business Architecture policies, directives, guidelines, standards, segment architectures and reference architectures.

d. TSA functional capabilities

e. TSA operational capabilities

f. TSA lines of business

g. TSA business processes

h. TSA funding sources

i. TBM Taxonomy for IT cost transparency

ii. All software and tools that are used to build, develop, or deploy IT solutions for TSA, shall leverage the TSA NextGen Architecture (NGA) Technology Stack known as “The Kit”. In accordance with TSA CIO Priority 2.1 “Modernize, Simplify, Reduce and Enforce TSA IT and Data Toolkit”, use of “the Kit” will achieve modernization and simplification, with the ultimate goal of reducing the current TSA Technology Footprint.

iii. This includes new Transportation Security Equipment (TSE) and Legacy TSE that utilizes IT software, services, or equipment including embedded IT elements such as network switches, routers, In printers, etc.

iv. All solutions shall implement, and leverage TSA information and data standards as defined and approved per TSA policy.

v. All solution architectures and services (e.g., Application, System, Network, Security, Information/Data, Cloud) shall be reviewed and approved by TSA EA as part of the TSA SELC (System Engineering Life Cycle) review process and in accordance with TSA IT Governance Management Directive 1400.20 with applicable DHS and TSA IT governance policies, directives, and processes. This includes the Solution Engineering Review (SER), Preliminary Design Review (PDR) and Critical Design Review ( CDR ) stage gates. The required design artifacts include solution approach document, the PDR document, and System Design Document (SDD) as directed by EAD. Successful completion of the PDR/CDR stages results in an approved architecture which is required before proceeding to development. An approved architecture is also a necessary critical step in receiving an Authority to Operate (ATO). All implementations shall follow the approved solution architecture/design without deviation. Any changes, to either the prior approved solution and/or prior approved design that are identified during subsequent SELC phases, including testing, implementation and deployment, shall undergo additional EA review prior to proceeding.

vi. TSA Offices acquiring Enterprise architecture type services at segment or solution levels shall engage and collaborate with the TSA Enterprise Architecture Division (EAD) to ensure strategic alignment of people, process, information, and technology and comply with enterprise level architecture governance, artifacts and standards.

a. The Contractor shall engage domain architect(s) in EAD before SELC Obtain Phase, i.e., during SELC Need or “Analyze and Select” Phase.

b. The Contractors shall collaborate with the EA domain architect(s) to deliver the required design artifacts and desired outcome under the guidance.

c. The Contractor shall provide architecture and system/application data and models in prescribed formats to be stored in TSA's Enterprise Architecture Repository.

b) In accordance with the TSA Cloud Strategy 2.0, April 2019, TSA's approach to cloud computing and governance of migration to the cloud, the contractor shall ensure that the cloud solutions utilize the SaaS (Software as a Service) model as its primary approach to cloud implementation, and also, when necessary, will use Platform as a Service (PaaS) or Infrastructure as a Service (IaaS). The contractor shall adhere to the principles of cloud strategy to systematically retire or replace legacy applications by use of an integrated approach to cloud planning, architecture, hybrid deployment, and operation.

c) 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-21-07, November 2020) 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.

Information and Data Governance and Management

d) The Contractor shall develop, use, and dispose of TSA information and data assets following the TSA governance processes established by the Enterprise Information/Data Governance Board (EIDGB), in compliance with the DHS Enterprise Data Governance and Management MD (Management Directive) 103-01.

i. TSA information and data assets include but are not limited to the TSA Data Catalog, TSA information and data standards, TSA Data Management Plan, TSA data sets (including open data sets for public consumption), TSA information and data stored in https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf https://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_103_01_enterprise_data_management_policy.pdf https://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_103_01_enterprise_data_management_policy.pdf

TSA repositories, TSA information and data in systems and applications (internal and external), and TSA information exchanges.

ii. All TSA information and data, and all solutions that capture, store, use and provide TSA information and data shall comply with the Geospatial Data Act (GDA) of 2018 (P.L.

115-254) that requires agencies to foster efficient management of geospatial data/information, technologies, and infrastructure through enhanced coordination among Federal, state, local, and tribal governments, along with private sector and academia.

iii. Description information for all data assets shall be submitted to the TSA Enterprise Architecture Team, who will be responsible for coordination with DHS, and for review, approval and insertion into the TSA Data Reference Model and Enterprise Architecture Repository.

iv. In addition to the Federal Acquisitions Regulations (FAR) Subpart 27.4 – 'Rights in Data and Copyrights' and Section 35.011 detailing technical data delivery, the contractor shall provide all TSA-specific data in a format maintaining pre-existing referential integrity and data constraints, as well as data structures in a format understandable to TSA. Examples of data structures can be defined as, but not limited to:

1. Data models containing entities and attributes, identifying authoritative and trusted data sources, and depicting relationship mapping and, or linkages

2. Metadata information to define data definitions

3. Detailed data formats, type, and size

4. Delineations of the referential integrity (e.g., primary key/foreign key) of data schemas, structures, and or taxonomies

5. Information exchange specifications

v. All TSA-specific data shall be delivered in a secure and timely manner to TSA. Data security is defined within the 'Requirements for Handling Sensitive, Classified, and/or Proprietary Information', section of this SOW (Statement of Work), SOO (Statement of Objectives) and PWS (Performance Work Statement). This definition complies with not only the delivery of data, but also maintaining TSA-specific data within a non-TSA or DHS proprietary system.

vi. All metadata shall be pre-defined upon delivery to TSA. Metadata shall be delivered in a format that is readily interpretable by TSA (e.g., metadata shall be extracted from any metadata repository that is not utilized by TSA and delivered in a TSA approved manner). Metadata shall also provide an indication of historical version, the most current data to be used, as well as frequency of data refreshes.

vii. The contractor shall provide a Data Asset Repository Profile (DAR) and Data Management Plan (DMP) to EA using EA provided template before the preliminary/critical design review. The DAR and DMP include conceptual and logical data models, data dictionaries, data asset profile, and other artifacts pertinent to the project's data.

viii. TSA adheres to the DHS NIEM (National Information Exchange Model) First policy and standards outlined in the DHS Memorandum, “Adoption of the National Information Exchange Model within the Department of Homeland Security," dated May 3, 2019. All TSA information and data exchanges shall be NIEM compliant. All TSA solutions that leverage TSA information and data exchanges shall be NIEM compliant.

DHS-USCG Enterprise Architecture Compliance

All solutions and services shall meet DHS and USCG Enterprise Architecture policies, standards, and procedures. Specifically, the contractor shall comply with the following Homeland Security Enterprise Architecture (HLS EA) and USCG EA requirements:

• All developed solutions and requirements shall be compliant with the HLS and USCG EAs.

• All IT hardware and software shall be compliant with the HLS EA Technical Reference Model (TRM) Standards and Products Profile and with the USCG IT Products and Standards Inventory.

• Description information for all data assets, information exchanges and data standards, whether adopted or developed, shall be submitted to USCG Enterprise Architecture Division (EAD) and DHS Enterprise Architecture Division (EAD) for review, approval and insertion into the USCG and 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.

DHS-CBP Enterprise Architecture Compliance

The Offeror shall ensure that the design conforms to the Department of Homeland Security (DHS) and Customs and Border Protection ( CBP ) Enterprise Architecture (EA), the DHS and CBP Technical Reference Models (TRM), and all DHS and CBP policies and guidelines (such as the CBP Information Technology Enterprise Principles and the DHS Service http://cbpnet.cbp.dhs.gov/linkhandler/cbpnet/oit/edme/soa.ctt/soa.pdf

Oriented Architecture - Technical Framework), as promulgated by the DHS and CBP Chief Information Officers (CIO), Chief Technology Officers ( CTO ) and Chief Architects ( CA ).

The Offeror shall conform to the Federal Enterprise Architecture (FEA) model and the DHS and CBP versions of the FEA model, as described in their respective EAs. All models will be submitted using Business Process Modeling Notation (BPMN 1.1 or BPMN 2.0 when available) and the CBP Architectural Modeling Standards. Universal Modeling Language (UML2) may be used for infrastructure only. Data semantics shall be in conformance with the National Information Exchange Model (NIEM). Development solutions will also ensure compliance with the current version of the DHS and CBP target architectures.

Where possible, the Offeror shall use DHS/CBP approved products, standards, services, and profiles, as reflected by the hardware, software, application, and infrastructure components of the DHS/CBP TRM/standards profile. If new hardware, software, or infrastructure components are required to develop, test, or implement the program, these products will be coordinated through the DHS and CBP formal Technology Insertion (TI) process (to include a trade study with no less than four alternatives, one of which reflecting the status quo and another reflecting multi-agency collaboration). The DHS/CBP TRM/standards profile will be updated as TIs are resolved.

All developed solutions shall be compliant with the Homeland Security (HLS) EA. All IT hardware and software shall be compliant with the HLS EA. Compliance with the HLS EA shall be derived from and aligned through the CBP EA.

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. 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 EA (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 USGv6 Profile (NIST Special Publication 500-267) and the corresponding declarations of conformance, defined in the USGv6 Test Program.

1.4 ITAR SME FedRAMP – Cloud and 'as-a-Service'

When procuring or considering cloud services, language must be updated/added to the requirements document and include the following language:

(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:

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.

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.

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

1.5 ITAR SME Geospatial DATA ACT (GDA)

In accordance with the Geospatial Data Act (GDA) of 2018 (U.S. Code, Title 43 – Public Lands, Chapter 46: Geospatial Data) all vendors shall:

• Ensure that all geospatial data, created or procured, complies with, Federal Geographic Data Committee (FGDC) endorsed standards and Department of Homeland Security Geospatial Management Office policies and best practices for metadata, records retention and privacy requirements.

• Ensure interoperability of geospatial data and allocate resources for effective data management.

• Support DHS in reducing duplicative data acquisition, as appropriate, by searching available data at Data.gov, Sam.gov and data from Homeland Security Enterprise partners (including, state, local, Tribal governments, private sector, and academia).

• Ensure that geospatial data is made available to the public, as appropriate

1.6 ITAR SME Identity and Credentials Management (ICAM)

https://us-cert.cisa.gov/report https://us-cert.cisa.gov/report https://www.fgdc.gov/metadata https://www.fgdc.gov/metadata https://usdhs.sharepoint.com/sites/dhsconnect/org/comp/mgmt/ocio/cdod/Pages/GMO.aspx https://usdhs.sharepoint.com/sites/dhsconnect/org/comp/mgmt/ocio/cdod/Pages/GMO.aspx https://data.gov/ https://sam.gov/

HSPD-12:

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.

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’s 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.

PIV/CAC Language For Coast Guard

The Homeland Security Presidential Directive 12 (HSPD-12)

The Homeland Security Presidential Directive 12 (HSPD-12) requires the use of the Personal Identity Verification (PIV)/Common Access Card ( CAC ) credentials as the common means of authentication for access to DHS facilities, networks, and information systems. PIV/( CAC ) credentials shall be used as the primary means of logical authentication for DHS sensitive systems. The Contractor must use his or her federal issued PIV/( CAC ) credentials to access DHS resources to include IT applications and physical facility.

The DHS Security Office shall be notified of all terminations/resignations within five (5) days of occurrence. The Contractor shall return to the Contracting Officer’s Representative (COR) all DHS issued PIV/CAC credentials / identification cards and building passes that have either expired or have been collected from terminated employees. If a PIV/CAC credential/identification card or building pass is not available to be returned, a report shall be submitted to the COR, referencing the PIV/CAC credential, pass or card number, name of individual to who it was issued and the last known location and disposition of the PIV/CAC credential, pass or card.

1.7 ITAR SME Privacy

If a contractor will have access to any IT systems that collect, process, store, or transmit controlled unclassified information, which included Personally Identifiable Information (PII) and/or Sensitive PII, include the following clauses:

• FAR 52.224-3 Privacy Training – Alternate I (DEVIATION) (see FAR Class Deviation 17-03, Revision 1) (July 2023)

• HSAR 3052.204-71 Contractor Employee Access (July 2023)

• HSAR 3052.204-72 Safeguarding Controlled Unclassified Information (July 2023)

• HSAR 3052.204-73 Notification and Credit Monitoring Requirements for Personally Identifiable Information Incidents (July 2023)

• Special Clause Information Technology Security Awareness Training (July 2023) (see HSAR Class Deviation 15-01, Revision 1)

ALTERNATE I (JULY 2023)

When the contract will require Contractor employees to have access to information resources, add the following paragraphs:

(g) Before receiving access to information resources under this contract, the individual must complete a security briefing; additional training for specific categories of CUI, if identified in the contract; and any nondisclosure agreement furnished by DHS. The Contracting Officer’s Representative (COR) will arrange the security briefing and any additional training required for specific categories of CUI.

(h) The Contractor shall have access only to those areas of DHS information resources explicitly stated in this contract or approved by the COR in writing as necessary for performance of the work under this contract. Any attempts by Contractor personnel to gain access to any information resources not expressly authorized by the terms and conditions in this contract, or as approved in https://www.dhs.gov/sites/default/files/2023-08/23_0803_cpo_FAR-17-03-Privacy-Training.pdf https://www.dhs.gov/sites/default/files/2023-07/HSAR%20Deviation%2015-01%20Rev%201%20Safeguarding%20of%20CUI.pdf writing by the COR, are strictly prohibited. In the event of violation of this provision, DHS will take appropriate actions with regard to the contract and the individual(s) involved.

(i) Contractor access to DHS networks from a remote location is a temporary privilege for mutual convenience while the Contractor performs business for DHS. It is not a right, a guarantee of access, a condition of the contract, or government-furnished equipment (GFE).

(j) Contractor access will be terminated for unauthorized use. The Contractor agrees to hold and save DHS harmless from any unauthorized use and agrees not to request additional time or money under the contract for any delays resulting from unauthorized use or access.

(k) Non-U.S. citizens shall not be authorized to access or assist in the development, operation, management, or maintenance of Department IT systems under the contract, unless a waiver has been granted by the Head of the Component or designee, with the concurrence of both the Department’s Chief Security Officer ( CSO ) and the Chief Information Officer (CIO) or their designees. Within DHS Headquarters, the waiver may be granted only with the approval of both the CSO and the CIO or their designees. In order for a waiver to be granted:

(1) There must be a compelling reason for using this individual as opposed to a U.S. citizen; and

(2) The waiver must be in the best interest of the Government.

(l) Contractors shall identify in their proposals the names and citizenship of all non-U.S. citizens proposed to work under the contract. Any additions or deletions of non-U.S. citizens after contract award shall also be reported to the Contracting Officer.

ALTERNATE II (JULY 2023)

When the Department has determined contract employee access to controlled unclassified information or Government facilities must be limited to U.S. citizens and lawful permanent residents, but the contract will not require access to information resources, add the following paragraphs:

(g) Each individual employed under the contract shall be a citizen of the United States of America, or an alien who has been lawfully admitted for permanent residence as evidenced by a Permanent Resident Card (USCIS I-551). Any exceptions must be approved by the Department’s Chief Security Officer or designee.

(h) Contractors shall identify in their proposals, the names and citizenship of all non-U.S.

citizens proposed to work under the contract. Any additions or deletions of non-U.S. citizens after contract award shall also be reported to the contracting officer.

HSAR 3052.204-71 CONTRACTOR EMPLOYEE ACCESS (JULY 2023)

(a) Controlled Unclassified Information ( CUI ) is any information the Government creates or possesses, or an entity creates or possesses for or on behalf of the Government (other than classified information) that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls. This definition includes the following CUI categories and subcategories of information:

(1) Chemical-terrorism Vulnerability Information ( CVI ) as defined in 6 CFR part 27, “Chemical Facility Anti-Terrorism Standards,” and as further described in supplementary guidance issued by an authorized official of the Department of Homeland Security (including the Revised Procedural Manual “Safeguarding Information Designated as Chemical-Terrorism Vulnerability Information” dated September 2008);

(2) Protected Critical Infrastructure Information (PCII) as set out in the Critical Infrastructure Information Act of 2002 (title XXII, subtitle B of the Homeland Security Act of 2002 as amended through Pub. L. 116–283), PCII’s implementing regulations (6 CFR part 29), the PCII Program Procedures Manual, and any supplementary guidance officially communicated by an authorized official of the Department of Homeland Security, the PCII Program Manager, or a PCII Program Manager Designee;

(3) Sensitive Security Information (SSI) as defined in 49 CFR part 1520, “Protection of Sensitive Security Information,” 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 designee), including Department of Homeland Security MD 11056.1, “Sensitive Security Information (SSI)” and, within the Transportation Security Administration, TSA MD 2810.1, “SSI Program”;

(4) Homeland Security Agreement Information means information the Department of Homeland Security receives pursuant to an agreement with State, local, Tribal, territorial, or private sector partners that is required to be protected by that agreement. The Department receives this information in furtherance of the missions of the Department, including, but not limited to, support of the Fusion Center Initiative and activities for cyber information sharing consistent with the Cybersecurity Information Sharing Act of 2015;

(5) Homeland Security Enforcement Information means unclassified information of a sensitive nature lawfully created, possessed, or transmitted by the Department of Homeland Security in furtherance of its immigration, customs, and other civil and criminal enforcement missions, the unauthorized disclosure of which could adversely impact the mission of the Department;

(6) International Agreement Information means information the Department of Homeland Security receives that is required to be protected by an information sharing agreement or arrangement with a foreign government, an international organization of governments or any element thereof, an international or foreign public or judicial body, or an international or foreign private or non-governmental organization;

(7) Information Systems Vulnerability Information (ISVI) means:

(i) Department of Homeland Security information technology (IT) systems data revealing infrastructure used for servers, desktops, and networks; applications name, version, and release; switching, router, and gateway information; interconnections and access methods;

and mission or business use/need. Examples of ISVI are systems inventories and enterprise architecture models. Information pertaining to national security systems and eligible for classification under Executive Order 13526 will be classified as appropriate; and/or

(ii) Information regarding developing or current technology, the release of which could hinder the objectives of the Department, compromise a technological advantage or countermeasure, cause a denial of service, or provide an adversary with sufficient information to clone, counterfeit, or circumvent a process or system;

(8) Operations Security Information means Department of Homeland Security information that could be collected, analyzed, and exploited by a foreign adversary to identify intentions, capabilities, operations, and vulnerabilities that threaten operational security for the missions of the Department;

(9) Personnel Security Information means information that could result in physical risk to Department of Homeland Security personnel or other individuals whom the Department is responsible for protecting;

(10) Physical Security Information means reviews or reports illustrating or disclosing facility infrastructure or security vulnerabilities related to the protection of Federal buildings, grounds, or property. For example, threat assessments, system security plans, contingency plans, risk management plans, business impact analysis studies, and certification and accreditation documentation;

(11) Privacy Information includes both Personally Identifiable Information (PII) and Sensitive Personally Identifiable Information (SPII). PII refers to information that can be used to distinguish or trace an individual’s identity, either alone, or when combined with other information that is linked or linkable to a specific individual; and SPII is a subset of PII that if lost, compromised, or disclosed without authorization could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. To determine whether information is PII, DHS will perform an assessment of the specific risk that an individual can be identified using the information with other information that is linked or linkable to the individual. In performing this assessment, it is important to recognize that information that is not PII can become PII whenever additional information becomes available, in any medium or from any source, that would make it possible to identify an individual. Certain data elements are particularly sensitive and may alone present an increased risk of harm to the individual.

(i) Examples of stand-alone PII that are particularly sensitive include: Social Security numbers (SSNs), driver’s license or State identification numbers, Alien Registration Numbers (A-numbers), financial account numbers, and biometric identifiers.

(ii) Multiple pieces of information may present an increased risk of harm to the individual when combined, posing an increased risk of harm to the individual. SPII may also consist of any grouping of information that contains an individual’s name or other unique identifier plus one or more of the following elements:

(A) Truncated SSN (such as last 4 digits);

(B) Date of birth (month, day, and year);

(C) Citizenship or immigration status;

(D) Ethnic or religious affiliation;

(E) Sexual orientation;

(F) Criminal history;

(G) Medical information; and

(H) System authentication information, such as mother’s birth name, account passwords, or personal identification numbers (PINs).

(iii) Other PII that may present an increased risk of harm to the individual depending on its context, such as a list of employees and their performance ratings or an unlisted home address or phone number. The context includes the purpose for which the PII was collected, maintained, and used. This assessment is critical because the same information in different contexts can reveal additional information about the impacted individual.

(b) Information Resources means information and related resources, such as personnel, equipment, funds, and information technology.

(c) Contractor employees working on this contract must complete such forms as may be necessary for security or other reasons, including the conduct of background investigations to determine suitability. Completed forms shall be submitted as directed by the Contracting Officer.

Upon the Contracting Officer’s request, the Contractor’s employees shall be fingerprinted or subject to other investigations as required. All Contractor employees requiring recurring access to government facilities or access to CUI or information resources are required to have a favorably adjudicated background investigation prior to commencing work on this contract unless this requirement is waived under Departmental procedures.

(d) The Contracting Officer may require the…