USBP-PMOD_20260918_IST_BPTOC-Enterprise-RFI_v1-02_Final.docx

BORDER PATROL TECHNICAL OPERATIONS CENTER SERVICES

REQUEST FOR INFORMATION

DESCRIPTION

U.S. Customs and Border Protection (CBP) is conducting market research through a Request for Information (RFI) on the current availability and capabilities of vendors to provide Border Patrol Technical Operations Center (BPTOC) services in support of U.S. Border Patrol (USBP) detection and surveillance technology portfolios.

BPTOC services include, but are not limited to, operating and managing a centralized Network Operations Center (NOC), Security Operations Center (SOC), and 24 hours a day, 365 days a year Call Center/Helpdesk to coordinate, monitor, track, report, and support operational availability and sustainment activities for deployed border security systems.

In responding to this RFI, vendors should clearly distinguish between functions they can perform directly using their own personnel, tools, facilities, and authorized access; functions they can support or coordinate with Government or third-party stakeholders; and functions that require Government, CBP Office of Information and Technology (OIT), field support, system owner, vendor, or other third-party authority, access, approval, or action. This distinction is especially important for SOC operations, vulnerability management, patching, account administration, backup and restore, incident response, field support, and system ownership activities. Vendors should identify any assumptions, dependencies, constraints, or required government-furnished information, access, tools, approvals, or decisions associated with their proposed approach.

THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR TO OTHERWISE PAY FOR INFORMATION RECEIVED. This RFI is issued solely for information, planning purposes, and market research only. It does not constitute a Request for Proposal (RFP) or a promise to issue an RFP. This research does not commit the Government to contract for any supply or service. CBP will not pay for any costs associated with responding to this RFI. Not responding to this RFI does not preclude participation in any future full and open competition RFP. If a solicitation is released, it will be posted through the appropriate Government acquisition channel. All submissions become the property of the Government and will not be returned. Information obtained from industry responses to this RFI may be used in the development of an acquisition strategy, requirements documents, and any future solicitation.

INTRODUCTION

CBP is responsible for protecting U.S. borders (preventing the entry of terrorists, weapons, contraband, and harmful agricultural products) while facilitating lawful international trade and travel. To accomplish this mission, USBP uses infrastructure, technology, and personnel to predict and deter illicit activity, detect and track illegal border crossings, identify and classify incursions, and respond effectively.

The USBP Program Management Office Directorate (PMOD) manages a portfolio of detection and surveillance technologies deployed across the Nation’s borders. These systems support persistent surveillance, situational awareness, and operational decision-making for field agents and command-and-control users.

To support the operational availability of these systems, PMOD requires BPTOC services that provide centralized monitoring, cybersecurity support, helpdesk support, incident management, service request management, reporting, and sustainment coordination. BPTOC services are expected to support multiple PMOD portfolios and systems, including current and future detection and surveillance technologies.

The BPTOC service community may include, but is not limited to:

· integrated surveillance tower systems;

· linear ground detection systems;

· advanced mobile surveillance systems;

· mobile surveillance systems;

· subterranean detection systems; and

· communications, command-and-control, and other PMOD technologies as directed.

CBP is seeking information from industry on vendor capabilities, technical maturity, service models, staffing approaches, transition strategies, cybersecurity capabilities, and cost drivers associated with providing enterprise BPTOC services.

PURPOSE

CBP is conducting market research to identify qualified sources capable of providing enterprise BPTOC services to support the operational availability, cybersecurity posture, and sustainment coordination of USBP detection and surveillance technologies deployed along the Nation’s borders.

CBP is particularly interested in industry capabilities to provide a managed BPTOC service that includes:

· 24/7/365 NOC support operations;

· 24/7/365 SOC support for BPTOC customer base systems within authorized access, technical control, and government-approved scope of responsibility;

· 24/7/365 call center/helpdesk support;

· Tier 1 and Tier 2 incident management;

· operational availability monitoring and reporting;

· vulnerability scanning, remediation tracking, and approved remediation support within authorized access and technical control;

· patch management support;

· disaster recovery and data backup support;

· program management, dashboards, and reporting;

· support for integration of applicable CBP systems and workflows into the BPTOC operating environment and CBP network, as authorized by the Government; and

· support for multiple task orders or technology portfolios.

CURRENT STATUS

CBP currently operates and sustains multiple border detection and surveillance technologies through separate program and sustainment structures. PMOD seeks to assess industry’s ability to provide enterprise BPTOC services under a contract structure capable of supporting multiple PMOD portfolios, which may include an Indefinite Delivery, Indefinite Quantity (IDIQ) contract structure with task orders aligned to specific portfolios or systems. Vendors should describe how they would distinguish between enterprise BPTOC baseline services and portfolio-specific or task-order-specific requirements, recognizing that PMOD systems may have different support needs, system boundaries, endpoint counts, cybersecurity responsibilities, Government/vendor interfaces, field support assumptions, exclusions, and service levels.

The Government anticipates that BPTOC services may support the initial task order areas listed below.

1. Integrated Surveillance Towers Portfolio

· Remote Video Surveillance System Upgrade

· Remote Video Surveillance System Overhaul

· Remote Video Surveillance System Legacy

· Northern Border Remote Video Surveillance System

· Integrated Fixed Towers

· Autonomous Integrated Surveillance Towers

· Border Wall Integrated Surveillance Systems

2. Mobile Portfolio

· Mobile Video Surveillance System

· Mobile Video Surveillance System with Radar

· Enhanced Mobile Video Surveillance System with Radar

· Mobile Surveillance Capability-Lite

· Enhanced Mobile Surveillance Capability-Lite

· Modular Mobile Surveillance System

3. Subterranean Portfolio

· Linear Ground Detection System Any future task orders are expected to define the applicable system scope, support boundaries, endpoint boundaries, cybersecurity responsibilities, OIT/vendor interfaces, field support assumptions, exclusions, and portfolio-specific service requirements.

The Government may add additional PMOD portfolios or systems to the BPTOC service community in the future.

Request for Information: CBP requests that vendors describe their ability to fulfill the capabilities identified below, in sequence, in a written response. Submission instructions are provided at the end of this RFI.

NOTE: The capabilities listed below do not constitute explicit CBP requirements and may be adjusted prior to any potential future request for proposal or request for quote. Any system quantities, endpoint counts, task order descriptions, timelines, or other details are notional and do not constitute final solicitation requirements.

TECHNICAL REQUIREMENTS

Enterprise BPTOC Service Capability Vendors should describe their capability to establish, operate, maintain, and manage an enterprise BPTOC service that supports multiple detection and surveillance technology portfolios.

At a minimum, responses should address the ability to provide:

· a centralized NOC, SOC, and call center/helpdesk capability;

· 24/7/365 operational readiness and availability;

· support for multiple geographically dispersed systems;

· monitoring of fielded detection and surveillance technology;

· remote root cause analyses, troubleshooting, and Tier 1/Tier 2 support;

· incident, service request, and work order management;

· escalation to government-designated Tier 3 support, field service representatives, sustainment contractors, or in-service engineering activities;

· operational availability tracking and reporting;

· support for systems after deployment, acceptance, and registration within CBP enterprise IT service management/operations management platforms; and

· integration of new and existing CBP Systems into the BPTOC environment.

Network Operations Center Services Vendors should describe their ability to provide NOC services, including:

· real-time monitoring of network performance, bandwidth usage, latency, packet loss, throughput, and system status;

· monitoring of routers, switches, firewalls, servers, endpoints, and supported surveillance/detection system components;

· network traffic analyses, flow data analyses, device communication monitoring, and quality of service visibility;

· anomaly detection and automated alerting;

· proactive identification of network bottlenecks, degraded performance, system downtime, hardware degradation, resource depletion, and configuration issues;

· dashboards that provide real-time system status, alerts, performance metrics, and operational availability data;

· redundancy and failover for BPTOC monitoring systems;

· Tier 2 troubleshooting, root cause analyses, and incident resolution support; and

· documentation and reporting of issues, resolutions, corrective actions, and follow-up actions in CBP-designated systems.

Security Operations Center Services Vendors should describe their ability to provide SOC services and explain their proposed SOC operating model for BPTOC-supported systems. Responses should distinguish whether the vendor’s SOC approach would include full contractor-operated SOC services, SOC augmentation, alert triage and escalation, integration with CBP/OIT SOC capabilities, or another operating model.

Vendors should identify assumptions, dependencies, and required Government decisions related to government-owned SOC tools, Security Information Event Management (SIEM) access, incident authority, access to system logs, escalation to CBP/OIT cybersecurity authorities, system owner coordination, information system security officer (ISSO)/information system security manager (ISSM) coordination, and other third-party support.

Responses should address:

· security monitoring for supported BPTOC customer systems;

· the proposed SOC operating model, including contractor-operated SOC, SOC augmentation, alert triage and escalation, integration with CBP/OIT SOC capabilities, or other proposed model;

· use of government-approved SOC tools, SIEM access, endpoint security tools, log sources, and monitoring capabilities;

· intrusion detection and prevention;

· endpoint security monitoring;

· SIEM integration;

· security event aggregation, analyses, correlation, triage, and escalation;

· identification of unauthorized access, malware, intrusion attempts, distributed denial-of-service activity, anomalous behavior, or other cybersecurity events;

· coordination and escalation to CBP/OIT cybersecurity authorities, system owners, ISSO/ISSM, vendors, or other responsible parties;

· support for forensic investigation and audit trails, where authorized by the Government;

· support for Federal Information Security Modernization Act (FISMA) compliance and authorization to operate processes;

· continuous monitoring and cybersecurity readiness activities;

· support for remediation tracking, coordination, and implementation of approved remediation actions within authorized access and technical control; and

· approach to supporting cybersecurity readiness prior to field roll-out or onboarding of systems into BPTOC services.

Call Center/Helpdesk Services Vendors should describe their ability to provide 24/7/365 call center/helpdesk services, including:

· serving as the single point of contact for BPTOC customer base users and stakeholders;

· receiving calls, emails, alerts, or other notifications;

· creating, updating, tracking, escalating, and closing incidents and service requests;

· providing Tier 1 support root cause analyses and troubleshooting;

· supporting user account issues, access issues, password resets, and system access requests, as authorized;

· supporting end-user device troubleshooting and configuration;

· assisting users with software installation and updates related to supported systems;

· escalating issues to NOC, SOC, field service representatives, sustainment contractors, or government-designated teams when required; and

· maintaining complete and accurate ticket documentation in CBP-designated systems.

Incident Management and Operational Availability Vendors should describe their capability to manage incidents and support operational availability reporting.

Responses should address:

· incident classification by priority or severity;

· differentiation between mission-impacting failures, degraded functionality, and minor issues;

· support for Tier 1, Tier 2, and escalation workflows;

· tracking of incident start time, restoration time, resolution time, root cause, corrective action, and downtime impacts;

· ability to support monthly operational availability calculations by portfolio or system;

· ability to support a threshold and objective operational availability model;

· use of ticketing systems, dashboards, analytics, and reporting tools to support availability analyses; and

· methods for identifying false positives, nuisance alarms, recurring incidents, and systemic issues.

Supported Systems and Endpoint Monitoring Vendors should describe their ability to support diverse surveillance and detection systems, including systems with varying degrees of remote accessibility.

Responses should address:

· endpoint monitoring approach;

· onboarding of new systems and endpoints;

· maintenance of real-time endpoint inventories, including how the vendor would differentiate between monitored endpoints, managed endpoints, vendor-owned endpoints, OIT-owned endpoints, and inaccessible endpoints;

· identification and tracking of decommissioned assets;

· differentiation between monitored endpoints, managed endpoints, vendor-owned endpoints, OIT-owned endpoints, and inaccessible endpoints within endpoint inventory records and reports;

· identification and tracking end of life and end of support timelines for network-critical hardware and software, where data is available or provided by the Government;

· management of endpoint monitoring tools and reports;

· support for systems that cannot be fully accessed remotely, including helpdesk intake, coordination, escalation, reporting, and handoff to field support or other responsible support groups;

· coordination with field service and sustainment personnel for systems requiring on-site support; and

· scalability to support increased endpoint counts over time.

Integration with CBP Systems and Workflows Vendors should describe their ability to integrate BPTOC services with government-provided systems, processes, and workflows.

Responses should address experience or capability integrating with:

· CBP enterprise IT service management/operations management platforms;

· Integrated Logistics Support System (ILSS) or similar logistics/ticketing systems;

· ServiceNow or similar enterprise service management platforms;

· asset management systems;

· configuration management systems;

· vulnerability management systems;

· security scanning and monitoring or SIEM tools;

· Government network access and remote monitoring environments;

· established Government escalation and support workflows; and

· credential and identification management.

Transition and Onboarding Vendors should describe their recommended transition approach for assuming BPTOC operations from an incumbent or prior support model.

Responses should address:

· recommended transition timeline, phases, milestones, and readiness criteria for assuming BPTOC operations;

· recommended transition-in deliverables, including schedules, reports, readiness checklists, risk registers, knowledge transfer artifacts, and operational acceptance artifacts;

· assumptions regarding access to prior support data, tools, documentation, ticket history, monitoring configurations, and operational records;

· approach to conducting knowledge transfer and validating that required operational knowledge is captured;

· approach to planning and executing transition activities while minimizing operational risk;

· approach to scaling and increasing staff, training, certifications, surge support, and personnel vetting;

· approach to implementing, configuring, integrating, and validating tools required to support BPTOC operations, including monitoring, ticketing, reporting, dashboards, vulnerability management, asset management, configuration management, and SIEM-related tools;

· approach to maintaining continuity of 24/7/365 operations during transition;

· approach to onboarding of portfolios, systems, users, sites, and endpoints;

· validation of monitoring, ticketing, reporting, escalation, incident response, and operational availability processes before assuming full or phased operational responsibility, as authorized by the Government;

· approach to developing, refining, updating, and maintaining standard operating procedures (SOP) and other transition documents; and

· approach to identifying, tracking, reporting, and mitigating risks, issues, action items, and dependencies.

SERVICE REQUIREMENTS

Managed Service Model CBP is interested in BPTOC services provided as a managed service. Vendors should describe their service model, including:

· ownership, management, and operation of a BPTOC facility or facilities;

· staffing model for NOC, SOC, and call center/helpdesk functions;

· 24/7/365 coverage model;

· remote work versus facility-based work assumptions, if applicable and authorized;

· tooling, dashboards, reporting, and automation approach;

· interfaces with Government personnel and government-furnished systems;

· approach for interfacing with and updating government-designated systems of record, including ticketing, logistics, asset management, facilities, and enterprise service management systems, such as ILSS, Tririga, and ServiceNow, as applicable;

· methods for maintaining service continuity; and

· ability to support multiple task orders under an enterprise contract.

Staffing Vendors should describe the staffing required to support BPTOC services.

Responses should address:

· program managers;

· NOC operators/NOC analysts;

· SOC operators/SOC analysts;

· network engineers;

· security analysts;

· helpdesk technicians;

· IT systems administrators;

· database/or reporting analysts;

· incident response analyst/incident response technician;

· integrated logistics support specialists;

· information system security officer;

· information system security manager; and

· cybersecurity analyst.

Service Availability Vendors should describe their ability to maintain continuous BPTOC service availability.

Responses should address:

· 24/7/365 operational readiness;

· redundant staffing and continuity planning;

· backup communications;

· facility continuity;

· tool and system failover;

· disaster recovery;

· continuity of operations planning;

· travel and onsite support; and

· methods for preventing BPTOC service outages from affecting supported system monitoring and incident response.

Service Level Expectations CBP is interested in industry feedback on appropriate BPTOC service levels. Vendors should address their ability to support service levels as described below.

Operational Availability Support

· Support Government measurement of operational availability by portfolio or system monthly.

· Support threshold and objective operational availability targets.

· Provide monthly operational availability reporting within five business days at the end of each month.

Incident Response and Resolution Support Vendors should describe their ability to meet or recommend response and resolution timelines for priority incidents. Vendors should also describe how their approach would align with government-designated ticketing systems, ILSS priority assignments, and portfolio-specific priority definitions, including whether scheduled preventive maintenance, planned outages, approved patching, or other non-emergency activities should be handled as a separate category or included within existing Priority 1, Priority 2, or Priority 3 definitions.

Responses should include:

· Priority 1 incidents involving loss of primary mission functions or safety-related issues;

· Priority 2 incidents involving partial failure or degraded primary functionality where mission operations may continue through alternative methods;

· Priority 3 incidents involving minor degradation, issues with available workarounds, scheduled preventive maintenance, planned outages, or approved patching activities, where applicable and consistent with portfolio-specific definitions; and

· any recommended additional priority category or status designation for planned maintenance, planned outages, scheduled patching, deferred maintenance, monitoring-only issues, or non-mission-impacting events.

Vendors should identify recommended acknowledgment, triage, escalation, restoration, and closure timelines for helpdesk, NOC, and SOC functions.

Mean Downtime Support Vendors should describe their ability to support Government measurement and analyses of mean downtime (MDT) by portfolio or system, where applicable and where data is available in government-designated systems.

Responses should address:

· ability to capture, validate, and report outage start time, restoration time, resolution time, downtime duration, and responsible support organization;

· ability to distinguish BPTOC-responsible downtime from downtime attributable to Government action, CBP OIT, field service, vendors, external networks, utilities, weather, access delays, scheduled maintenance, or other factors outside BPTOC control;

· recommended threshold and objective MDT targets for BPTOC service functions, if applicable;

· ability to provide monthly MDT reporting within five business days after the end of each month; and

· use of MDT data to identify recurring issues, systemic degraders, process delays, and opportunities to improve remote troubleshooting and escalation.

Mean Time Between Failure Support Vendors should describe their ability to support Government measurement and analyses of mean time between failures (MTBF) by portfolio or system, where applicable and where data is available in government-designated systems.

Responses should address:

· ability to identify recurring failures, repeat incidents, nuisance alarms, false positives, and systemic issues;

· ability to use ticketing, monitoring, endpoint, and operational availability data to support MTBF analysis;

· recommended threshold and objective MTBF targets for BPTOC service functions, if applicable;

· ability to provide monthly MTBF reporting within five business days after the end of each month; and

· assumptions, limitations, or dependencies affecting MTBF reporting, including system design, field maintenance, sustainment contractor actions, vendor-managed components, and data quality.

Program Management Vendors should describe their approach to program planning and control, including:

· monthly program management reviews;

· monthly program management reports;

· integrated master schedule development and maintenance;

· risk, issue, and action item tracking;

· staffing and resource management;

· cost and schedule management;

· portfolio-level reporting;

· task order-level reporting; and

· performance metrics and trend analyses.

Reporting and Dashboards Vendors should describe their ability to provide reporting and dashboards, including:

· customizable dashboards for Government stakeholders;

· real-time health and status reporting of systems;

· incident metrics;

· service request metrics;

· operational availability reporting;

· cybersecurity metrics;

· vulnerability and patch status reporting;

· endpoint monitoring reports;

· trend analyses;

· executive-level reporting; and

· exportable reports for audit or program management purposes.

Disaster Recovery and Backup Vendors should describe their ability to support disaster recovery and data backup requirements. Vendors should distinguish between virtual machine/platform backups, operating system/configuration backups, application/data backups, log backups, ticketing/reporting backups, and vendor-managed backups. Vendors should identify which backup layers they can perform directly, which they would coordinate with Government or third-party stakeholders, and any assumptions, dependencies, access requirements, tooling requirements, or system ownership constraints that may affect backup and recovery.

Responses should address:

· disaster recovery plan development and maintenance;

· backup of critical BPTOC data, configurations, logs, tickets, reports, and documentation;

· recovery procedures;

· virtual machine/platform backup approach;

· periodic recovery testing;

· staff training on recovery procedures; and

· support for continuity after natural disasters, cyber incidents, hardware failures, human errors, or other disruptions.

Continuous Improvement Vendors should describe their approach to continuous improvement, including:

· gathering feedback from Government stakeholders, field users, and system operators;

· reviewing operational processes;

· identifying inefficiencies and providing recommendations for improvement;

· automating repetitive tasks;

· applying analytics to identify recurring issues;

· using artificial intelligence, robotic process automation, or other tools where appropriate and approved; and

· updating SOPs, training, dashboards, and workflows based on operational lessons learned.

Research, Development, Testing, and Evaluation Support Vendors should describe their ability to provide research, development, testing, and evaluation support for BPTOC modernization and expansion, including:

· identifying emerging technologies and best practices;

· developing and testing prototypes or process improvements;

· conducting pilot programs, simulations, or controlled deployments;

· performing feasibility studies for integrating additional USBP systems into BPTOC services;

· documenting test results, lessons learned, and recommendations;

· developing rough order of magnitude cost estimates for future integration efforts; and

· supporting transition of successful research, development, testing, and evaluation outcomes into production.

SECURITY REQUIREMENTS

The proposed BPTOC service must support CBP cybersecurity, privacy, and system authorization requirements. Vendors must address each security area noted below in detail, describing both technical implementation and operational processes. Vendor responses should distinguish between functions the vendor can perform directly; functions the vendor can support or coordinate; and functions that require Government, CBP OIT, system owner, ISSO/ISSM, vendor, or other third-party authority, access, approval, or action. Vendors should also identify assumptions, dependencies, required government-furnished tools or access, inherited controls, and shared responsibility considerations.

The Government retains authority for cybersecurity governance, risk acceptance, authorization to operate (ATO) decisions, plan of action and milestones (POA&M) ownership, cybersecurity incident reporting authority, incident command, privileged access approval, scan authorization, penetration testing authorization, and enterprise cybersecurity decisions unless expressly delegated in writing. Vendors should describe how they would support these government-retained responsibilities while performing authorized monitoring, reporting, coordination, vulnerability management, and remediation support activities.

Vendors should also describe how they would support systems with vendor-proprietary software, restricted administrative access, vendor-controlled patching, proprietary databases, specialized tuning/calibration requirements, or other constraints that may affect monitoring, vulnerability management, patching, incident response, backup/restore, reporting, or ATO support.

All security controls must be implemented in accordance with applicable federal law, DHS policy, and CBP policy, and must support CBP’s Federal Information Security Modernization Act (FISMA)/Risk Management Framework (RMF) compliance and Authorization to Operate (ATO) process.

Compliance with Federal and DHS/CBP Cybersecurity Policy Vendors should describe how their BPTOC service aligns with applicable federal, DHS, and CBP cybersecurity policies and standards, including, as applicable:

· Federal Information Security Modernization Act;

· NIST SP 800-53, current revision;

· NIST SP 800-171, as applicable;

· DHS 4300A;

· CBP HB 1400-05D;

· FIPS 140-2 or FIPS 140-3 for cryptographic modules, as applicable;

· CBP Product Supply Chain Resiliency Policy; and

· CBP FISMA inventory and continuous monitoring requirements.

Vendors should also describe how they would support RMF/ATO activities without assuming Government ownership or authority for authorization decisions, risk acceptance, control acceptance, or POA&M ownership. Vendors should identify artifacts they can develop, update, or support, and identify which artifacts require Government review, approval, or final decision.

Responses should address support for:

· system security plan documentation;

· security assessment report documentation;

· ATO activities;

· annual security review;

· vulnerability assessment;

· continuous monitoring;

· security control evidence collection and documentation; and

· POA&M input, remediation evidence collection, remediation status tracking, and coordination.

Security Monitoring and Incident Response Vendors should describe their security monitoring and incident response capabilities. Responses should clearly distinguish among security monitoring, alert triage, incident coordination, incident response support, and formal incident command or reporting authority. Vendors should explain how they would support CBP/DHS incident response procedures without assuming Government incident authority unless such authority is formally delegated.

Responses should address:

· continuous monitoring of security events;

· SIEM integration or log forwarding;

· intrusion detection and prevention;

· endpoint detection and response;

· malware detection;

· unauthorized access detection;

· security alert triage and escalation;

· security incident response plan development;

· incident response coordination and support with CBP/DHS;

· joint incident response with CBP;

· forensic support;

· root cause analyses support, including suspected cause identification, corrective action documentation, and coordination with responsible resolver groups; and

· reporting timelines for incidents affecting CBP systems, data, or operations.

Vendors should describe forensic support capabilities separately from routine SOC monitoring and incident response activities. Responses should address chain-of-custody procedures, evidence handling, use of government-approved tools, personnel qualifications, data preservation methods, reporting approach, and assumptions regarding Government authorization, direction, and legal or evidentiary requirements.

Vulnerability Management and Patch Management Vendors should distinguish between routine vulnerability scanning and penetration testing. Penetration testing, if proposed, should be performed only when specifically authorized by the Government under approved rules of engagement.

Vendors should describe how they would support vulnerability management and patch management by responsibility layer. Responses should address scanning, reporting, remediation planning, remediation tracking, remediation coordination, patch planning, patch testing, patch deployment coordination, patch implementation, rollback, emergency patching, exception handling, patch status reporting, and implementation of approved remediation actions within the vendor’s authorized access and technical control.

Vendors should identify assumptions regarding system ownership, administrative access, change control, maintenance windows, test environments, system owner approval, vendor-managed components, OIT-managed components, ATO/security impact, and any other dependencies that may affect vulnerability management or patch management execution.

Vendors should describe their ability to perform or support vulnerability management and patch management, including:

· regular vulnerability scanning;

· vulnerability scan reporting;

· support for ISSOs;

· support to CBP vulnerability assessment teams;

· POA&M input, evidence collection, remediation status tracking, and remediation coordination;

· remediation planning;

· remediation tracking and coordination with responsible parties;

· patch testing;

· patch deployment coordination;

· patch implementation, where authorized;

· rollback planning and support;

· emergency patching approach;

· exception handling;

· patch status reporting;

· secure baseline configuration management;

· documentation of scanning, patching, remediation, and residual risk; and

· recommended timelines for remediation of critical, high, moderate, and low vulnerabilities.

Authentication and Access Control Vendors should describe how they will support authentication and access control for BPTOC systems and supported environments. Vendors should distinguish between access request intake, account administration, password reset and account unlock support, privileged access management, access approval, access removal, and recertification support. Vendors should identify how they would operate under government-approved Personal Identification Verification (PIV)/Common Access Card (CAC) workflows and maintain audit logs of access-related actions.

Responses should address:

· multi-factor authentication for administrative access;

· role-based access control;

· least privilege;

· privileged account management, including privileged access controls, approval workflows, session logging, auditability, and periodic review;

· separation of duties between access request intake, access approval, provisioning, privileged administration, and audit functions;

· user access request intake, tracking, routing, and coordination;

· user access provisioning and deprovisioning, where authorized;

· password reset and account unlock support, where authorized;

· emergency access procedures, including approval, duration, monitoring, logging, and removal of emergency access;

· access approval workflows and required Government approvals;

· periodic access reviews and recertification support;

· support for PIV/CAC-based access, where applicable;

· audit logging of access events and access-related administrative actions;

· procedures for account creation, modification, unlocking, password resets, suspension, termination, and removal;

· access removal procedures for users, administrators, subcontractors, or other personnel who no longer require access; and

· assumptions, dependencies, and constraints related to government-approved workflows, system owner approvals, CBP OIT processes, and supported system access boundaries.

Logging and Auditability Vendors should describe their ability to generate, collect, protect, retain, segregate, and export logs. Vendors should identify log source ownership, retention assumptions, access controls, audit support processes, and handling of logs containing sensitive operational, security, access, vulnerability, or incident information. Vendors should also describe how logs would be protected, segregated by portfolio/task order where applicable, and made available for audits, investigations, and incident response.

Responses should address:

· logging of authentication events;

· logging of configuration changes;

· logging of security events;

· logging of administrative actions;

· logging of incident response activity;

· logging of system performance events;

· audit logging of access events and access-related administrative actions;

· logging of access request, approval, provisioning, deprovisioning, account unlock, password reset, emergency access, and access removal activities, where applicable;

· logging of privileged access activity, administrative sessions, and access-related administrative actions, where applicable;

· auditability of access-related events, including support for access reviews, investigations, incident response, and compliance reviews;

· protection, retention, and export of access-related logs in accordance with applicable DHS/CBP policy and Government-designated processes.

Configuration and Change Management Vendors should describe how they would integrate with Government change control processes, including change request preparation, approval routing, implementation authority, testing, rollback, emergency changes, documentation, and ATO/security impact review. Vendors should identify which activities they would perform directly; which activities they would support or coordinate; and which activities require Government, CBP OIT, system owner, ISSO/ISSM, vendor, or other third-party approval or action.

Responses should address:

· secure baseline configuration management;

· configuration monitoring and documentation;

· change request preparation, submission, routing, tracking, and closure;

· government notification of changes affecting security, availability, or performance;

· required Government, CBP OIT, system owner, ISSO/ISSM, vendor, or third-party approvals prior to implementation, where applicable;

· testing of patches and configuration changes in a separate environment, where applicable;

· implementation of approved hardware and software updates, where authorized;

· rollback planning and support;

· emergency change process and documentation;

· ATO/security impact review support;

· post-implementation validation and documentation of results;

· version control;

· documentation of approved changes;

· alignment with DHS/CBP standards, DISA STIGs, CIS Benchmarks, or other applicable baselines; and

· assumptions, dependencies, and constraints related to access, ownership, test environments, maintenance windows, implementation authority, and Government change control processes.

Supply Chain and Personnel Security For purposes of this RFI, supply chain and personnel security refers to the vendor’s approach for ensuring that hardware, software, services, subcontractors, teaming partners, and personnel used to perform BPTOC services are authorized, compliant, vetted, monitored, and managed to reduce security, operational, access, and supply chain risk.

Responses should address:

· use of authorized and compliant hardware, software, and service providers;

· screening against prohibited or restricted sources;

· supply chain risk management documentation and processes;

· subcontractor management strategies;

· flow-down of security requirements to subcontractors;

· identification of subcontractors with access to CBP data or systems;

· identification of any subcontractors or teaming partners that would have privileged access, access to CBP systems, or access to CBP operational or security data, including how such access would be approved, monitored, audited, and removed when no longer required;

· identification of whether privileged operations or access will be performed by non-U.S. persons or outside the United States;

· ability to restrict privileged access to U.S. persons within the United States, if required;

· personnel background checks;

· personnel vetting assumptions, including ability to obtain required CBP background investigations or other CBP-approved access determinations;

· Security awareness training; and

· Access removal procedures for personnel who no longer require access.

Data Protection Vendors should describe how CBP data will be protected, including how BPTOC operational data, tickets, logs, reports, dashboards, backups, configuration data, and other CBP-related operational data will be stored, accessed, transmitted, retained, segregated, and destroyed. Vendors should identify whether any CBP data would reside in contractor-managed environments and describe how data would be segregated by portfolio, task order, system, user role, or other government-approved boundary.

Vendors should address:

· encryption of data in transit;

· encryption of data at rest;

· use of FIPS-validated cryptographic modules, where applicable;

· secure backup storage;

· data location, including whether data would reside in government-managed or contractor-managed environments;

· data segregation by portfolio, task order, system, user role, or other government-approved boundary;

· data retention practices;

· secure data destruction and media sanitization;

· protection against unauthorized access, disclosure, modification, deletion, or exfiltration of CBP data; and

· any assumptions, dependencies, or constraints related to data storage, access, location, segregation, retention, or destruction.

Security Documentation and Deliverables Vendors should describe their ability to provide security documentation and deliverables, including sample or template documentation for:

· system security plan inputs;

· incident response plan;

· disaster recovery plan;

· vulnerability scan reports;

· POA&Ms;

· supply chain attestations;

· security architecture diagrams;

· control implementation summaries;

· third-party security assessments, such as SOC 2 or ISO 27001, if applicable;

· configuration management procedures;

· change management procedures; and

· shared responsibility matrix identifying how security and operational responsibilities would be divided among BPTOC, the Government, CBP OIT, system owners, ISSOs/ISSMs, vendors, and other third parties for hosting, system administration, cybersecurity monitoring, backups, access management, incident response, vulnerability management, patch management, reporting, and escalation.

CONTRACTING AND TASK ORDER CONSIDERATIONS

CBP is considering an enterprise contract structure that may support multiple PMOD portfolios through individual task orders. Vendors should provide feedback on contract structure, including:

· suitability of an Indefinite Delivery, Indefinite Quantity (IDIQ) contract;

· use of portfolio-specific task orders;

· recommended contract types for base BPTOC services;

· recommended contract types for surge support;

· recommended contract types for research, development, testing, and evaluation or feasibility studies;

· fixed-price versus labor-hour or time-and-material considerations;

· service-level based pricing;

· endpoint-based pricing;

· portfolio-based pricing;

· cost drivers;

· scalability considerations;

· transition costs;

· facility costs;

· tool licensing costs;

· staffing assumptions; and

· travel assumptions.

POTENTIAL DELIVERABLES

CBP is interested in industry feedback on appropriate BPTOC deliverables. Vendors should address their ability to provide the notional deliverables listed in the table below.

RESPONSE

Your firm is requested to submit a response that addresses the following topics in sequence.

Attachment A: Vendor Company Data Vendors should provide basic company information, including:

· company name;

· address;

· points of contact name, title, phone number, and email;

· Unique Entity Identifier (UEI) and Commercial and Government Entity (CAGE) code;

· business size and socioeconomic status;

· contract vehicles available for use;

· relevant North American Industry Classification System (NAICS) codes;

· security clearances or facility clearance information, if applicable; and

· existing federal, DHS, or CBP contract experience, if applicable.

Attachment B: White Paper The white paper shall address the topics listed below.

1. Technical Approach Describe your proposed BPTOC solution, including NOC, SOC, call center/helpdesk, monitoring tools, ticketing integration, dashboards, incident management, operational availability tracking, and support for multiple PMOD portfolios.

2. Service Model Describe your managed service offering, including staffing, facilities, hours of operation, redundancy, service availability, operational continuity, service-level management, and supportability.

3. Experience Describe relevant past performance or experience providing similar NOC, SOC, call center/helpdesk, operational availability, cybersecurity, or sustainment coordination services, especially for Government, law enforcement, border security, defense, critical infrastructure, or geographically dispersed operational systems.

4. Integration Capability Describe your ability to integrate with CBP systems, government-furnished tools, ticketing systems, asset management systems, vulnerability management tools, SIEM platforms, and established operational workflows.

5. Incident Management and Operational Availability Describe how your solution supports incident prioritization, Tier 1/Tier 2 troubleshooting, escalation, root cause analyses, service request management, operational availability calculations, and monthly reporting.

6. Cybersecurity Describe how your solution addresses cybersecurity requirements, including security monitoring, FISMA/RMF support, vulnerability scanning, patch management, incident response, access control, logging, auditing, configuration management, and supply chain risk management.

7. Transition Approach Describe your proposed transition approach, including onboarding from an incumbent provider, staffing ramp-up, knowledge transfer, tool deployment, system onboarding, SOP development, and continuity of operations.

8. Scalability Describe how your solution scales to support additional portfolios, systems, endpoints, users, sites, and task orders over time.

9. Staffing and Personnel Security Describe your staffing model, labor categories, qualifications, certifications, shift coverage, surge support, and ability to meet CBP personnel vetting and access requirements.

10. Deliverables and Reporting Describe your ability to provide reports, dashboards, contract data requirements lists (CDRL), operational availability metrics, vulnerability reports, POA&Ms, program management review briefings, integrated master schedules, incident reports, and other recurring deliverables.

11. Contracting Feedback Provide recommendations regarding contract structure, task order structure, pricing model, service levels, performance metrics, contract type, and key cost drivers.

12.…