Software Vendor RFP Checklist for B2B Buyers
A software RFP should state the problem, the functional and non-functional requirements, the security and data needs, the commercial terms and the scoring method before any vendor replies. Score the weighted criteria rather than arguing afterwards, check the references rather than believing the case studies, and run a short paid pilot before signing anything that commits a budget.
What should a software RFP contain?
The document exists to make answers comparable. A vendor can only respond to what is written; an RFP that describes a vision and asks for a price invites proposals that all sound excellent and none of which can be evaluated against each other. The functional content, the constraints and the scoring rule have to be fixed before the first reply arrives, or the evaluation becomes a negotiation about criteria. Send the requirements you have written so far and we will quote a review that turns them into a scorable RFP: request a quote.
There is also a sequencing point that saves months: the RFP is not where you discover what you need. Requirements come out of internal work — the process owners describing how the business actually runs, finance stating what must reconcile, the people who will use the system daily saying where the current pain is. That work is slow and political, and it happens before any vendor is involved. Teams that outsource it to the first vendor who arrives end up with requirements written in that vendor's product language, which then makes every other proposal look like a poor fit — not because they are, but because the benchmark was written around one of the bidders.
One more distinction worth keeping, between three documents that are often confused. An RFI asks the market what exists; it is short, it precedes requirements, and it does not commit anyone. An RFP asks for a proposal against defined requirements and a stated evaluation method. An RFQ asks for a price against a defined scope. Running an RFQ before the scope exists is the most common way to compare three numbers that mean three different things.
Five things a complete RFP does that an incomplete one does not:
- Defines the problem, not the solution. "Reduce the time to compile the monthly consolidated report from days to a defined number of hours" is a problem statement; "build us a data warehouse" is a solution guess that may not solve it.
- Separates requirements from preferences. Must-haves that decide a pass, should-haves that decide a rank, and nice-to-haves that decide nothing. Vendors respond seriously only when that distinction is visible.
- Names the constraints. Existing systems that must be integrated, data that must migrate, the audit and retention obligations, the go-live window, who signs off.
- States the evaluation method in advance. Weighted criteria, who evaluates, what evidence is required, and when unsuccessful vendors get a summary of their scores.
- Sets the process dates. Question deadline, clarification window, submission deadline, evaluation period, decision date. A process without dates attracts vendors who are already busy.
RFP structure
| Section | What goes in | Common mistake |
|---|---|---|
| Problem statement | The business problem, who has it, what it costs today | Describing the wanted software instead of the problem |
| Scope and requirements | Functional requirements, non-functional requirements, integrations, data migration | Listing everything as mandatory; nothing is a priority if everything is |
| Constraints and context | Systems in place, compliance obligations, timeline, decision owners | Leaving compliance out and discovering it in the contract phase |
| Commercial terms | Pricing model expected, contract duration, payment structure | Only asking for a number, so each vendor prices a different scope |
| Evaluation method | Criteria, weights, evidence required, process dates | Announcing the method after proposals arrive |
| Submission format | Document structure, page limits, demo expectations | Accepting free-form submissions that cannot be compared |
Functional and non-functional requirements
Functional requirements describe what the system does: which processes, for which roles, with which outputs. Non-functional requirements describe how well it does them, and they are the ones most often missing — then enforced later, expensively, or not at all.
Worth stating explicitly in most B2B projects:
- Performance. Response times under a stated load, for the operations that matter — order entry, report generation, month-end close.
- Availability. What uptime the business needs, maintenance windows, and what happens when the system is down — a target without a description of acceptable downtime is not a requirement.
- Recovery. RTO and RPO in plain terms: how quickly operations resume after an incident, and how much work may be lost. Both numbers belong in the evaluation, not only in the contract.
- Audit trail. Who changed what and when, retained how long, retrievable by whom — especially where money, stock or personal data moves.
- Accessibility and usability. Who uses the system, on what devices, in which languages; a system the warehouse cannot operate is not implemented, however well it scores.
- Integration and data. Which systems connect, in which direction data flows, and who owns the master record for each entity.
Security and compliance questions
Security is better asked as questions with required evidence than as a yes/no line. The ones worth including:
- ISO/IEC 27001 — does the vendor hold it, and what does the certified scope cover? A certificate covering the sales organisation but not the delivery teams tells you something specific.
- Secure development — where security sits in design, code review and testing; whether dependency and vulnerability handling is routine.
- OWASP Top 10 — whether it is part of the vendor's review for web-facing components; a concrete, answerable question.
- Access control — who can reach your environments and data, how access is granted and revoked, what logging exists.
- Data protection duties — KVKK and GDPR where they apply; who is controller, who is processor, what the data processing agreement says about sub-processors and breach notification.
Commercial terms and SLAs
Ask for pricing in a structure you can compare: what is included, what is charged separately, and how changes are priced. A single number without scope behind it cannot be compared with another single number; the cost and pricing models page explains the common structures and the questions each one raises.
SLAs deserve the same precision as requirements. An availability percentage is only meaningful with its measurement method, exclusions and remedy; a response time is only meaningful with its severity definitions and business hours. Ask each vendor to define the terms inside the SLA rather than accepting a page of percentages with no definitions.
Evaluation scoring matrix
A copyable template. The weights below are an example — set your own against your priorities, and keep the total at 100. Define what 1, 3 and 5 mean before anyone scores, not after the arguments start.
| Criterion | Weight % (example) | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|
| Understanding of the problem | 15 | Restates the brief | Summarises the problem correctly | Shows the problem from a similar project and questions an assumption |
| Functional fit | 20 | Major gaps; workarounds needed | Covers most requirements; some customisation | Covers requirements as standard; extensions documented |
| Non-functional fit | 10 | No answers on performance or recovery | Partial answers; figures not evidence-backed | Meets stated targets with evidence |
| Security and compliance | 10 | No position on security | Policies exist; evidence limited | Certificate scope verified; secure development described |
| Integration and migration | 10 | No experience with the named systems | Similar systems; migration planned loosely | Named systems delivered; migration approach documented |
| Team and delivery | 10 | Team named late or not at all | Team named; process generic | Named team, delivery process, escalation path |
| References | 10 | No references offered | References provided; not yet checked | Comparable projects; references reachable and positive |
| Commercial terms | 10 | Number without scope | Scope priced; changes undefined | Structure transparent; change pricing defined |
| Support and SLA | 5 | Percentages only | Definitions partial | Definitions complete; remedies realistic |
| Total | 100 |
Two disciplines make this work. Score independently before discussing, so the first confident voice does not set the room. And record one line of justification per score — vendors who receive a score summary with reasons accept the outcome far more readily, and your own team can defend it six months later.
A third discipline is about who scores. The panel should include the people who will live with the result — the process owner, the person responsible for the data, someone from security or finance where those functions exist — not only procurement. Evaluations fail quietly when the panel scores what it can judge (the proposal's structure, the sales team's polish) and defers what it cannot (whether the integration approach actually fits the current systems). One technical person with authority to say "this will not work with what we run" prevents more cost than any discount.
Weights themselves deserve one more warning: they are a statement of priorities that becomes visible to vendors. If security is weighted at 5% and price at 30%, serious security-minded vendors will notice, and so will your own team when the contract is signed. A weighting set in a hurry, to fill the table, is read as the truth by everyone outside the room; set it once, with the decision-makers in the room, and change it only through the same formality with which you set it.
Reference checks and pilot
Case studies are marketing; reference checks are evidence. The call that works is short and asks about what happened, not what was delivered: did the project finish, what changed in the scope, who was actually on the team, what would they do differently, and would they start the project again with this vendor. Past tense and specific answers are the signal.
Ask for a reference from a project that resembles yours in size and complexity, not the vendor's proudest work — a flagship implementation twice your budget teaches you little about how the team behaves at your scale. And check the reference yourself: a contact the vendor briefs in advance is a testimonial, not a reference; the useful call is one where the client learns what you are asking on the spot.
A short paid pilot then tests the part no reference can: how this team works with your people when the requirements are incomplete. The design rules are the same ones worth setting for any pilot — real work, written acceptance criteria, one mid-course change, and a decision rule agreed in advance. The outsourcing page treats pilot design in more detail.
Contract clauses to check
- IP assignment — rights to code, documentation and derivatives transferring to you, from creation, not only at final payment.
- Data ownership — your data remains yours; the vendor's rights are limited to what is needed to deliver.
- Acceptance — what acceptance means, who declares it, and the process when something fails it.
- Change control — how scope changes are requested, priced and approved; without it, every change becomes a dispute.
- Exit and transition — source code, access, documentation and assistance at the end; how knowledge transfers if the vendor changes.
- Escrow — where business continuity depends on vendor-held components, what happens if the vendor cannot continue.
- Liability — caps, exclusions and what is uninsured; read it with the same attention as the price.
- Termination — notice periods, obligations after termination, and the data return or deletion process.
Frequently Asked Questions
Should we send an RFI or an RFP first?
An RFI when the market or the problem is unclear — you are asking what exists and what it costs. An RFP when the requirements and the evaluation method are defined; sending one earlier just moves the requirements work into each vendor's proposal, in their words and their priorities.
How many vendors should we invite?
Few enough that you can read every proposal properly and call every reference. Most evaluations lose quality beyond a handful; a shortlist built from an RFI, a screening call and one similar reference project is usually more useful than a long list of famous names.
How should weights be set?
From your priorities, before seeing any proposal, and agreed between the people who will live with the result. A common failure is equal weights across everything, which is a way of saying nothing matters more than anything else; if price or risk dominates for you, the weights should say so.
Should price be scored?
Yes, but as one weighted criterion with its scope fixed, not as the whole evaluation. A price scored without scope behind it rewards the vendor who assumed the least work; price your requirements first, then compare totals for the same thing.
How do I score security answers?
On evidence, not tone. Three levels work: no position (1), policies described (3), certificate scope verified plus secure development described and evidence provided (5). Where a vendor holds no certificate, ask what equivalent controls exist in writing — an honest no with documented controls scores better than an unverifiable yes.
Can we change requirements after the RFP?
Before submissions, yes — with the change announced to everyone. After submissions, only through a formal clarification that all bidders receive; silently changing requirements for one vendor ends the comparability the whole process was built on. After the contract, that is what change control is for.
Sources and standards
- ISO — publisher of ISO/IEC 27001 (information security management); confirm the current edition and a certificate's scope before relying on it.
- OWASP — publisher of the Top 10 web application security risks checklist referenced on this page.
- Scoring-matrix principles follow published RFP-template practice; the weights shown are an example to edit, not a recommendation. This page is procurement guidance, not legal advice, and no certification or audit is claimed for WorldwideTradeX.
Related pages
Software development · IT outsourcing from Türkiye · Cost and pricing models · IT audit and consulting · Request a quote