Who Actually Buys Your Software in a Federal Agency: Contracting Officers, CORs and Program Offices
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
In a commercial sale, the person who loves your product, the person who controls the budget and the person who signs the order are often a short walk apart. In a federal agency they sit in different offices, follow different rules and can each stop a deal in a different way.
Knowing who does what saves a software company months of selling to the wrong person. This guide covers the main roles in a federal software purchase, what each one can and can’t do, and when to talk to them.
The one rule that matters most
Only a contracting officer can commit the government to a contract. The Federal Acquisition Regulation (FAR Subpart 1.6) gives contracting officers that authority, and each one holds a written appointment, often called a warrant, that sets its limits.
Everyone else, however senior and however enthusiastic, can’t legally agree to buy your product, change a contract’s terms or approve extra work. A promise from a program manager or an end user isn’t a contract. Work done on that kind of promise is an unauthorized commitment, and the government doesn’t have to pay for it unless the agency later chooses to ratify it.
Keep that rule in mind through every conversation below.
The roles in a federal software purchase
| Role | What they do | Can they commit the government? |
|---|---|---|
| Contracting officer (CO) | Runs the acquisition, issues the solicitation, awards the contract and signs changes | Yes, within the limits of their warrant |
| Contract specialist | Does much of the day-to-day acquisition work under a CO: drafting documents, answering questions, managing the file | No |
| Program office (requiring activity) | The part of the agency that needs the capability, defines the requirement and usually owns the budget | No |
| Contracting officer’s representative (COR) | Designated in writing by the CO to monitor technical performance after award | No |
| Technical evaluators | Score proposals against the solicitation’s evaluation criteria | No |
| End users | The staff who will use the software day to day | No |
| Security and IT governance | CIO staff, information system security officers and the authorizing official who grants an authority to operate | No, but they can block deployment |
| Small business office (OSDBU) | Advocates for small business participation and advises on set-aside decisions | No |
Before a solicitation: the program office leads
Most of a software deal is shaped long before a solicitation posts, and the program office does the shaping. It decides what problem needs solving, writes or drives the requirement, estimates the cost and pushes for the funding.
This is the stage where a software company has the most influence. Demonstrations, answers to sources sought notices and RFIs, and conversations at industry days all reach the program office while the requirement is still open. Agency procurement forecasts often name a point of contact for exactly this reason.
Two cautions apply:
- Program staff can’t promise an award. Treat interest as a signal, not a commitment.
- Once a solicitation posts, the rules change. Questions go through the contracting officer or contract specialist named in the solicitation, usually in writing, so that every bidder receives the same answers.
During a competition: the contracting officer leads
From the moment a solicitation is released until award, the contracting officer controls communication with bidders. Contacting evaluators or program staff about an open competition can harm your bid and, in some cases, raise procurement integrity concerns.
What the contracting side wants from you during this window is a compliant, easy-to-evaluate proposal. That means following the instructions and evaluation criteria in the solicitation closely. See Sections L and M explained for how those two sections drive what evaluators score.
After award, the contracting officer is also your route to a debriefing and the party a bid protest would name.
After award: the COR and the users
Once the contract is in place, day-to-day oversight usually moves to the contracting officer’s representative. The COR checks that the software is delivered and performs as the contract requires, reviews deliverables and reports problems to the contracting officer.
A COR can’t change the contract. If a COR or a user asks for a new feature, extra seats, a different deployment or work outside the statement of work, the right answer is to ask for a modification from the contracting officer before you deliver it. Delivering first and asking later is how vendors end up doing unpaid work.
End users matter more after award than their formal authority suggests. Adoption by real users is what turns a pilot into an option-year exercise or a follow-on buy, and it’s the evidence your next past performance reference will rest on.
The gatekeepers software companies forget
Two groups can stall a software purchase that everyone else wants:
- Security and IT governance. Software generally needs an authority to operate before it can be used with agency data, and the authorizing official decides whether to grant one. Cloud products are often expected to have a FedRAMP authorization. Bring your security documentation early and be clear about which controls an independent assessor has verified and which are self-attested. See verified vs. self-attested.
- Small business offices. If you are a small business, the agency’s OSDBU or small business specialist can help a program office consider a set-aside. See small business set-asides.
A practical map for your account plan
For each agency you target, try to name:
- The program office that owns the problem your software solves, and who in it controls the budget.
- The contracting office that buys for that program, and whether it typically buys through its own contracts, a contract vehicle or a reseller.
- The security and IT governance path a new product has to clear.
- The small business contact, if you qualify.
Gaps in that map tell you where your next conversation should be.
Where it fits in your federal readiness
Knowing the buyers gets you into the right rooms. What those buyers check once you’re there, from registration to security and compliance evidence, is what decides whether you can actually be bought.
To see where your company stands across the categories federal buyers check, score your company’s federal readiness.
Related reading
- How to Sell Software to the Federal Government: The Complete 2026 Guide for ISVs
- Agency Procurement Forecasts for Software Companies, Explained
- Sources Sought and RFIs for Software Companies: Why Answering Early Shapes the Contract
- Authority to Operate (ATO) for SaaS Companies: What It Is and How Agencies Grant One
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.