Send an RFI when you are still learning the market, an RFP when you know your requirements and want vendors to propose how they would meet them, and an RFQ when the specification is fixed and you mainly need comparable quotes. For most security tooling, a short RFI followed by a tight RFP works well.
Definitions in plain words
RFI (request for information). A questionnaire to learn what exists and what vendors can do. It is not an offer and it does not commit you to buy. US federal rules describe it this way: an RFI may be used when the government does not presently intend to award a contract, and responses are not offers.
RFP (request for proposals). A document that states your requirement, the terms you expect, what vendors must include in their response, and how you will evaluate. The federal rule for RFPs lists those same ingredients: the requirement, anticipated terms, the information required in a proposal, and the evaluation factors with their relative importance.
RFQ (request for quotation). In common usage, a request for prices on a defined item or service. It suits purchases where the thing you are buying is already settled.
You do not need to be a government buyer to borrow this vocabulary. It is useful because every vendor already knows it.
Which one fits which situation
| Situation | Send | Why |
|---|---|---|
| You do not yet know what categories or approaches exist | RFI | Cheap way to learn before you commit to requirements |
| You know the problem and have written requirements | RFP | Lets vendors propose approaches and be scored on the same criteria |
| You are renewing or adding seats of a tool you already run | RFQ or a direct renewal | The specification is fixed |
| You have a long list of eight or more names | RFI, then cut | Avoids making vendors write long answers you will not read |
A two-step pattern that saves everyone time
- Send a one or two page RFI to a long list. Ask for deployment options, supported languages and ecosystems, how findings reach developers, and where customer data is stored.
- Use the answers to cut the list to three or four vendors.
- Send those vendors the full RFP, with your environment description, your knockout questions, and your scoring method.
- Run a hands-on test on your own code before final scoring, so claims are checked against evidence.
The federal guidance also encourages exchanges with interested parties early, from the time a requirement is first identified, and lists draft RFPs and one-on-one meetings as ways to do it. A private company can do the same: share a draft with two vendors and ask what is unclear.
Mistakes to avoid
- Skipping the RFI and writing an RFP from vendor brochures. You end up copying one vendor's feature list into your requirements, which tilts the result before anyone responds.
- Sending a 200 question RFP to ten vendors. Quality drops, and your team cannot score that much text.
- Hiding the evaluation method. Tell vendors how you will weigh answers. It makes responses more focused.
- Calling a sales call an RFI. If there is no written, comparable answer, you cannot score it.
A worked example: one purchase, three documents
Imagine a mid-sized software company that wants better visibility into vulnerable dependencies. The security lead does not yet know whether the answer is a scanner, a platform, or a change in process. That is an RFI problem.
Week 1, the RFI. The security lead sends two pages to ten vendors. The questions are about the shape of the market, not the details of a contract. Which package ecosystems do you read? Can you run inside our network? How do findings reach a developer? What data leaves our environment? The responses are short, and the lead scores them pass or fail against three deal breakers. Four vendors drop out. Six remain.
Week 2, the RFP. By now the team has written requirements. The RFP goes to four vendors and includes the environment description, ten scored questions, a response template, the evaluation factors with weights, and the dates for questions, responses and demos. Vendors are asked to say whether each capability is generally available, in early access, or on a roadmap.
Week 4, the RFQ, if you need one. Suppose the company picks a vendor and later wants to add a second business unit under the same terms. The specification is fixed, so a short request for a quotation, or simply a quote request under the existing agreement, is enough. Sending a new RFP at that point would waste everybody's time.
What each document should contain
| Document | Must contain | Should not contain |
|---|---|---|
| RFI | Purpose, a promise that it is not an offer, five to ten open questions, a reply date | Weights, contract terms, detailed requirements |
| RFP | Requirement, environment, expected terms, response format, evaluation factors and weights, timeline | Vendor names, the incumbent's pricing, wishlists with no priority |
| RFQ | Exact item or scope, quantity, term, delivery or start date, reply date | Open-ended capability questions |
How the three documents relate to a proof of concept
A hands-on test is not a substitute for any of these, and none of these replaces it. The RFI narrows the field. The RFP gets written, comparable commitments. The test shows whether the commitments hold on your code. Treat the test as the final scored section, with success criteria written before the trial starts, and share those criteria with vendors so nobody is guessing.
Pitfalls specific to security tools
- Asking an RFI to do the work of an RFP. If you ask for a detailed architecture review in an RFI, you will get marketing pages.
- Treating the RFP as a contract. Responses inform the contract, and commitments that matter should be written into it.
- Forgetting internal readers. Legal, privacy and procurement need time with the draft. Send it to them before it goes to vendors.
- Sharing the incumbent's data. Do not pass one vendor's pricing or technical details to another.
A short decision rule
If you cannot yet write five must-have requirements, send an RFI. If you can, and more than one vendor could plausibly meet them, send an RFP. If one product and one scope are already settled, ask for a quote.
Where Safeguard fits
If dependency risk, reachability, policies and gates, or SBOMs are on your requirements list, Safeguard is one option you could invite to respond. You can also run the free scan at https://gold.safeguard.sh/scan on a repo before you write requirements, to see what a finding looks like in practice.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an inventory view shows, then use it to decide which RFI questions about ecosystems and components matter most to you.
Quick check
Can a small company skip the RFI?
Yes, if you already know the category and have a short list from peers. Go straight to a short RFP and a hands-on test.
Does an RFI commit us to buy?
No. An RFI gathers information and responses are not offers. Say so in the first paragraph so vendors understand the stakes.
Should we share the scoring weights with vendors?
Yes. The federal RFP rule expects evaluation factors and their relative importance to be stated, and the same logic helps private buyers get focused answers.
Sources
Last reviewed: 19 October 2026.
