Responses to Questions 191NLE26R0085_ABIS_QA.xlsx
XLSX spreadsheet 23 KB Posted
- Solicitation number
- 191NLE26R0085
About this file
This file is a Questions and Answers (Q&A) document for Solicitation No. 191NLE26R0085, an Automated Biometric Identification System (ABIS) procurement for the Guatemalan Migration Institute (IGM) by the U.S. Department of State's Office of Acquisition Management through INL (International Narcotics and Law Enforcement). The Q&A addresses 49 clarification questions submitted by offerors regarding technical specifications, hardware delivery, disaster recovery architecture, facilities requirements, licensing, training scope, and acceptance criteria.
Key technical clarifications include: confirmation that functionally equivalent virtualization/backup solutions (beyond the listed Proxmox VE/PBS) may be acceptable; that REST/gRPC APIs consumable from C# satisfy programmatic administration requirements; and that algorithm-open architecture with multi-vendor biometric integration capability and documented APIs/SDKs is required to avoid vendor lock-in. The Government addresses facility and infrastructure prerequisites, including electrical service specifications, cooling capacity, rack dimensions, and network connectivity requirements that offerors must assume or verify during post-award site visits. Critical delivery and logistics clarifications confirm that the 30-day hardware delivery requirement to the Miami freight forwarder will commence after site verification completion, and that delays caused by Government/IGM dependencies will result in schedule relief. The Q&A clarifies that the 50-page technical proposal limit in Attachment 1 supersedes the 15-page limit in Section 2.6 of the SOW; that full-stack training across all solution components (servers, storage, HSM, virtualization, networking, UPS, backup software) must be included within the 50-hour CLIN 4A training allocation; that all software licenses must remain active for the full three-year warranty period with renewal costs included in the firm-fixed-price; and that FAT and SAT objective acceptance criteria, test data, and Government test resources will be defined post-award. The solicitation closed on August 31, 2026, with proposals due by 5:00 PM EST; all quotes must remain valid for a minimum of 90 days.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Updated Responsese 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 | ||||
| No. | Area | SOW / Solicitation Reference | Question / Clarification | Government Response |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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). | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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). | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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? | |
| 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). | |
| 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. | |
| 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. | |
| 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. | |
| 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). | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| 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. | |
| Q46 | Existing Environment, Prerequisites & Responsibilities | SOW 3.1– 3.3; 3.7 | Site readiness and Government-furnished prerequisites. Please confirm whether the Government will establish and approve a Site Readiness / Prerequisite Checklist following award identifying the facilities, power, network connectivity, IP addressing, DNS/NTP, firewall rules, credentials, certificates, software dependencies, licenses, access permissions, and IGM technical resources required before installation and integration activities begin. Please also confirm whether commencement of the applicable implementation milestones will be contingent upon completion of the Government/IGM responsibilities identified in the approved checklist. | |
| Q47 | Proposal Instructions & Evaluation | SOW 5.3 | Technical evaluation ratings and minimum acceptability. Section 5.3 assigns weighted evaluation factors of 25% for Factor 1, 30% for Factor 2, 15% for Factor 3, and 30% for Factor 4. The SOW further states that an overall rating of no less than “Acceptable” must be achieved for Factor 1, while also stating that an “Unacceptable” technical subfactor will result in an overall “Unacceptable” non-price rating. Please clarify whether each Technical Factor (Factors 1 through 3) must independently receive a minimum rating of “Acceptable” to remain eligible for award, and clarify how the Factor 4 Past Performance rating will be incorporated into the overall weighted non-price evaluation. | |
| Q48 | Proposal Instructions, CLINs & Pricing | SOW CLIN 1A/1B/2A/2B; Price Evaluation | Base requirements, Option CLINs, and evaluated pricing. Please identify which SOW requirements and components constitute the Base Requirement and which, if any, constitute evaluated Option CLINs. Specifically, please clarify the contractual status of CLIN 1B Software Components and CLIN 2B Disaster Recovery Infrastructure, including whether these components must be included in the proposed technical architecture and price at initial award or priced separately as options. Please also identify all evaluated option requirements that will be included in the Government’s total evaluated price. | |
| Q49 | Acceptance, Testing & Government Resources | SOW CLIN 5; 3.3– 3.5 | Test data, test accounts, and Government test resources. Please clarify which party will provide the biometric test datasets, test identities, sample records, application test accounts, API credentials, certificates, and access to IGM systems required for FAT, SAT, integration testing, performance testing, and training. Please confirm whether IGM will provide representative production-equivalent test data and the technical personnel required to execute and validate end-to-end tests involving IGM-owned applications. |
_x000D_&1#&"Calibri"&14&K000000 SBU - CONTRACTING AND ACQUISITIONS
File details come from the government source that posted it. Updated .