Defense software procurement: from RFI to signed contract

Defense software procurement is not a slow version of commercial software buying. It is a structurally different process with different instruments, different evaluation logic, different legal frameworks, and failure modes that do not appear in commercial markets. A vendor who has won contracts in the private sector and enters a defense acquisition process without preparation will routinely lose to smaller, less capable competitors who understand how the process works. A procurement officer who applies commercial procurement instincts to a defense software acquisition will often end up with a poorly specified contract that generates years of disputes.

This article traces the process from first market contact to contract award – covering each instrument in the sequence, the evaluation logic that drives source selection, the certifications that gate participation, and the contract structures that determine risk allocation. It also identifies the mistakes that eliminate technically strong vendors from competition before evaluation even begins.

The procurement instruments: RFI, RFP, and ITT

Defense software procurement uses three primary instruments in sequence, and confusing their purpose leads to misallocated effort at each stage.

RFI – request for information

The RFI is a market research tool. It carries no commitment to award and generates no binding obligations for either party. The procuring authority – BAAINBw in Germany, DGA in France, IU MON in Poland, or a joint NATO procurement agency – uses the RFI to understand what solutions exist, what vendors can credibly deliver them, and what a realistic cost and schedule range looks like before drafting formal requirements. RFI responses are typically short (5–15 pages), and the evaluation is informal. There is no scoring rubric, no competitive down-select, and no mechanism to exclude a vendor from a later RFP based on their RFI response alone.

The strategic value of the RFI for vendors is not scoring – it is shaping. A well-crafted RFI response that introduces a capability the authority had not considered, or that defines a technical approach that becomes the baseline for the RFP requirements, creates a structural advantage before competitive evaluation begins. Authorities write what they know. Vendors who help them understand what is possible influence the requirements document.

RFP – request for proposals

The RFP is the formal solicitation. It opens competitive source selection and contains the full requirements specification, evaluation criteria with weights, instructions for proposal preparation, contract terms and conditions, and the schedule for evaluation and award. RFP responses are formally evaluated against the stated criteria and form the legal basis for the contract award decision. The competitive record created during RFP evaluation is what a losing vendor uses if they file a protest.

RFPs for defense software programs are typically lengthy documents – 100 to 400 pages is not unusual for a major acquisition – and the requirements specification within them is binding. A vendor who submits a proposal that does not explicitly address every requirement receives no credit for that requirement, regardless of their actual capability. This is the most common structural error in defense software RFP responses: responses written as marketing documents that describe what the vendor does, rather than compliance documents that map the vendor's solution to each stated requirement.

ITT – invitation to tender

The ITT, used predominantly in European and UK procurement contexts and under EU defense procurement directives, is functionally equivalent to the RFP in most respects. The primary distinction is that ITTs typically apply more stringent price-competitiveness weighting and are used in procurement contexts where the technical specifications are fully defined in advance, leaving less scope for technical approach differentiation. An ITT is often the appropriate instrument for software components with established specifications (communications protocols, data formats, interoperability standards), where the primary competitive variable is price and delivery schedule.

The procurement timeline: 12 to 36 months

The realistic timeline from RFI release to contract award for a significant defense software program is 18 to 36 months. Smaller, well-defined acquisitions can move faster – 12 to 18 months is achievable when requirements are already specified and the procurement is structured as a competitive order against an existing framework contract. The typical timeline breakdown is:

RFI release and market research: 2–3 months. The authority collects responses, holds industry days, and develops a preliminary assessment of the market. Requirements development and RFP drafting: 3–6 months. The authority translates market research into a formal requirements specification and drafts the solicitation. This phase often includes a draft RFP comment period where vendors can identify ambiguities. RFP open period: 2–3 months. Vendors prepare proposals; the authority manages formal questions-and-answers. Proposal evaluation and down-select: 3–6 months. Evaluation panels score technical, management, and cost volumes against the stated criteria. BAFO round (if used): 1–2 months. A shortlisted set of vendors submits revised final proposals. Source selection decision and award: 1–3 months. The source selection authority issues the award decision and the required pre-award notification period. Protest period: 35–90 days depending on jurisdiction. Unsuccessful vendors have a defined window to file a protest before contract performance begins.

Programs that skip the RFI phase and draft requirements without market engagement tend to produce specifications that either favor a single vendor (generating protests) or describe a capability that no vendor can fully deliver (generating change orders after award). The time spent on pre-solicitation engagement almost always shortens the post-award dispute phase.

Source selection criteria: how proposals are evaluated

Defense software RFPs typically evaluate proposals across three volumes – technical, management, and cost – with defined weights that must sum to 100%. The exact weights vary by program and authority, but a common distribution for complex software acquisitions is 40–50% technical, 20–30% management, and 20–30% cost. Some authorities use a pass/fail technical gate before cost evaluation begins: proposals that do not meet a minimum technical threshold are excluded from cost comparison entirely.

Technical volume

The technical volume is evaluated against the functional and non-functional requirements stated in the RFP. Evaluators assess whether the proposed solution meets the requirements, whether the technical approach is realistic and achievable within the proposed schedule, and whether the vendor has demonstrated understanding of the technical risks. A proposal that claims full compliance without explaining how compliance is achieved scores lower than one that explicitly maps each requirement to a specific architectural or implementation decision. Evaluators are typically subject matter experts – software engineers, systems integrators, cybersecurity specialists – who can identify vague compliance claims.

Management volume

The management volume covers the project execution plan, team qualifications, key personnel, risk management approach, and subcontractor management. Past performance citations are a core element – the authority reviews documented delivery history on comparable programs as evidence of execution risk. Past performance is typically evaluated separately from the management volume under a confidence assessment (substantial confidence, satisfactory confidence, limited confidence, no confidence) that can eliminate technically strong vendors if their delivery history shows schedule or quality problems.

Cost volume

Cost is evaluated for realism and reasonableness, not just absolute value. An unrealistically low price – one that the authority's independent cost estimate indicates cannot support the proposed technical approach – is scored negatively as a risk indicator, not rewarded. Authorities perform cost realism analysis on T&M and cost-plus contracts; on FFP contracts they evaluate price reasonableness. A cost volume that does not include a detailed work breakdown structure with traceable labor hour estimates is difficult to defend under cost realism scrutiny.

Mandatory certifications and compliance requirements

Defense software programs require vendors to hold specific certifications before award. The baseline set that appears across most NATO member state solicitations includes ISO 27001 (information security management system), ISO 9001 (quality management system), and AQAP 2110 – the NATO quality assurance standard for design, development, and production, aligned with ISO 9001 and required for any software integrated into a weapons system, C2 platform, or mission-critical infrastructure. AQAP 2110 is not ISO 9001 with a defense label; it has specific requirements for configuration management, design review, and acceptance testing that are not present in the commercial standard.

National requirements layer on top of the NATO baseline. German BAAINBw programs for classified systems require compliance with national classified information handling procedures. French DGA programs may require ANSSI certification for systems handling sensitive government data. Polish IU MON programs require compliance with national classified information protection law. UK MOD programs reference JSP 440 (Defence Manual of Security) and the Cyber Essentials Plus scheme as baseline requirements for commercial software suppliers.

ITAR-free status as a competitive differentiator

International Traffic in Arms Regulations (ITAR) restrict the export of defense-related technologies of US origin. For EU defense programs, software that incorporates ITAR-controlled components creates compliance and operational constraints: the procuring authority must obtain US government authorization before sharing the software with allied nations, deploying it in joint operations with non-authorized partners, or modifying it in ways that alter the controlled technology. These constraints are operationally significant for multinational programs and create procurement risk for authorities who want flexibility in how they deploy the system.

EU-based software vendors whose products contain no US-origin ITAR-controlled components can market this as a genuine operational advantage, not a marketing claim. It simplifies the legal review, removes a re-export authorization dependency, and gives the procuring authority full control over deployment decisions. For programs operated by multiple EU member states or deployed in multinational environments, ITAR-free status is often a formal requirement, not a preference. See our analysis of ITAR-free defense software considerations for a fuller treatment of how this affects competitive positioning.

BAFO: the best and final offer stage

A BAFO (Best and Final Offer) round is used when initial proposal evaluation has narrowed competition to a shortlist of vendors whose scores are close enough that revised proposals could change the outcome. The contracting authority issues written instructions specifying what vendors may revise – typically price, staffing plan, and defined technical elements – and what is locked. Vendors submit revised proposals within a defined window, typically 2–4 weeks.

The strategic error most vendors make in a BAFO round is treating it purely as a price negotiation. If the evaluation shows a 3-point technical score gap and a 5% price difference, cutting price without closing the technical gap loses. Effective BAFO responses address both dimensions simultaneously: tightening the technical approach where the evaluation feedback (when available) indicated scoring gaps, and sharpening the price where margin exists. Authorities cannot legally provide specific score breakdowns before BAFO, but debriefs after initial evaluation – where available – provide enough signal to identify where the gap lies.

Contract structures for defense software: FFP vs. T&M

The two primary contract structures for defense software are Firm Fixed Price (FFP) and Time and Materials (T&M), with cost-plus variants used for research-intensive or highly uncertain work. The choice between them allocates schedule and cost risk differently and shapes the entire program management relationship after award.

FFP transfers cost and schedule risk to the vendor. The government pays a fixed amount regardless of how long the work takes or what it costs to deliver. FFP is appropriate when requirements are fully specified, stable, and detailed enough that the vendor can build a realistic bottom-up cost estimate. For defined software releases with accepted requirements baselines, FFP creates vendor incentive to deliver efficiently. The risk for the vendor is requirements creep after award – any change to the agreed requirements baseline triggers a change order process, and disputes about what was and was not in scope at award are a leading source of program delays.

T&M pays the vendor for hours worked at agreed labor category rates plus direct material costs, with the government bearing schedule and cost risk. T&M is appropriate when requirements are exploratory, when the scope involves integration with existing systems of unknown configuration, or when the work involves research and development where the outcome is uncertain. T&M does not reduce the government's obligation to manage the program – it increases it, because the authority must actively monitor labor hours and deliverables to ensure value.

Most defense software programs of significant scope use a hybrid structure: FFP for defined deliverables (software releases, documentation deliverables, training), T&M or cost-plus for exploratory work, systems engineering support, and maintenance activities where the volume of work cannot be reliably estimated in advance. For the post-award maintenance phase, see our detailed analysis of defense software maintenance contract structures and negotiation points.

Common vendor mistakes that eliminate competitive proposals

Several recurring errors appear in defense software RFP responses that are technically capable but procedurally flawed.

Failing to address every requirement explicitly. A proposal that does not map to every stated requirement in the RFP receives zero credit for the requirements it skips, regardless of implied compliance. Evaluators score what is written, not what can be inferred. A compliance matrix – a table mapping each requirement to a proposal section – is not optional; it is the evaluator's primary navigation tool.

Overstating past performance credentials. Defense contracting authorities verify past performance citations. A citation that inflates contract value, scope, or delivery performance creates a credibility problem that damages scoring across all evaluation volumes, not just past performance. Accurate, specific past performance citations from comparable programs outperform inflated ones from unrelated work.

Underbidding to win and planning to recover costs through change orders. This strategy is well understood by contracting authorities and priced into their evaluation models. A price that falls below the independent government cost estimate by more than 15–20% typically triggers a cost realism review. A proposal that wins on unrealistically low price and then generates change orders creates the conditions for the relationship breakdown that leads to program failure and debarment proceedings.

Missing certification requirements. A proposal from a vendor who does not hold the required certifications at proposal submission cannot be awarded. Evaluators do not accept commitments to obtain certifications post-award for requirements listed as mandatory. The time to begin AQAP 2110 certification is not after the RFP is released – it is 12 to 18 months before you intend to compete for the programs that require it.

What procurement officers should watch for on the authority side

Procurement authorities make structural errors that generate vendor protests and program delays with equal reliability. Requirements specifications that are written around a single incumbent vendor's solution – identifiable when performance requirements match the incumbent's current capability exactly, or when the specification uses the incumbent's proprietary terminology – generate protests that delay award by 6 to 12 months. Overly prescriptive technical requirements that mandate a specific architecture rather than a performance outcome limit competition to vendors who can demonstrate compliance with the specified approach rather than those who can deliver the required capability.

Evaluation criteria that are inconsistently applied across proposals – where evaluators score similar technical approaches differently without documented rationale – are the second leading cause of successful protests. Defense software acquisitions that use structured evaluation scorecards with documented consensus scoring produce more defensible award decisions and fewer protests than those that rely on individual evaluator judgment.