Updated Responsese 191NLE26R0085_ABIS_QA_.xlsx
XLSX spreadsheet 34 KB Posted
- Solicitation number
- 191NLE26R0085
About this file
This is a Questions and Answers (Q&A) document for the INL Guatemala Automated Biometric Identification System (ABIS) solicitation 191NLE26R0085, addressing 49 clarifications from offerors regarding the Statement of Work and implementation requirements.
The solicitation requires offerors to deliver a comprehensive ABIS solution for the Guatemalan Migration Institute (IGM) with mandatory CLINs covering: CLIN 1A (ABIS Platform Software), CLIN 1B (Software Components including disaster recovery), CLIN 2A (Infrastructure and Hardware), CLIN 2B (Disaster Recovery Infrastructure with Hardware Security Module), CLIN 3 (Installation and Integration Services), CLIN 4 (Training and Knowledge Transfer), and CLIN 5 (Acceptance Testing). The solution must support 160 million fingerprints, 16 million facial records, and 32 million iris records; process up to 3,000 passport enrollments and 270,000 migration records daily; deliver sub-second response times for biometric operations; and include active-active high-availability architecture at the primary site with geographic replication to a secondary disaster recovery site. Key technical requirements include mandatory use of Proxmox VE 8.4.4 and Proxmox Backup Server 4.0.18 for virtualization and backup, APIs/SDKs compatible with IGM's C#/.NET environment, and integration with existing institutional applications without requiring their replacement. The hardware delivery period has been extended to 90 days from award. IGM will provide existing infrastructure (rack cabinets, network connectivity, facility power, and network topology details post-award), while the Contractor must supply all software licenses, biometric engines, compute/storage hardware, backup appliances, HSM for data protection in transit, and three years of on-site warranty with local maintenance support. Training shall comprise 50 hours covering ABIS administration, infrastructure administration, and integration/development for IGM personnel. The proposal limit is 50 pages for Volume I (Technical), all CLINs are mandatory with firm-fixed pricing, and proposals are due by 5:00 PM EST on August 31, 2026. Evaluation will follow a Best Price/Technical Tradeoff methodology with weighted factors: Factor 1 (Approach and Platform Fit) 25%, Factor 2 (Performance and Scalability) 30%, Factor 3 (Warranty and Support) 15%, and Factor 4 (Past Performance) 30%, with a minimum "Acceptable" rating required for technical eligibility.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Responses to Questions 191NLE26R0085_ABIS_QA.xlsx | XLSX spreadsheet | |
| 191NLE26R0085_A0002 Signed.pdf | ||
| SOW Updated 08_06_2026_IGM ABIS Platform.docx | DOCX document | |
| 191NLE26R0085 Signed.pdf | ||
| Attch 1 - Instruction to Offerors Supplemental.docx | DOCX document | |
| 191NLE26R0085_ A0001 Signed.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Q&A
| Automated Biometric Identification System (ABIS) – Guatemalan Migration Institute (IGM) | |||||
| Solicitation No. 191NLE26R0085 | INL – U.S. Embassy Guatemala | |||||
| https://sam.gov/workspace/contract/opp/173f182d996a4da8a5b1cc376365e2b9/view | SOW Updated 08_06_2026_IGM ABIS Platform.docx | ||||
| No. | Area | SOW / Solicitation Reference | Question / Clarification | Government Response | Columna1 |
| Q1 | Technical Specifications and Platform | SOW 1A.9; Factor 1 | Virtualization / backup stack (SOW 1A.9 vs. Factor 1). SOW 1A.9 permits enterprise Linux (RHEL, Rocky, or Ubuntu) and any of Docker/Podman/Kubernetes/LXC, yet Factor 1 specifically lists "certified Proxmox VE 8.4.4," "Debian LTS," and "Proxmox Backup Server (PBS 4.0.18)." Please confirm whether Proxmox VE/PBS is a mandatory requirement or one acceptable example, and whether functionally equivalent enterprise virtualization/backup stacks (e.g., RHEL KVM, VMware, Veeam) will be evaluated as compliant. | Based on the requirements established in SECTION 5.3 – Factor 1 of the SOW, Proxmox VE 8.4.4 and Proxmox Backup Server (PBS) 4.0.18 are mandatory requirements for the proposed solution. The Offeror shall therefore provide an architecture compatible with and supporting the specified Proxmox virtualization and backup environment, while also complying with the operating system and containerization requirements established in SECTION 3.2, CLIN 1A, subsection 1A.9 | |
| Q2 | Technical Specifications and Platform | SOW 1A.12 | Programmatic administration interface (SOW 1A.12). SOW 1A.12 requires programmatic administration via a locally developed C# application. Please confirm whether a native C# SDK is required, or whether documented REST/gRPC API endpoints consumable from a C# application satisfy the requirement. | Please refer to SECTION 3.2, CLIN 1A, subsections 1A.4, 1A.5 , 1A.12. and Factor 2 of the SOW. The solution shall provide the required APIs, SDK, client libraries, and documentation to enable integration with IGM-developed applications, including its C#/.NET environment. Development or replacement of such applications is not within the Contractor's scope. | |
| Q3 | Delivery, Logistics, and OEM Support | SOW 4.3/ 4.6 | Hardware delivery timeline vs. OEM lead times ( 4.6). 4.6 requires delivery of all hardware to the freight forwarder within 30 calendar days of award, with partial shipments prohibited. Under current global supply conditions, all major OEMs (Dell, HPE, Cisco, Lenovo) are quoting standard manufacturing-and-delivery lead times on the order of twelve (12) weeks after purchase-order confirmation for enterprise-class components. A firm 30-day, no-partial-shipment requirement is therefore not achievable for new, manufacturer-current equipment. Will the Government (a) extend the hardware delivery period to at least ninety (90) days / twelve (12) weeks from award, and/or (b) allow offerors to state OEM lead times without adverse impact in the technical evaluation? If the 30-day period is firm, please clarify how offerors are expected to reconcile it with prevailing OEM lead times. |
Government will extend the delivery period to 90 days.
| Q4 | Delivery, Logistics, and OEM Support | SOW 4.2 | OEM authorization and local support letters ( 4.2). 4.2 requires the offeror to be registered to do business in Guatemala or to have an established local partner to guarantee on-site hardware maintenance, repairs, and spare parts. Will the Government require, as part of the proposal, a manufacturer/OEM letter of representation (or authorized-partner authorization letter) for each proposed brand, confirming (a) the offeror’s authorization to sell and support the equipment, and (b) availability of local/in-country on-site support and spare parts throughout the 3-year warranty? If so, please confirm whether such letters are required at proposal submission or only from the awardee. | The Offeror shall demonstrate compliance with the certification and support capability requirements established in SECTION 2, subsection 2.6, and SECTION 4, subsection 4.2. The SOW does not prescribe a specific additional documentary format beyond the evidence necessary to demonstrate such compliance. | |
| Q5 | Disaster Recovery, High Availability, and Backup | SOW DR / CLIN 1B | Scope of the DR plan. Please clarify whether the Contractor must produce a complete institutional Disaster Recovery Plan (covering IGM’s broader IT environment, roles, and continuity of operations) or only a DR plan/runbook scoped to the ABIS Platform delivered under this contract (failover, replication, and restore procedures for the ABIS application and its data). | CLINs 1B and 2B cover the Disaster Recovery components of the ABIS solution. Any associated recovery documentation or procedures shall be limited to the ABIS Platform and the components supplied under this contract. Development of an institution-wide Disaster Recovery Plan for IGM's entire IT environment is not required. | |
| Q6 | Disaster Recovery, High Availability, and Backup | CLIN 1B; 2A.1 | High-availability and replication architecture (CLIN 1B, 2A.1). CLIN 1B lists an "Active-Active Synchronization Architecture," a "Geographic Replication Module," and "Storage Replication SAN Nodes," while 2A.1 and CLIN 1B also describe standby/failover replication (implying active-passive). Please clarify: (a) whether the required HA architecture at the primary site is active-active or active-passive; (b) whether the secondary/DR site is warm-standby or active-active; and (c) at which layer replication must occur — native ABIS platform, database, and/or storage array (SAN) — and whether dedicated replication software/licenses must be included in the proposal. | Please refer to SECTION 3.2, CLIN 2A, subsection 2A.1 – High Availability, CLIN 1B and CLIN 2B. The solution shall eliminate single points of failure within the primary infrastructure and include the required geographic replication and inter-site recovery capabilities. The Offeror shall propose, document, and implement the technical architecture necessary to satisfy these requirements. Detailed institutional network, connectivity, and security information required for implementation will be provided to the awardee in accordance with SECTION 3.2, CLIN 3, subsection 3.7 – Information Security Restraint. Additionally, relevant technical information may be further reviewed, validated, or clarified during the pre-installation site verification established under SECTION 3.2, CLIN 3, subsection 3.1, prior to the final ordering of the products. | |
| Q7 | Disaster Recovery, High Availability, and Backup | CLIN 1B | Replication mode, inter-site link, and data scope. CLIN 1B references real-time replication and a Geographic Replication Module between the primary and Disaster Recovery sites. To size the replication design correctly, please clarify: (a) whether replication must be synchronous or asynchronous, which bears directly on the achievable RPO and on link and latency requirements; (b) the network link between the primary and DR sites — who provides it, its available bandwidth, and the maximum latency/distance offerors should assume — so replication traffic can be sized without creating an operational bottleneck; (c) the data scope that must be replicated (biometric templates, raw images, database, audit/transaction logs, and configuration — full or selective); and (d) the expected failover and failback procedure, including whether re-synchronization back to the primary site after a DR event is the Contractor’s responsibility. | CLINs 1B and 2B require the Offeror to propose and implement the geographic replication architecture. The Offeror shall describe the replication mechanism and mode, data scope, connectivity requirements, and failover/failback procedures required by its solution. Detailed institutional network and connectivity information required for implementation will be provided to the awardee in accordance with SECTION 3.2, CLIN 3, subsection 3.7 – Information Security Restraint. Additional technical details necessary to validate compatibility with the existing infrastructure may also be reviewed and clarified during the pre-installation site verification established under SECTION 3.2, CLIN 3, subsection 3.1, prior to the final ordering of the products. | |
| Q8 | Disaster Recovery, High Availability, and Backup | SOW HA/DR | RPO / RTO targets. To size HA, replication, and DR correctly, please state the target Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for both intra-site HA failover and site-to-site DR failover. | The SOW does not establish specific numerical RPO/RTO values. The Offeror shall describe the recovery objectives and recovery times supported by the proposed HA and DR architecture, demonstrating consistency with the availability, continuity, replication, and failover requirements established in the SOW. | |
| Q9 | Disaster Recovery, High Availability, and Backup | 2A.1; Factor 1 | Backup — software, hardware, and retention. 2A.1 (Backup and Restore) requires full, scheduled backups and complete restoration; Factor 1 references Proxmox Backup Server. Please confirm: (a) whether backup software licensing must be included; (b) whether the offeror must also provide dedicated backup hardware (a backup server/target and/or repository storage) sized for the ABIS repositories, or whether IGM provides existing backup infrastructure; (c) the required retention period; and (d) whether backups must also be replicated to the DR site. | Please refer to SECTION 3.2, CLIN 2A, subsection 2A.1 – Backup and Restore, CLIN 1B and CLIN 2B. The solution shall include all mechanisms and components necessary for full and scheduled backups and complete restoration of the ABIS Platform, repositories, and configurations. The Offeror shall also provide the backup/replication mechanisms necessary for the supplied DR architecture. | |
| Q10 | Facilities, Electrical, and Environmental (Site Sizing) | 2A.1 | Electrical service, power budget, and standby power. Please provide, for the ABIS installation location: (a) available electrical service — number and rating of panels/boards, spare breaker capacity, nominal voltage (120V / 208V / 220–240V), and single- vs. three-phase availability; (b) the power budget available per rack (kW/cabinet) and total for the deployment, so node counts stay within facility limits; (c) rack PDU provisioning (IGM-provided or Contractor-supplied) and the receptacle/plug types at the site, which also drive the UPS input configuration in 2A.1 (e.g., NEMA L5-30P vs. locking 208/240V); (d) whether facility-level standby power (generator) exists upstream of the UPS, and any minimum required UPS runtime at full load; and (e) grounding/earthing provisions in the room. | Site-specific conditions shall be verified in accordance with SECTION 3.2, CLIN 3, subsection 3.1 – Pre-Installation Site Verification. Prior to ordering equipment, the awardee shall validate electrical conditions, space, power, grounding, and any other conditions necessary to ensure compatibility of the proposed infrastructure. | |
| Q11 | Facilities, Electrical, and Environmental (Site Sizing) | 2A.1 / Site | Cooling and environmental. Please provide (a) the available cooling capacity at the installation room (kW, BTU/hr, or tons), the cooling type (CRAC/CRAH, in-row, or comfort cooling), and whether a hot-aisle/cold-aisle arrangement exists; and (b) the operating temperature and humidity ranges maintained, so the heat load of the proposed hardware stays within room capacity. | Environmental and cooling conditions are part of the site conditions to be verified in accordance with SECTION 3.2, CLIN 3, subsection 3.1. The Contractor shall ensure that the proposed equipment is compatible with such conditions. | |
| Q12 | Facilities, Electrical, and Environmental (Site Sizing) | 2A.1; 4.7 | Space, rack, and delivery access. IGM states it provides the rack cabinets ( 2A.1). Please confirm (a) the number of rack units (U) available for this deployment, the cabinet usable depth (mm) and static load rating, and the four-post mounting standard; and (b) any equipment-delivery constraints at 6ª Ave 3-11, zona 4 (door widths, elevator, loading dock) and raised-floor loading limits, so chassis/rail selection and delivery are compatible. | In accordance with SECTION 3.2, CLIN 2A, subsection 2A.1, IGM provides standard 19-inch cabinets. Available rack space, dimensions, physical access, and other conditions necessary for installation shall be verified in accordance with CLIN 3, subsection 3.1 prior to ordering equipment. | |
| Q13 | Facilities, Electrical, and Environmental (Site Sizing) | 2A.1 | Network physical layer. Please confirm who provides the structured cabling and switch ports between the ABIS racks and the IGM network (patch panels, fiber/copper drops, uplink speeds), and whether the Contractor must supply top-of-rack switching for the ABIS cluster or connect to existing IGM switching. | Please refer to SECTION 3.2, CLIN 2A, subsection 2A.1 – Networking, and CLIN 3, subsection 3.7. The proposed infrastructure shall include the networking components necessary for the proposed ABIS architecture. Detailed institutional network information will be provided to the awardee in accordance with the SOW. | |
| Q14 | Algorithm Openness, Interoperability, and Application Independence | 1A.4– 1A.12 | Algorithm-open / multi-vendor architecture. Please confirm the Government’s intent regarding an algorithm-open ABIS: (a) whether IGM shall retain the ability, during the contract lifecycle and future expansions, to introduce, replace, upgrade, or add biometric recognition algorithms from different qualified manufacturers without replacing the core ABIS platform or the Government-developed frontend applications; and (b) whether the platform is therefore procured as an independent biometric services layer (rather than a closed, single-vendor ecosystem), with documented, manufacturer-supported interfaces/APIs/SDKs enabling such multi-vendor integration — subject to IGM’s validation, licensing, security, interoperability, and performance requirements. | Please refer to SECTION 3.2, CLIN 1A, subsections 1A.6, 1A.7, and 1A.8. The requirement addresses interoperability with existing systems, ownership and portability of biometric data, and protection against vendor lock-in. The SOW does not require biometric engines or algorithms from different manufacturers to be interchangeable within the platform. | |
| Q15 | Algorithm Openness, Interoperability, and Application Independence | 1A.4– 1A.12 | Application-layer and frontend independence. Please confirm that the Government-developed application layer may be developed and maintained independently (in C#/.NET or other commercially supported technologies), with no proprietary frontend, development environment, or middleware license required from the ABIS manufacturer for normal operation or future development; and that all core biometric operations — enrollment, verification (1:1), identification (1:N), duplicate search (N:N), record management, and administrative functions — are accessible programmatically through documented, supported APIs and/or SDKs, independent of any proprietary enrollment, border-control, migration, or identity-management frontend. | Yes. In accordance with SECTION 3.2, CLIN 1A, Boundary of Responsibility and subsections 1A.4, 1A.5, and 1A.12, IGM will retain its institutional applications, and the ABIS solution shall provide the necessary supported APIs/SDKs for integration. Replacement of existing applications with a proprietary manufacturer frontend is not required. | |
| Q16 | Algorithm Openness, Interoperability, and Application Independence | 1A.5; 4.2 | OEM developer support and lifecycle integration assistance. Please confirm that the ABIS provider shall furnish comprehensive technical support to IGM’s software development and integration teams throughout the entire three-year warranty/maintenance period — including API/SDK implementation assistance, architecture guidance, troubleshooting and debugging, integration testing, performance optimization, version compatibility, API/SDK upgrades, patches, documentation, sample code, and assistance integrating future biometric algorithms — while preserving compatibility with Government-developed applications. | Please refer to SECTION 3.2, Clin A1, subsection 1.A5 and SECTION 4, subsection 4.2. Support during the contract period shall cover the ABIS Platform, its APIs/SDKs, supplied components, updates, and interoperability established in the SOW. It shall not be interpreted as continuous development of institutional applications or implementation of new functionality or integrations outside the contracted scope. | |
| Q17 | Algorithm Openness, Interoperability, and Application Independence | 1A.6; 3.3 | Compatibility and migration from existing IGM applications. The SOW requires native integration with IGM’s existing enrollment, border-control, and electronic-passport systems and capture devices without replacing them. Please confirm that, if an Offeror proposes an ABIS and biometric algorithms different from the currently deployed MegaMatcher technology, the successful Offeror shall provide — within its proposed solution, implementation services, and pricing — all APIs, SDKs, integration tools, documentation, and OEM engineering support required to make IGM’s existing frontend applications fully compatible and operational, plus technical assistance to IGM’s teams throughout integration and migration (compatibility assessment, integration, application adaptation, testing, troubleshooting, performance validation, deployment, and post-integration support), without requiring IGM to replace or redevelop its existing frontend applications. | Please refer to SECTION 3.2, CLIN 1A, subsection 1A.6, description and Boundary of Responsibility, and CLIN 3, subsection 3.3 – Integration Services. The solution shall integrate with existing systems without requiring their replacement. The Contractor shall provide APIs, SDKs, documentation, and integration services; IGM will retain responsibility for development and modification of its applications. | |
| Q18 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | Functional scope, use cases, and site placement. Please specify (a) the cryptographic functions the HSM must perform — key generation and storage; encryption of the biometric and image repositories at rest and/or protection of data in transit; protection of TLS / mutual-authentication keys between ABIS and DR nodes; digital signing of records or audit logs; and/or key protection for a PKI — and (b) whether an HSM is required at the primary data center as well as the DR site, or at the DR site only (CLIN 2B lists it only under DR). | Please refer to SECTION 3.2, CLIN 2B – Centralized Security/Encryption Appliance. The physical HSM or hardware-based token management engine forms part of the required Disaster Recovery infrastructure and shall be intended for the protection of biometric data in transit, in accordance with the scope defined in the SOW. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. The Offeror shall provide for the proper integration of the required security/encryption component with the proposed ABIS and DR architecture, in accordance with the requirements of the SOW | |
| Q19 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | Certification, interfaces, and cryptographic algorithms. Please specify (a) the minimum certification required (e.g., FIPS 140-2 Level 3, FIPS 140-3, and/or Common Criteria EAL); (b) the cryptographic interfaces the HSM must expose (e.g., PKCS #11, KMIP, Microsoft CNG/CAPI, Java JCE, OpenSSL), noting that IGM’s application layer is C#/.NET (please confirm whether a specific provider such as a CNG Key Storage Provider is expected); (c) the required algorithms and curves (e.g., RSA, ECDSA/EdDSA with NIST or Brainpool curves, AES, SHA-2/SHA-3) and any host-country/national algorithm requirements; and (d) whether the HSM must support, or be firmware-upgradeable to, NIST-selected post-quantum algorithms (ML-KEM/Kyber, ML-DSA/Dilithium) and hash-based schemes (LMS/XMSS/XMSS-MT), or whether a FIPS-certified classical HSM is acceptable. | The SOW does not establish specific certifications, cryptographic interfaces, algorithms, or post-quantum cryptography requirements beyond those defined under SECTION 3.2, CLIN 2B. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI.The Offeror shall propose and document an HSM or hardware-based token management engine technically appropriate to perform the required function. | |
| Q20 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | Partitioning, authentication, and administrative control. Please specify (a) whether IGM requires logical separation of key material into multiple isolated partitions (cHSM) / PKCS #11 slots — e.g., separate partitions for the biometric platform, PKI/ePassport, TLS, and audit-log signing — and if so, the number required (which affects model and licensing); and (b) the required administrative controls: operator/administrator authentication methods (password, key file, and/or smart card), whether multi-person (m-of-n / k-of-n, e.g., 3 of 5) authorization is required for sensitive operations, and whether role-based access control (RBAC) with separation of duties must be enforced. | The SOW does not establish a specific number of partitions, slots, m-of-n/k-of-n schemes, or additional administrative controls. The Offeror shall propose and document a configuration appropriate to the functional scope established under CLIN 2B. | |
| Q21 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | Form factor, quantity, high availability, and physical characteristics. Please specify (a) the required form factor (PCIe cryptographic card vs. network-attached rack-mount appliance) and quantity across the primary and DR sites; (b) the HA/redundancy model, including whether secure key backup and key replication/synchronization between the primary and DR HSMs is required; and (c) for an appliance form factor, the required network-interface redundancy (dual 1 GbE vs. 10 GbE SFP+), whether an independent trusted time source (GPS / DCF-77 or authenticated NTP) is required for signing timestamps (consistent with 2A.1), and whether redundant hot-swappable power supplies are required. | CLIN 2B does not establish a specific form factor, quantity, or redundancy configuration. The Offeror shall propose, provide, and implement the architecture and configuration technically appropriate to satisfy the established scope and its integration with the DR solution. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. | |
| Q22 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | Performance and sizing basis. So the HSM can be correctly sized, please state the required cryptographic throughput (operations per second) or peak concurrent key operations expected, taking into account the SOW’s daily processing volumes (3,000 passport enrollments and 270,000 migration records every 24 hours) and any per-transaction signing or encryption the HSM must perform. | The SOW does not establish a specific number of cryptographic operations per second for CLIN 2B. The volumes defined under CLIN 2A, subsection 2A.1 – Daily Processing Throughput relate to ABIS sizing. The Offeror shall size the security/encryption component according to the function established under CLIN 2B and the proposed DR architecture. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. | |
| Q23 | Hardware Security Module (HSM) and PKI Integration | 1A.7– 1A.8; CLIN 2B | Key storage, backup, and portability. Please confirm IGM’s requirements for (a) key storage — internal to the HSM and/or external as encrypted key blobs in the filesystem or an enterprise database; (b) secure backup, cloning, or escrow of key material for disaster recovery; and (c) wrapped-key export in standard formats, so that cryptographic keys — like the biometric data they protect — remain portable and under IGM control, consistent with the data-sovereignty and vendor-lock-in provisions of SOW 1A.7–1A.8. | Subsections 1A.7 and 1A.8 establish ownership, access, export, and portability requirements for biometric data. The SOW does not establish additional specific key-storage, escrow, or cryptographic key-export requirements for CLIN 2B. The Offeror shall document the key management and protection mechanism of the supplied solution. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. | |
| Q24 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B / ePassport | PKI software brand and model (sizing dependency). The SOW references Electronic Passport and Identity Verification workflows, which typically rely on a PKI. Please identify the brand and model/version of the PKI software in use (or to be used) by IGM with which the HSM and ABIS must integrate. This is material to sizing and compatibility: the HSM’s throughput, partition/slot count, key-slot capacity, and integration interface depend directly on the PKI product’s key volumes, certificate issuance/signing rates, and integration requirements. Without it, offerors cannot confirm interoperability or accurately size and price the HSM. | The component established under SECTION 3.2, CLIN 2B does not require integration with IGM's electronic passport PKI infrastructure. Its scope is limited to the function established for the ABIS/DR solution. Therefore, the electronic passport PKI brand or version is not an integration requirement for this component. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. | |
| Q25 | Hardware Security Module (HSM) and PKI Integration | CLIN 2B | HSM simulator and SDK for integration development. To allow IGM’s C#/.NET developers to build and validate integration in parallel with delivery, please confirm whether the Offeror must provide an HSM simulator and the corresponding SDK / cryptographic provider (e.g., PKCS #11, CNG) at no additional cost, and whether simulator/SDK access is expected in advance of physical HSM installation to avoid integration delays. | The SOW does not require provision of an HSM simulator or advance cryptographic SDK. The Offeror shall provide the components, software, documentation, and interfaces necessary for proper implementation, integration, and operation of the component established under CLIN 2B. PKI infrastructure is not within the scope of this SOW, and the HSM requirement shall not be interpreted as being limited to, or specifically associated with, an electronic passport interface or electronic passport PKI. | |
| Q26 | Network Security and Firewalls | 2A.1 | Firewall provision and scope. The SOW requires "secure communication channels" ( 2A.1) but does not specify firewalls or network-security appliances. Please clarify whether the Contractor must provide firewalls / next-generation network-security appliances as part of the delivered infrastructure and, if so, the required scope: (a) perimeter firewalling; (b) internal segmentation between ABIS tiers (application, matching, database); (c) a DMZ or protected zone for the API gateway exposed to IGM’s frontend applications; and (d) firewalling/encryption of the link between the primary and DR sites — or whether IGM provides some or all of these. | Please refer to SECTION 3.2, CLIN 2A, subsection 2A.1 – Networking, and CLIN 3, subsection 3.7. The SOW requires redundant connectivity and secure communication channels between ABIS components but does not specifically require the provision of firewalls or perimeter security appliances. The SOW does not require the Offeror to provide a firewall, firewall appliance, or additional perimeter security platform as part of the ABIS solution. The solution shall provide only the components, software, documentation, interfaces, and configuration necessary to comply with the requirements established in the applicable CLINs. Any integration with IGM's existing network and security infrastructure shall be performed using the institutional infrastructure and information provided by IGM in accordance with SECTION 3.2, CLIN 3, subsection 3.7 – Information Security Restraint. | |
| Q27 | Network Security and Firewalls | 2A.1; 3.7 | Firewall redundancy, sizing, and integration. If firewalls are within the Contractor’s scope, please specify (a) the required redundancy/HA model (e.g., active-active or active-passive pair) to avoid a single point of failure; (b) the throughput and concurrent-session sizing basis, given the sub-second, high-throughput border-control API traffic; and (c) whether the firewalls must match or integrate with IGM’s existing firewall platform (brand/model) so that segmentation and policy remain consistent. We note that 3.7 withholds internal network topology until after award; please confirm that reasonable, documented assumptions stated in the proposal will not be scored as weaknesses. | The SOW does not require the Offeror to provide a firewall, firewall appliance, or additional perimeter security platform as part of the ABIS solution. The solution shall provide only the components, software, documentation, interfaces, and configuration necessary to comply with the requirements established in the applicable CLINs. Any integration with IGM's existing network and security infrastructure shall be performed using the institutional infrastructure and information provided by IGM in accordance with SECTION 3.2, CLIN 3, subsection 3.7 – Information Security Restraint. | |
| Q28 | Network Security and Firewalls | 3.2 | Firewall policy management and ownership. Please clarify who defines and manages firewall/segmentation policy during installation and thereafter — i.e., whether the Contractor configures initial rule sets and segmentation as part of installation and hardening ( 3.2), with documented handover to IGM for ongoing management, or whether IGM’s network team owns policy throughout. | In accordance with SECTION 3.2, CLIN 3, subsections 3.2 – Installation Services and 3.3 – Integration Services, the Contractor shall be responsible for initial configuration and hardening, including the rules necessary for integration. Upon completion of configuration activities and successful completion of applicable testing and acceptance, IGM technical personnel shall assume ongoing administration of such rules within its own infrastructure.Any necessary coordination during implementation and testing shall be conducted between the Contractor and IGM's technical personnel. | |
| Q29 | Training and Knowledge Transfer Scope (Full Solution Coverage) | CLIN 4A | Component coverage of the training. Please confirm whether the required training must cover every component of the complete solution — ABIS software, compute servers, storage/SAN, HSM, backup software, virtualization/containerization platform, UPS units, and networking/firewall equipment — or only the ABIS platform and its direct administration. If full-stack coverage is expected, please identify each product for which the Government requires formal operational/administration training. | Please refer to SECTION 3.2, CLIN 4, subsections 4A.1 and 4A.3. The 50 hours shall cover the profiles and content applicable to ABIS Platform administration, infrastructure administration, and integration/development, using the software, APIs, SDKs, and infrastructure supplied under the contract, including the DR components applicable to each profile. | |
| Q30 | Training and Knowledge Transfer Scope (Full Solution Coverage) | CLIN 4A | Relationship of the 50 hours to per-product manufacturer courses. Manufacturers typically deliver standard operational or administration training on a per-product basis, often on the order of 40 hours per product. Please clarify whether the 50 hours in CLIN 4 is (a) a total ceiling intended to encompass all products of the complete solution; (b) a baseline for the ABIS platform only, to which standard OEM per-product courses for the remaining components (servers, storage/SAN, HSM, backup software, virtualization, UPS, networking) would be added; or (c) intended to be supplemented by each manufacturer’s standard product training. If per-product OEM courses are expected, should offerors propose and price them individually, by product and course length? | The 50 hours established under SECTION 3.2, CLIN 4, subsection 4A.1 constitute the contractual instructor-led training requirement. No additional mandatory manufacturer-specific courses are established unless included by the Offeror without affecting compliance with the stated requirement. | |
| Q31 | Training and Knowledge Transfer Scope (Full Solution Coverage) | CLIN 4A | Depth, audience, and certification per product. For each in-scope product, please confirm (a) the expected depth (operation vs. administration vs. integration/development); (b) which of the three audiences (ABIS administrators, infrastructure administrators, software developers) each product’s training targets; (c) whether official manufacturer course-completion or certification is required; and (d) whether training must also extend to developers/engineers from the external companies that maintain IGM’s integrating systems, or is limited to IGM employees — so offerors can map the correct OEM courses, durations, and Spanish-language instructors, including the mandatory on-site phase (CLIN 4A.3). | Please refer to SECTION 3.2, CLIN 4, subsections 4A.1 and 4A.3. Training shall provide IGM-designated personnel with the knowledge necessary to administer, operate, maintain, integrate, and support the complete supplied solution, according to the established profiles and hours. The SOW does not require OEM professional certifications for participants. | |
| Q32 | Existing Environment, Data & Sizing | SOW 1A.3, 1A.7–1A.8 | Existing biometric data / migration responsibility. The SOW requires bulk import/export capabilities and compatibility with IGM’s existing operational environment. Please clarify whether the Contractor is required to migrate any existing biometric records, templates, images, demographic data, audit records, or other information from IGM’s current systems into the new ABIS Platform. If migration is required, please provide the approximate record volume, biometric modalities, existing data formats, source database/platform, data quality condition, and identify which party is responsible for extraction, transformation, cleansing, deduplication, validation, and final migration acceptance. | Please refer to SECTION 3.2, CLIN 1A, subsections 1A.3, 1A.7, and 1A.8. The Platform shall provide supported bulk import and export capabilities for biometric records, templates, and metadata. The SOW does not establish the initial migration of IGM's existing records as part of the Contractor's scope. | |
| Q33 | Existing Environment, Data & Sizing | SOW 1A.3, 2A.1 | Definition of biometric capacity. The SOW requires capacity for 160,000,000 fingerprints, 16,000,000 facial records, and 32,000,000 iris records. Please clarify whether these quantities represent individual biometric samples/templates or unique persons/identities. For fingerprints, please confirm the assumed number of fingerprint images/templates per individual; for iris records, whether the requirement assumes one or both eyes per individual; and whether raw biometric images must be retained in addition to biometric templates. | The capacities under CLIN 1A, subsection 1A.3 refer to biometric records by modality and not to numbers of persons: 160M fingerprints, 16M facial records, and 32M iris records. In accordance with CLIN 2A, subsection 2A.1 – Storage Infrastructure, the infrastructure shall provide capacity for both the Biometric Repository and Image Repository. | |
| Q34 | Existing Environment, Data & Sizing | SOW 1A.3, 2A.1 | Current population and growth rate. Please provide the estimated biometric population at system Go-Live and the anticipated annual growth rate during the three-year contract period, including expected growth of biometric images, templates, transaction logs, audit records, and associated metadata. | The SOW does not establish a specific initial population or annual growth rate. In accordance with CLIN 1A, subsection 1A.3, and CLIN 2A, subsection 2A.1, the Offeror is responsible for sizing the solution using the established biometric capacities, transaction volumes, and scalability requirements. | |
| Q35 | Existing Environment, Data & Sizing | SOW 1A.3; Factor 2 | Concurrent transaction and performance test profile. The SOW requires sub-second response times and high-concurrency processing but does not define the number or mix of simultaneous transactions. Please specify the peak concurrent users/transactions expected for 1:1 verification, 1:N identification, N:N duplicate searches, enrollments, and API requests, and define the response-time measurement methodology and acceptance threshold (for example average, 95th percentile, or 99th percentile). | Please refer to SECTION 3.2, CLIN 1A, subsections 1A.3 and 1A.4, and CLIN 2A, subsection 2A.1. The solution shall be sized for the established volumes, high-concurrency requirements, and response-time objectives. The SOW does not establish an additional transaction-type distribution or percentile-based latency methodology. The Offeror shall document and justify the performance of its architecture. | |
| Q36 | Acceptance, Execution & Dependencies | SOW CLIN 5; 3.4– 3.5 | FAT/SAT objective acceptance criteria. Please provide or define the objective pass/fail acceptance criteria for FAT and SAT, including the required test cases, datasets, transaction volumes, concurrency levels, performance thresholds, biometric accuracy thresholds, HA/DR failover criteria, backup/restore criteria, and responsible party for approving each test. Please also confirm whether the Government will provide an approved Acceptance Test Plan prior to execution or whether the Contractor is expected to develop the plan for Government approval. | Please refer to SECTION 3.2, CLIN 5, including subsections 5.1 and 5.2. As part of the proposal, the Offeror is expected to define the proposed FAT and SAT approach, test procedures, and acceptance criteria, in accordance with the applicable requirements and items established throughout the CLINs. The Contractor shall be responsible for planning, executing, and documenting the acceptance activities necessary to demonstrate compliance with the SOW. FAT and SAT shall cover, at a minimum, the elements identified under CLIN 5 and shall provide traceability to the applicable technical requirements. The agreed FAT/SAT procedures and criteria will subsequently be used as the basis for verification and final acceptance of the delivered solution. Final Acceptance will be granted by the Government following successful completion of the applicable acceptance tests and correction of any identified deficiencies. | |
| Q37 | Acceptance, Execution & Dependencies | SOW 3; 4.6 | Government/IGM dependencies and schedule relief. Please confirm that delays resulting from Government/IGM dependencies—including availability of facilities, network configuration, IP addresses, firewall rules, credentials, existing application access, test data, IGM developer availability, integration support, customs clearance, site readiness, or Government review/approval—will result in corresponding schedule relief and will not be considered Contractor-caused delay. | The parties' responsibilities and performance timelines shall be as established in the SOW and resulting contractual instrument. Any circumstance that may affect the schedule shall be timely documented and coordinated with the Contracting Officer/COR and evaluated in accordance with the applicable contract terms. | |
| Q38 | Acceptance, Execution & Dependencies | SOW 1A Boundary of Responsibility; 3.3 | IGM integration team availability and responsibilities. Please identify the Government/IGM technical resources that will be available during integration, including application developers, database administrators, network/security personnel, and infrastructure administrators. Please confirm that IGM will be responsible for making any required changes to its internally developed applications, workflows, source code, databases, or institutional systems necessary to consume the Contractor-provided APIs/SDKs. | Please refer to SECTION 3.2, CLIN 1A – Boundary of Responsibility, and CLIN 3, subsection 3.3 – Integration Services. IGM will retain responsibility for its applications and code modifications necessary to consume the APIs/SDKs. The Contractor shall provide APIs, SDKs, documentation, and professional integration services. IGM technical resources will be coordinated during implementation. | |
| Q39 | Delivery, Site Verification & Facilities | SOW 3.1; 4.3; 4.6 | Site visit vs. equipment ordering / 30-day delivery. Section 3.1 requires the successful Contractor to conduct a site verification before ordering equipment, while Section 4.6 requires all hardware to be delivered to the Miami freight forwarder within 30 calendar days of award. Please clarify the required timing of the post-award site visit, the number of days IGM will make the facilities available following award, and confirm whether the 30-day hardware-delivery period will commence only after completion of the site verification and Government confirmation that the proposed architecture is compatible with site conditions. | The technical site visit shall be coordinated with IGM immediately following award and prior to the final equipment order, in accordance with SECTION 3.2, CLIN 3, subsection 3.1. The delivery requirement established under SECTION 4, subsections 4.3 and 4.6, is modified in accordance with the clarification provided in Question 3 of this Questions and Answers document. The site visit will be coordinated on a priority basis to allow timely verification of site conditions and compatibility of the proposed equipment prior to the final equipment order. | |
| Q40 | Delivery, Site Verification & Facilities | SOW CLIN 2B; 4.7 | Primary and DR site locations. Please confirm the physical location of both the Primary Data Center and the Secondary Disaster Recovery site, including whether both sites are located within the IGM facility identified in Section 4.7 or at separate geographic locations. If the DR site is geographically separate, please provide sufficient facility characteristics to permit infrastructure, logistics, power, rack, and connectivity planning. | CLIN 2B requires the provision of Disaster Recovery infrastructure at a secondary site. Both the primary and secondary data center sites are located at IGM facilities. The location identified in SECTION 4, subsection 4.7 corresponds solely to the delivery location for the equipment and shall not be interpreted as the physical location of either the primary or secondary data center. The specific locations and relevant technical conditions of both data center sites will be provided to the awardee during the Pre-Installation Site Verification established under SECTION 3.2, CLIN 3, subsection 3.1, and in accordance with the information security provisions established under SECTION 3.2, CLIN 3, subsection 3.7 – Information Security Restraint. | |
| Q41 | Existing Environment, Data & Sizing | SOW CLIN 4A; 4A.1 | Development/Test/QA environment. Please clarify whether the Contractor must provide separate Development, Test/QA, Training, and Production environments in addition to the Production and Disaster Recovery environments. If separate environments are required, please identify the required capacity and licensing expectations for each. | The SOW does not require separate Development, Test/QA, or Training environments in addition to the contracted solution. In accordance with SECTION 3.2, CLIN 4, subsection 4A.1, practical exercises shall be performed using a production-equivalent environment that reflects the operational configuration delivered to IGM. The requirement to use a production-equivalent environment for training and practical exercises shall not be interpreted as a requirement for the Offeror to provide multiple, separate, or permanent environments (e.g., Development, Test/QA, Training, and Production). The Offeror shall provide the environment and resources necessary to conduct the required training activities without creating an obligation to deliver a multi-environment architecture beyond the scope established in the SOW. | |
| Q42 | Licensing, Warranty & Support | SOW CLIN 1A/1B; 4.2 | Software licensing model and three-year entitlement. Please confirm whether all ABIS, database, operating system, virtualization, backup, replication, API gateway, HSM, monitoring, and other software licenses must be perpetual or may be subscription-based, and identify which licenses/support subscriptions must remain active for the full three-year warranty period. Please also confirm whether license renewal costs during the three-year period must be included in the Firm-Fixed-Price proposal. | The Offeror shall provide all licenses necessary for complete operation of the supplied solution, including licensing required for components under CLINs 1A, 1B, 2A, and 2B, and maintain them valid throughout the contract and warranty period established in the SOW. Any licensing model shall be clearly identified and include all costs necessary to maintain the contracted functionality throughout such period. | |
| Q43 | Licensing, Warranty & Support | SOW 4.2; Factor 3 | Warranty SLA. The SOW requires a three-year on-site warranty and immediate local support. Please define the required support Service Level Agreements (SLAs), including support hours (business hours or 24x7), severity classifications, initial response times, remote response times, required on-site response times, restoration targets, resolution targets, and spare-parts replacement timelines. | Please refer to SECTION 4, subsection 4.2 – Warranty. The Contractor shall provide a three-year on-site warranty and maintain local capability for maintenance, repairs, and spare-parts provisioning. The SOW does not establish additional numerical response, repair, or replacement times beyond the requirements expressly stated. | |
| Q44 | Proposal Instructions & Evaluation | SOW 2.6; Attachment 1 | 15-page vs. 50-page proposal conflict. The updated SOW Section 2.6 states a maximum proposal length of fifteen (15) pages, while Attachment 1 – Instructions to Offerors establishes a fifty (50) page limit for Volume I – Technical Proposal, with specified exclusions. Please confirm that Attachment 1 supersedes Section 2.6 of the SOW and that the applicable page limit for Volume I is fifty (50) pages. | Please consider the requirement established in Attachment 1 as the correct and applicable requirement. Accordingly, the proposal page limit shall be fifty (50) pages. The fifteen (15) page limit stated in SECTION 2, subsection 2.6 shall be superseded by this clarification for purposes of proposal submission. | |
| Q45 | Existing Environment, Prerequisites & Responsibilities | SOW 1A.9; 3.2– 3.3; 3.7 | Existing environment, required prerequisites, and responsibility allocation. Please clarify the infrastructure and software prerequisites that will be provided by IGM versus those that must be included by the Contractor as part of the proposed solution. Without requesting disclosure of sensitive network architecture, please identify whether IGM will provide, license, configure, and maintain any required operating systems, virtualization components, databases, middleware, network services, DNS/NTP services, certificates, directory/authentication services, network connectivity, firewall rules, storage services, or other third-party software/services upon which the ABIS implementation will depend. For any prerequisite that will remain under IGM responsibility, please confirm that it will be installed, licensed, configured, and available prior to the applicable installation/integration activity. Please also confirm whether the Contractor will be responsible for procuring or licensing any third-party software or infrastructure not expressly identified in the SOW or in the Government's responses to these clarification questions. | Please refer to SECTION 3.2, CLIN 1A – Boundary of Responsibility and subsection 1A.9; CLIN 1B; CLIN 2A, subsection 2A.1; CLIN 2B; and CLIN 3, subsections 3.2, 3.3, and 3.7. The Contractor shall provide all software, hardware, licensing, configuration, and integration components necessary for complete operation of the ABIS solution and its DR architecture. IGM will provide only infrastructure and resources expressly identified as existing or under its responsibility. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .