SOW.pdf

Department of Homeland Security U.S. Custom and Border Protection (CBP)

U.S. Border Patrol (USBP) Statement of Work

USBP Intelligence Program Management Support For Technology Pilots and Capabilities PR# - TBD

April 24, 2026

1. INTRODUCTION:

The U.S. Border Patrol (USBP) operates in a dynamic threat environment characterized by global terrorism, transnational crime, and changing political and economic conditions, all of which drive increasing volumes and complexity of cross-border activity. To meet these challenges, USBP prioritizes enhanced intelligence and data-driven capabilities to generate timely, accurate, and actionable information that enables the identification, disruption, and dismantlement of threat networks. These capabilities include tools, data services, and related technologies that support the collection, processing, analysis, and dissemination of information derived from a broad range of sources, including publicly available information.

Within this environment, Open-Source Intelligence (OSINT) capabilities play a critical role in leveraging publicly available information to support intelligence production, targeting, and vetting. USBP must be able to collect, triage, process, and analyze large volumes of publicly available information and integrate OSINT-derived insights with other intelligence and law enforcement information, while ensuring that the use of OSINT remains consistent with applicable laws, policies, and oversight requirements.

Separately, the USBP Strategic Collaboration Group (SCG) leads the identification, piloting, and evaluation of advanced technology solutions, such as those supporting vehicle identification and tracking, digital media exploitation, radio frequency signal detection and geolocation, maritime domain awareness, vehicle counter-surveillance, and AI-enabled analytic workflows to enhance situational awareness and agent safety. As the volume, variety, and velocity of available data continue to grow, SCG must ensure that these technology pilots and related capabilities can effectively exploit emerging data sources and technologies in support of USBP’s mission.

2. BACKGROUND:

To maximize the effectiveness of its intelligence and technology capabilities, USBP requires a deliberate and coordinated approach to the planning, governance, and integration of these capabilities, ensuring they are fully aligned with broader intelligence and operational priorities.

The USBP Headquarters Intelligence Division (INTEL) requires program management support to strengthen its ability to efficiently acquire, implement, and sustain platforms and tools that enhance analytic tradecraft, improve targeting and vetting workflows, and increase the speed and quality of intelligence support to operations that protect the homeland.

For OSINT capabilities, USBP must evaluate, implement, and sustain solutions that support the secure, lawful, and auditable use of publicly available information. This includes tools and platforms that can scale with growing data volumes, integrate with existing analytic and operational workflows, and enable analysts to derive timely, accurate, and actionable insights from diverse open sources. A structured approach is required to identify OSINT operational needs, translate those needs into clear technical and performance objectives, and ensure that selected OSINT capabilities can be effectively deployed, maintained, and adapted as mission priorities and the open-source environment evolve.

For SCG-led technology pilots and related capabilities, USBP must be able to plan, execute, assess, and transition promising technologies that address critical mission challenges. This includes evaluating new commercial platforms, data sources, and analytical capabilities; ensuring they can integrate with existing systems and workflows; and determining their operational suitability and impact on mission effectiveness and operational efficiency. A structured approach is required for SCG to define pilot objectives and requirements, manage and monitor pilot execution, assess performance and operational impact, and ensure that selected SCG capabilities can be effectively transitioned to sustain operational use and adapted as technologies and threat networks change over time.

3. SCOPE:

3.1 Business Management

The Contractor shall assist the USBP Headquarters INTEL with managing the coordination and organization of business activities which includes the processes of planning, decision making, organizing, leading, motivation and controlling the human, financial, physical, and information resources to reach INTEL's goals efficiently and effectively.

3.2 Administrative Support

The Contractor shall support the administrative requirements required to meet the day-to-day mission directly supporting INTEL’s management. The Contractor shall help streamline communications, tasks, meetings and other activities. The Contractor shall develop to memoranda and other documents as requested, provide cursory review (quality control) of incoming memoranda and taskers, track and report on the status of taskers, and route documents for review, approval and signature. The Contractor shall assist INTEL’s leadership in preparation for meetings including developing agendas, tracking action items, and distributing meeting minutes. This includes developing PowerPoint presentations and briefing books on INTEL’s initiatives and projects. The Contractor shall also ensure SharePoint and Teams are up to date for clear communication and integration.

3.3 Program Management and Governance Support

The Contractor shall provide program management and governance support to plan, coordinate, and oversee intelligence and technology initiatives, ensuring activities are executed on schedule, within scope, and aligned with USBP priorities. As part of this support, the Contractor may assist USBP in identifying and attracting qualified technical expertise by providing input on position descriptions, qualification criteria, interview materials, and outreach strategies, as directed by the Government; all hiring and selection decisions shall remain the responsibility of the Government.

For OSINT capabilities, the Contractor shall support INTEL in maintaining OSINT program plans and roadmaps, tracking schedules, risks, issues, and interdependencies, and preparing status reports and decision support materials. The Contractor shall help ensure OSINT activities are aligned with broader intelligence and operational priorities and are coordinated with relevant CBP and DHS stakeholders, as directed by the Government.

For SCG technology pilots and related intelligence capabilities, the Contractor shall support INTEL by managing and governing a portfolio of pilots, including capabilities for vehicle identification and tracking, rapid digital media exploitation, radio frequency signal detection and geolocation, maritime domain awareness, vehicle counter-surveillance, and AI-enabled analytic workflows. The Contractor shall coordinate activities and dependencies across pilots and prototypes, maintain integrated pilot program plans and governance artifacts, track progress and risks, and provide regular status reporting and documentation to support Government transition decisions.

3.4 Acquisition Management Support

The Contractor shall provide acquisition management support across the lifecycle of capabilities, from requirements refinement and pre-award planning to ensure that acquired solutions effectively address mission needs.

For OSINT capabilities, the Contractor shall assist INTEL in refining OSINT requirements; developing or updating performance work statements, technical requirements, evaluation criteria, and other acquisition documentation; supporting market research and industry engagement related to OSINT tools, platforms, and data services.

For SCG technology pilots and related capabilities, the Contractor shall provide acquisition management support for solutions emerging from, or informed by, those pilots. This includes translating pilot lessons learned into refined technical and operational requirements, acquisition strategies, and supporting documentation, assisting with planning for transition from pilot/prototype to operational deployment, including operations and sustainment considerations.

3.5 Training Support

The Contractor shall provide training support to enable effective and consistent use of capabilities, ensuring users understand key workflows, configuration concepts, and applicable governance requirements.

For OSINT capabilities, the Contractor shall develop, update, and maintain training materials, job aids, and reference guides that support effective use of OSINT tools, platforms, and processes by USBP INTEL and other authorized CBP users. The Contractor shall support Government-directed delivery of OSINT-related training, document participation and completion, and collect user feedback to inform training and capability refinements, with emphasis on analytic workflows and proper use of publicly available information.

For SCG technology pilots and transitioned capabilities, the Contractor shall develop, update, and maintain user-focused training products that enable USBP and other authorized CBP stakeholders to effectively operate and integrate capabilities such as vehicle identification and tracking, rapid digital media exploitation, radio frequency signal detection and geolocation, maritime domain awareness, vehicle counter-surveillance, and AI-enabled analytic workflows. The Contractor shall support training delivery, track participation, and incorporate user feedback, focusing on operational workflows, basic configuration concepts, and any governance, privacy, or oversight requirements associated with these capabilities.

3.6 Assessment Support

The Contractor shall support the Government in assessing whether capabilities are meeting operational and intelligence needs by providing technical and analytical support for performance measurement, operational evaluation, and decision support.

For OSINT capabilities, the Contractor shall assist INTEL in defining performance measures, metrics, and evaluation criteria; collecting and analyzing qualitative and quantitative data on OSINT usage, effectiveness, and mission impact; and producing assessment summaries and recommendations for enhancement, rationalization, or retirement. The Contractor shall assess the impact of OSINT capabilities on analytic tradecraft, targeting and vetting workflows, and the speed and quality of intelligence support to operations.

For SCG technology pilots and related capabilities, the Contractor shall provide technical and analytical support for independent assessment, integration planning, and operational evaluation. This includes supporting the development and refinement of operational needs, use cases, and technical requirements; assisting with system design reviews, architecture evaluations, and integration planning with existing CBP/USBP systems and workflows; and supporting the planning and execution of tests and evaluations in relevant environments, including scenario design, coordination with Government and vendors, and structured data collection. The Contractor shall assess solutions for performance, usability, scalability, interoperability, reliability, and operational suitability; analyze impacts on mission effectiveness and operational efficiency; and document findings, strengths, limitations, recommended deployment conditions, and recommendations to support Government transition decisions.

3.7 Compliance Support

The Contractor shall support the Government in ensuring that capabilities are planned, implemented, and used in a manner consistent with applicable laws, regulations, and DHS policies, including requirements related to privacy, civil liberties, and information protection.

For OSINT capabilities, the Contractor shall support USBP INTEL in developing and maintaining documentation, processes, and artifacts that demonstrate appropriate use of publicly available information and compliance with applicable privacy and civil liberties requirements. The Contractor shall assist, as directed, in coordination with CBP and DHS privacy, civil liberties, security, and records management offices. The Contractor and the Government shall use publicly available information for research and analysis in accordance with applicable privacy laws and DHS policies, ensuring appropriate protection of information related to lawful First Amendment activities (including free speech, assembly, and association). The Contractor shall not collect, retain, or analyze information solely on the basis of an individual’s exercise of these rights and shall implement safeguards to prevent improper use or disclosure.

For SCG technology pilots and transitioned capabilities, the Contractor shall support USBP/SCG in ensuring that these capabilities comply with applicable laws, regulations, DHS policies, and component-specific directives governing classified information and Controlled Unclassified Information (CUI), as applicable. This includes supporting the preparation and maintenance of compliance-related documentation; assisting with readiness for, and response to, audits, inspections, and reviews; and documenting compliance findings and associated corrective actions, recognizing that legal determinations and inherently governmental decisions remain the responsibility of the Government.

4. APPLICABLE DOCUMENTS:

Commercial standards shall be used wherever practicable. The Contractor shall adhere to the requirements found in Part 24 of the Federal Acquisition Regulation, Protection of Privacy and Freedom of Information Act.

5. DELIVERABLES AND DELIVERY SCHEDULE:

The contractor shall submit all deliverables on their respective due date and media type as specified in the table below:

Task Deliverable Due Date Content Acceptance Criteria

3.3 Kickoff Brief, Agenda, and Meeting Notes TBD

Program objectives, stakeholders, initial execution plan

Complete, accurate, delivered on time

3.3 Program Management

Plan TBD

Scope, roles, schedule approach, risk/issue process, communications plan

Government approval of submission, or documented revisions

All Monthly Status Report By the 5th business day of each month

Accomplishments, planned activities, risks/issues, staffing, KPIs

Submitted on time; factual and actionable

3.3 License Utilization

Report

By the 5th business day of each month

Utilization trends, active users, inactive account candidates, recommendations

Data-backed; clear recommendations; delivered on time

3.3 Quarterly Program

Performance Report

Quarterly KPI trends, risks/issues

Evidence-based; supports program decision-making summary, recommendations

3.5

Training Plan TBD Curriculum outline, training cadence, audience tiers, materials plan

Government approval or documented revisions provided

3.5 Training Materials Package

Initial delivery + updates as needed

Slide decks and quick-reference guides

Usable artifacts; properly marked; Government acceptance obtained

3.5

Training Effectiveness Summary

Quarterly Attendance records, feedback themes, recommended improvements

Complete and actionable

3.7

Compliance Support Package

As directed by the Government

PTA support inputs, artifact updates, compliance checklists

Meets Government format and safeguarding requirements

All Transition/Closeout Report

60-90 Days before End of Period of Performance

Lessons learned, artifact inventory, sustainment recommendations

All artifacts delivered; no open critical actions

6. PERIOD OF PERFORMANCE:

The period of performance shall begin on date of task order award with a 12-month base period of performance:

Base Year: 12 months from award

7. PLACE OF PERFORMANCE:

The place of performance shall be both at the contractor's facility and CBP facilities.

8. GOVERNMENT-FURNISHED EQUIPMENT AND INFORMATION:

The Government does not anticipate providing any Government-Furnished Equipment (GFE).

Upon completion of a CBP BI, a computer workstation at the Government site will be provided to contractors working on-site. On a case-by-case basis, additional items will be issued depending upon requirements of the Government. The Government will also provide access to copiers and printers.

9. SECURITY REQUIREMENTS:

All USBP facilities are secure premises. The facility location has a visitor's entrance to arrange an escort with POC. All suppliers are prohibited from entering a controlled area unless escorted or accompanied by CBP personnel. Pictures and/or videos are prohibited upon entering the facility.

10. CONTRACT ADMINISTRATION:

10.1 POC: TBD

Contracting Officer’s Representative (COR):

Name: TBD Office: TBD Email: TBD

CONTRACTING OFFICER (CO):

Name: TBD Office: TBD Email: TBD

10.2 Contracting Officer (CO):

The Contracting Officer is the only person authorized to make or approve any changes to any of the requirements of this contract. In the event the Contractor makes any changes at the direction of any other person other than the CO, the change shall be considered to have been made without authority, and the Contractor performs at its own risk. All questions concerning this contract shall be directed to the Contracting Officer.

11. SPECIAL CONSIDERATIONS:

11.1 Changes to the SOW:

No changes to this SOW or cost increases shall be incurred without written prior approval of the Contracting Officer as coordinated by the COR. Any changes or cost increases will not take effect until the Contracting Officer executes a written modification.

11.2 Travel:

Travel is not required to support the tasks identified in this SOW.

11.3 Disclosure of Information:

Any information made available to the contractor by the government, or its customers shall be used solely for the purpose of carrying out the provisions of this contract. This information shall not be divulged or made known in any mailto:joshua.e.porter@cbp.dhs.gov manner to any persons except as may be necessary in the performance of the contract. In the performance of this contract, the contractor assumes responsibility for the protection of the confidentiality of government records.

11.4 Artificial Intelligence:

The contractor must disclose as post-award deliverable how the contractor is going to meet requirements of this SOW and related Tasks and Deliverables. The contractor’s AI compliance and risk management plan is a deliverable and must address various elements and AI Safeguards.

Elements to be addressed in the AI compliance and risk management plan Deliverable.

The contractor shall:

1. Identify specific tasks or functions for which AI will be used.

2. Disclose how AI-generated data will be stored, utilized, and retained or deleted.

3. Identify if the AI technologies planned to be used, including GenAI tools, during performance of the contract are open-source, proprietary or any other type.

4. Describe what AI safeguards are in place, and how the contractor employs AI compliance, risk mitigation and management practices, measures taken to prevent unauthorized data access, and strategies to mitigate bias in AI outcomes, considering principles identified within AI directives and policies.

5. Describe how the contractor will assess and ensure that implementing AI-related technologies does not produce disparate and unfair outcomes;

covers privacy, civil rights, and civil liberty concerns; and the means to prevent misuse, unauthorized use, or corruption of AI systems.

6. Ensure that the contractor’s use of AI product or solution will not make or support decisions, based on illegal consideration of race, ethnicity, gender, national origin, religion, sexual orientation, gender identity, age, nationality, medical condition, or disability in violation of Title VII of the Civil Rights Act of 1964 (Title VII), the Americans with Disabilities Act of 1990 (ADA), and the Age Discrimination in Employment Act of 1967 (ADEA), as amended.

7. The Government reserves the right to review and approve or disapprove the proposed use of AI technology in the performance of this contract. The contractor must obtain the Contracting Officer’s written acceptance and approval of the AI compliance and risk management plan (Deliverable) that lists all AI technologies and tools.

8. Deliverable Timeline: The contractor shall provide the Artificial Intelligence (AI) compliance and risk management plan within 10 days after the contract award and on reoccurring basis as directed by the Contracting Officer. The contractor will provide an updated AI compliance and risk management plan if any changes to the use of AI take place outside of established timeline.

12. INVOICE INSTRUCTIONS:

The Contractor shall submit invoices in accordance with the terms of the contract, this Statement of Work (SOW), and applicable Federal Acquisition Regulation (FAR) requirements. Invoices shall be submitted only after completion and Government acceptance of the associated deliverables or services.

12.1 Invoice Submission: The Contractor shall submit one (1) FFP invoice for the Base Period thirty days (30) after the contract award for the full amount of the POP outlined in Section 6.0 of this SOW. Option(s) shall be invoiced thirty days (30) after a fully ratified modification to exercise the option for the full amount of the POP outlined in Section 6.0 of this SOW. The invoice shall be simultaneously transmitted electronically to the COR at the e-mail address provided in Section 10.1, and the Contractor shall invoice CBP per CBP invoicing clause, “Electronic Invoicing and Payment Requirements – Invoice Processing Platform (IPP) (JAN 2016).”

12.2 Invoice Content Requirements: Each invoice submitted by the Contractor shall include the following:

1. Contract number and task order number (if applicable)

2. Contractor name, address, and point of contact

3. Invoice number and invoice date

4. Description of services provided

5. Period of performance covered by the invoice

6. Quantity, unit price, and total amount billed

7. Cumulative amount billed to date

8. Any required supporting documentation

Invoices shall be submitted electronically in PDF format unless otherwise authorized by the Contracting Officer. Payment requests shall be submitted electronically through the U. S.

Department of the Treasury's Invoice Processing Platform System (IPP) at: https://www.ipp.gov.

A courtesy e-mail notification upon invoice submission in IPP shall be sent by the Contractor to the COR. Only the CO has the authority to represent the Government in cases where the delivery order requires a change in the terms and conditions, delivery schedule, scope of work and/or price of the products and/or services under this task order.

13. Proof of Delivery or Performance: Each invoice shall include proof of delivery or performance, as applicable:

1. Physical Deliverables: Signed packing slip or delivery receipt.

2. Software or Services: Acceptable “soft” delivery confirmation, such as:

2.1 Email confirmation of delivery or system access

2.2 License activation notice

2.3 Screenshot or system-generated confirmation

3. Written confirmation of service completion

4. Proof shall demonstrate Government receipt and acceptance of the required deliverable or service.

https://www.ipp.gov/

Invoice Review and Acceptance: The Government will review invoices to ensure accuracy and compliance with contract requirements. Invoices that are incomplete, inaccurate, or missing required documentation may be rejected and returned to the Contractor for correction.

ADDENDUM A

Contract Clauses

Enterprise Architecture (EA) 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 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 architecture.

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 reflects 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 Data Management Office (EDMO) for review, approval, and insertion into the DHS Data Reference Model and Enterprise Architecture Information Repository.

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.

SAFEGUARDING OF SENSITIVE INFORMATION (MAR 2015)

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

(b) Definitions. As used in this clause—

“Personally Identifiable Information (PII)” means information that can be used to distinguish or trace an individual's identity, such as name, social security number, or biometric records, either alone, or when combined with other personal or identifying information that is linked or linkable to a specific individual, such as date and place of birth, or mother’s maiden name. The definition of PII is not anchored to any single category of information or technology. Rather, it requires a case-by-case assessment of the specific risk that an individual can be identified. In performing this assessment, it is important for an agency to recognize that non-personally identifiable information can become personally identifiable information whenever additional information is made publicly available—in any medium and from any source—that, combined with other available information, could be used to identify an individual.

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

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

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

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

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

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

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

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

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

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

(3) Citizenship or immigration status

(4) Ethnic or religious affiliation

(5) Sexual orientation

(6) Criminal History

(7) Medical Information

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

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

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

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

(2) DHS 4300A Policy Directive (Version 13.3, February 13, 2023)

(3) DHS Security Authorization Process Guide

(4) DHS Handbook for Safeguarding Sensitive Personally Identifiable Information

(5) DHS Instruction Handbook 121-01-007 Department of Homeland Security Personnel

Suitability and Security Program

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

(7) DHS Privacy Incident Handling Guidance

(8) Federal Information Processing Standard (FIPS) 140-2 Security Requirements for

Cryptographic Modules accessible at http://csrc.nist.gov/groups/STM/cmvp/standards.html

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

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

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

(1) Department of Homeland Security (DHS) policies and procedures on Contractor personnel security requirements are set forth in various Management Directives (MDs), Directives, and Instructions. MD 11042.1, Safeguarding Sensitive but Unclassified (For Official Use Only) Information describes how Contractors must handle sensitive but unclassified information. DHS uses the term “FOR OFFICIAL USE ONLY” to identify sensitive but unclassified information that is not otherwise categorized by statute or regulation. Examples of sensitive information that are categorized by statute or regulation are PCII, SSI, etc. The DHS 4300A Policy Directive (Version 13.3, February 13, 2023) provide the policies and procedures on security for Information Technology (IT) resources. The DHS Handbook for Safeguarding Sensitive Personally Identifiable Information provides guidelines to help safeguard SPII in both paper and electronic form. DHS Instruction Handbook 121-01-007 Department of Homeland Security Personnel Suitability and Security Program establishes procedures, program responsibilities, minimum standards, and reporting protocols for the DHS Personnel Suitability and Security Program.

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

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

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

(e) Authority to Operate. The Contractor shall not input, store, process, output, and/or transmit sensitive information within a Contractor IT system without the Authority to Operate (ATO) signed by the Headquarters or Component CIO, or designee, in consultation with the Headquarters or Component Privacy Officer. Unless otherwise specified in the ATO letter, the ATO is valid for three (3) years. The Contractor shall adhere to current Government policies, procedures, and guidance for the Security Authorization (SA) process as defined below.

(1) Complete the Security Authorization process. The SA process shall proceed according to the DHS 4300A Policy Directive (Version 13.3, February 13, 2023), or any successor publication, and the Security Authorization Process Guide including templates.

(i) Security Authorization Process Documentation. SA documentation shall be developed using the Government provided Requirements Traceability Matrix and Government security documentation templates. SA documentation consists of the following: Security Plan, Contingency Plan, Contingency Plan Test Results, Configuration Management Plan, Security Assessment Plan, Security Assessment Report, and Authorization to Operate Letter. Additional documents that may be required include a Plan(s) of Action and Milestones and Interconnection

Security Agreement(s). During the development of SA documentation, the Contractor shall submit a signed SA package, validated by an independent third party, to the COR for acceptance by the Headquarters or Component CIO, or designee, at least thirty (30) days prior to the date of operation of the IT system. The Government is the final authority on the compliance of the SA package and may limit the number of resubmissions of a modified SA package. Once the ATO has been accepted by the Headquarters or Component CIO, or designee, the Contracting Officer shall incorporate the ATO into the contract as a compliance document. The Government’s acceptance of the ATO does not alleviate the Contractor’s responsibility to ensure the IT system controls are implemented and operating effectively.

(ii) Independent Assessment. Contractors shall have an independent third party validate the security and privacy controls in place for the system(s). The independent third party shall review and analyze the SA package, and report on technical, operational, and management level deficiencies as outlined in NIST Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations. The Contractor shall address all deficiencies before submitting the SA package to the Government for acceptance.

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

(2) Renewal of ATO. Unless otherwise specified in the ATO letter, the ATO shall be renewed every three (3) years. The Contractor is required to update its SA package as part of the ATO renewal process. The Contractor shall update its SA package by one of the following methods: (1) Updating the SA documentation in the DHS automated information assurance tool for acceptance by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls; or (2) Submitting an updated SA package directly to the COR for approval by the Headquarters or Component CIO, or designee, at least 90 days before the ATO expiration date for review and verification of security controls. The 90-day review process is independent of the system production date and therefore it is important that the Contractor build the review into project schedules. The reviews may include onsite visits that involve physical or logical inspection of the Contractor environment to ensure controls are in place.

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

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

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

(6) Federal Reporting Requirements. Contractors operating information systems on behalf of the Government or operating systems containing sensitive information shall comply with Federal reporting requirements. Annual and quarterly data collection will be coordinated by the Government. Contractors shall provide the COR with requested information within three (3) business days of receipt of the request. Reporting requirements are determined by the Government and are defined in the Fiscal Year 2014 DHS Information Security Performance Plan, or successor publication. The Contractor shall provide the Government with all information to fully satisfy Federal reporting requirements for Contractor systems.

(f) Sensitive Information Incident Reporting Requirements.

(1) All known or suspected sensitive information incidents shall be reported to the Headquarters or Component Security Operations Center (SOC) within one hour of discovery in accordance with DHS 4300A Policy Directive (Version 13.3, February 13, 2023) requirements.

When notifying the Headquarters or Component SOC, the Contractor shall also notify the Contracting Officer, COR, Headquarters or Component Privacy Officer, and US-CERT using the contact information identified in the contract. If the incident is reported by phone or the

Contracting Officer’s email address is not immediately available, the Contractor shall contact the Contracting Officer immediately after reporting the incident to the Headquarters or Component SOC. The Contractor shall not include any sensitive information in the subject or body of any e-mail. To transmit sensitive information, the Contractor shall use FIPS 140-2 Security Requirements for Cryptographic Modules compliant encryption methods to protect sensitive information in attachments to email. Passwords shall not be communicated in the same email as the attachment. A sensitive information incident shall not, by itself, be interpreted as evidence that the Contractor has failed to provide adequate information security safeguards for sensitive information or has otherwise failed to meet the requirements of the contract.

(2) If a sensitive information incident involves PII or SPII, in addition to the reporting requirements in DHS 4300A Policy Directive (Version 13.3, February 13, 2023), Contractors shall also provide as many of the following data elements that are available at the time the incident is reported, with any remaining data elements provided within 24 hours of submission of the initial incident report:

(i) Data Universal Numbering System (DUNS).

(ii) Contract numbers are affected unless all contracts by the company are affected.

(iii) Facility CAGE code if the location of the event is different than the prime contractor location.

(iv) Point of contact (POC) if different than the POC recorded in the System for Award Management (address, position, telephone, email).

(v) Contracting Officer POC (address, telephone, email).

(vi) Contract clearance level.

(vii) Name of subcontractor and CAGE code if this was an incident on a subcontractor network.

(viii) Government programs, platforms or systems involved.

(ix) Location(s) of incident.

(x) Date and time the incident was discovered.

(xi) Server names where sensitive information resided at the time of the incident, both at the Contractor and subcontractor level.

(xii) Description of the Government PII and/or SPII contained within the system.

(xiii) Number of people potentially affected, and the estimate or actual number of records exposed and/or contained within the system; and

(xiv) Any additional information relevant to the incident.

(g) Sensitive Information Incident Response Requirements.

(1) All determinations related to sensitive information incidents, including response activities, notifications to affected individuals and/or Federal agencies, and related services (e.g., credit monitoring) will be made in writing by the Contracting Officer in consultation with the Headquarters or Component CIO and Headquarters or Component Privacy Officer.

(2) The Contractor shall provide full access and cooperation for all activities determined by the Government to be required to ensure an effective incident response, including providing all requested images, log files, and event information to facilitate rapid resolution of sensitive information incidents.

(3) Incident response activities determined to be required by the Government may include, but are not limited to, the following:

(i) Inspections,

(ii) Investigations,

(iii) Forensic reviews, and

(iv) Data analyses and processing.

(4) The Government, at its sole discretion, may obtain assistance from other Federal agencies and/or third-party firms to aid in incident response activities.

(h) Additional PII and/or SPII Notification Requirements.

(1) The Contractor shall have in place procedures and the capability to notify any individual whose PII resided in the Contractor IT system at the time of the sensitive information incident not later than 5 business days after being directed to notify individuals, unless otherwise approved by the Contracting Officer. The method and content of any notification by the Contractor shall be coordinated with, and subject to prior written approval by the Contracting Officer, in consultation with the Headquarters or Component Privacy Officer, utilizing the DHS Privacy Incident Handling Guidance. The Contractor shall not proceed with notification unless the Contracting Officer, in consultation with the Headquarters or Component Privacy Officer, has determined in writing that notification is appropriate.

(2) Subject to Government analysis of the incident and the terms of its instructions to the Contractor regarding any resulting notification, the notification method may consist of letters to affected individuals sent by first class mail, electronic means, or general public notice, as approved by the Government. Notification may require the Contractor’s use of address verification and/or address location services. At a minimum, the notification shall include:

(i) A brief description of the incident.

(ii) A description of the types of PII and SPII involved.

(iii) A statement as to whether the PII or SPII was encrypted or protected by other means.

(iv) Steps individuals may take to protect themselves.

(v) What the Contractor and/or the Government are doing to investigate the incident, to mitigate the incident, and to protect against any future incidents; and

(vi) Information identifying who individuals may contact for additional information.

(i) Credit Monitoring…