VAPT & penetration testing specialists · Indiasales@bugfoe.com
PentestProvidersIndia · by BugFoe
Buying

Pentest RFP Questions That Separate Strong Providers from Weak Ones

A request for proposal is only as useful as the questions in it. Use these to compare providers on substance rather than slide decks.

Updated October 20265 min readBy the PentestProviders Security Research Team

Penetration testing proposals tend to look alike. Every provider promises experienced testers, manual techniques and clear reports. The way to tell them apart is to ask questions that require specific, checkable answers. This list is organised by theme so you can lift the sections you need into your own request for proposal.

India contextAsk every bidder to confirm prices exclude or include 18% GST, how many tester-days are manual, and whether retests are included. If a firm claims CERT-In empanelment, check the legal entity against CERT-In's published list. Our VAPT cost guide shows typical ranges.
How to use this listSend a clear scope document with the questions, ask providers to answer each one directly, and request an illustrative sample report. Score replies against the same criteria. Specific answers with examples are a good sign; vague ones that repeat marketing copy are not.

Before you write the RFP

The quality of replies depends on the quality of what you send. Include a short scope covering targets, user roles, environment, knowledge level and timing. Our scoping guide walks through what to include. State any compliance driver up front, along with the date you need a final report.

Set a realistic timetable. Give providers a week or two to reply, allow a short window for clarifying questions and share every answer with all bidders so nobody gains an advantage. Say when you will decide and when testing needs to start, so providers can check tester availability before they commit to dates.

Keep the invitation list short. Three to five serious providers give you enough contrast without burying your team in reading.

Method and coverage

  1. Which methodologies or standards do you follow for this type of test, for example the OWASP Web Security Testing Guide, PTES or NIST SP 800-115?
  2. What proportion of the effort is manual testing, and which tasks do you automate?
  3. How do you test authorisation between users and roles?
  4. How do you approach business logic flaws specific to our application?
  5. What will you need from us: accounts, documentation, source code, network access?
  6. How do you decide when coverage of an area is sufficient?
  7. Which tests or techniques will you avoid in production, and why?

Good answers name concrete techniques and explain trade-offs. Watch for replies that list scanning tools but say little about what testers do by hand.

People and supervision

  1. Who will do the testing, and what relevant experience do they have with similar targets?
  2. Are testers employees or subcontractors? If subcontracted, how are they vetted and bound by confidentiality?
  3. Will the same people who scope the test carry it out?
  4. How is work reviewed before the report is issued?
  5. Can we speak with the lead tester before work begins?

Ask for role descriptions or anonymised profiles if names cannot be shared. If a provider relies on individual certifications, ask how those relate to the specific test you need.

Reporting and communication

  1. Can you share an illustrative or redacted sample report?
  2. How are findings rated? Which version of CVSS do you use, and do you add business context?
  3. Does each finding include reproduction steps, evidence and specific remediation advice?
  4. Is there an executive summary written for non-technical readers?
  5. How quickly do you report critical issues found during testing?
  6. What format is the report delivered in, and can findings be exported to our ticketing system?
  7. Will you hold a debrief call to walk engineers through the findings?

If CVSS matters to your internal process, our CVSS v4.0 guide explains what to look for in a provider's ratings.

Retesting and follow-up

  1. Is a retest of fixed findings included in the price? Within what time window?
  2. What does the retest cover: only the original findings, or the surrounding functionality as well?
  3. Will you issue an updated report or letter showing which findings are closed?
  4. Can our engineers ask questions about remediation between the report and the retest?

Retesting is where risk is actually reduced, so treat vague answers here as a warning. See the remediation and retesting guide for what a good process looks like.

Security of our data

  1. How do you store evidence, credentials and reports during and after the engagement?
  2. How long do you retain our data, and how is it deleted?
  3. Who inside your organisation can access our findings?
  4. Will you sign our NDA, or do you provide your own?
  5. What written authorisation do you require before testing begins?
  6. Do you hold professional liability or cyber insurance appropriate to this work?

Commercials and logistics

  1. Is the proposal fixed-price, and what would cause the price to change?
  2. How many tester-days are included, and how were they estimated?
  3. What is the earliest start date, and how long from final testing day to report?
  4. What happens if testing is blocked by issues on our side, such as broken accounts?
  5. Are there any extra charges for debriefs, retests or report revisions?

Asking for tester-days makes quotes comparable. A low price with very few days is not a bargain. Use the cost calculator to sense-check effort before replies arrive. If quotes for the same scope differ widely in tester-days, ask each provider to explain what the extra or missing days are spent on.

Scoring the replies

Have at least two people score each proposal independently, then compare notes. Disagreements usually point to a question that needs a follow-up call rather than a guess.

Agree the scoring criteria before you open any proposals, so the loudest reply does not win by default.

CriterionSuggested weightWhat a strong reply shows
Method and coverage30%Specific manual techniques for your target type
People and review20%Relevant experience and a real peer-review step
Reporting quality20%Clear sample report with evidence and fixes
Retest and support15%Included retest, defined window, updated report
Commercials and timing15%Transparent effort, fixed price, realistic dates

Weights are illustrative; adjust them to your priorities. A short call with the top two providers often settles the decision.

Red flags in replies

  • Guaranteed "zero false positives" or claims of finding every vulnerability
  • Very low tester-day counts for a complex scope
  • No sample report, or one that is mostly scanner output
  • Reluctance to name who will test or how work is reviewed
  • No mention of written authorisation before testing starts

Frequently asked questions

How many providers should we invite to an RFP?

Three to five is usually enough. More than that creates review work without improving the decision, especially if your scope document is clear.

Should we ask for a sample report?

Yes. A redacted or illustrative sample shows writing quality, evidence standards and how remediation advice is framed, which matter more than the number of tools listed.

Running a tender? Send us your scope through the quote form and we will answer these questions in our proposal for VAPT, compliance pentesting or any other test.

PentestProviders Security Research Team
Written and technically reviewed by practising penetration testers and SOC analysts. Last reviewed October 2026. See how we test.

Ready to find your risks before attackers do?

Tell us what you need tested or monitored. A senior consultant replies within one business day with a scoped, fixed-price proposal.

  • Fixed-price proposal
  • Reply within 1 business day
  • NDA on request