Writing a VAPT RFP That Gets Comparable Quotes

Three proposals arrive. One is forty pages and quotes a fixed price. One is six pages and quotes a day rate. One quotes two figures depending on an assumption nobody asked them to make. They cannot be compared, and the reason is almost always in the document that was issued to them.

Four drafting mistakes cause most of it.

1. Specifying the method instead of the target

The most common, and the most counterproductive. An RFP that runs to several pages on required methodology, tooling and certifications, and half a paragraph on what is actually being tested.

This inverts the effort. Vendors respond by restating your methodology section back to you, because that is what they are being scored on, and every proposal becomes identical on the things you specified and silent on the things you did not. Meanwhile they still have to guess the scope, and each one guesses differently — which is where the price variance comes from.

Specify the target precisely; state the methodology as a minimum standard and stop. Naming OWASP WSTG or NIST SP 800-115 as a floor is enough. What you want back is how they would approach your system, which is the part that actually differentiates them.

2. Leaving the API ambiguous

This one line accounts for more quote variance than anything else in a VAPT tender. "Test our web application" is read by one vendor as the interface, by another as the interface plus the API behind it. Those are materially different pieces of work, and the cheaper proposal is frequently the one that assumed less.

State explicitly whether the API is in scope as a target in its own right or only incidentally as the thing the front end talks to. The same applies to administrative interfaces, which are often a separate application wearing the same brand, and to mobile clients, where two platforms plus a shared backend is three targets rather than one. The counting is in how a VAPT scope gets sized.

3. Not publishing the evaluation criteria

If vendors do not know how they will be scored, they optimise for the thing tenders usually reward, which is price. You then receive three proposals competing on cost and discover that the cheapest quoted fewer days.

Publishing the weights changes the responses you get. If technical approach carries more weight than price, proposals will spend their effort on technical approach. Set the weights before any proposal arrives, so they are a decision rather than a justification.

Ask for the price broken into tester-days plus reporting, with retesting itemised separately. That single instruction makes otherwise incomparable proposals comparable, because it forces every vendor onto the unit they all actually price in.

4. Timelines that price in risk you did not intend

Two failures here. Asking for delivery inside a window that does not fit the work produces either a declined bid or a padded price. And running the tender so that testing finishes days before a deadline leaves no room for remediation or the retest — which is the artefact the deadline usually exists for.

Work backwards from the date you need the closure document: retest, then remediation, then reporting, then testing, then mobilisation. The result is usually earlier than expected, and it is the single most useful number in the RFP.

What to include, briefly

Scope, with exclusions and the reason for each. Roles and how many accounts will be provided. Environment, described honestly. Any hard constraints — change freezes, third-party components you cannot authorise. Methodology as a floor. Deliverables, including whether retesting and a closure document are required. Evaluation criteria with weights. The timeline, derived backwards.

Send all three vendors the same document. Otherwise you are comparing quotes for different work.

Two questions worth asking in the response

Both are hard to answer generically, which is the point.

• What proportion of the engagement is manual, and what will the manual portion be spent on? A credible answer names activities — authorisation testing across roles, business logic review of named workflows. An evasive one describes proprietary technology.
• Given this system, what information would you want from us, and what would you do differently without it? A tester who has thought about your system will answer specifically; one who has not will restate definitions. The background to that question is in black, grey and white box testing.

Security Brigade publishes a VAPT vendor evaluation and RFP template — the section structure, the requirement wording and a default set of evaluation weights — as a document you fill in and issue yourself. It names no vendor and is written to work whoever you pick.