The problem with most penetration testing RFPs is not that they ask for too little: they leave too many decisions to the vendor. A request for "annual penetration testing of our web application" will produce bids from $4,000 to $40,000, from vendors who plan to run an automated scanner to vendors who plan a ten-day manual engagement with a four-person team. Every vendor responded to the same RFP. None of the bids are comparable.
Comparability is the goal. An RFP that produces comparable bids (bids that can be evaluated against each other on quality and price because they describe the same service) requires specifying every dimension that vendors would otherwise decide for themselves.
This guide maps each RFP element that affects comparability, what to specify in each, and why omitting it produces incomparable bids. It closes with an evaluation framework for scoring responses once they arrive.
Four ambiguities in a typical vague RFP each create a decision that vendors resolve differently:
Testing methodology. "Penetration testing" describes everything from automated vulnerability scanning to manual expert-led exploitation to agentic continuous testing. Without a methodology specification, vendors bid on whatever they do. Penetration testing automation: beyond scripted scans maps the full automation spectrum. A buyer who wants exploitation-confirmed findings and receives bids from a vendor who plans automated scanning and a vendor who plans a manual engagement cannot meaningfully compare the two on price.
Scope. "Our web application" could mean a single login page or a fifty-endpoint SaaS platform with four user roles, a GraphQL API, and three third-party integrations. Without a detailed scope specification, vendors estimate scope themselves, and their estimates will vary by a factor of five or more.
Deliverables. Does the report include executive summary only, or detailed technical findings with proof-of-exploitation evidence? Is remediation guidance included? Is retest included or a separate line item? Vendors make these decisions differently unless the RFP specifies them.
Test type. Black box, grey box, or white box testing produces different effort levels for the same target. An RFP that does not specify test type produces bids built on different assumptions about how much information the vendor will have at the start of testing.
Each omission multiplies the incomparability. An RFP with all four ambiguous receives bids that are comparing different services at different effort levels for different deliverables. No procurement process can evaluate those bids fairly.
Start the RFP with context that helps vendors understand the engagement before they see the scope. This section should include:
Organisation overview relevant to security. Industry, regulatory environment, primary technology stack. A financial services company has different compliance requirements than a healthcare startup. A team shipping code daily has different cadence requirements than one releasing quarterly.
Reason for testing. Annual security programme requirement, pre-launch assessment, compliance obligation (PCI DSS, SOC 2, ISO 27001), cyber insurance requirement, post-incident assessment, or vendor security assessment. The reason shapes what the vendor needs to deliver and affects how they prioritise coverage.
Previous testing history. Whether penetration testing has been conducted previously, when, and whether reports are available for reference. Vendors who understand prior testing can scope for depth rather than breadth.
Security programme maturity context. Whether the organisation has a dedicated security team, an existing vulnerability management programme, and how findings from previous tests were remediated. This context helps vendors calibrate the technical level of reporting.
This is the section that most directly determines whether bids are comparable. Every ambiguity here becomes a vendor assumption that creates incomparability. Penetration testing scope: how to define it before you start covers the full scope definition process. For the RFP, require vendors to respond to each of the following:
Systems and assets to be tested. Enumerate specifically:
Do not write "our web application and associated infrastructure." Write the actual URLs, IP ranges, and API documentation location. Vendors who bid on a specific enumerated scope produce comparable bids. Vendors who bid on "web application and associated infrastructure" produce incomparable bids.
User roles and credentials. Specify every user role that must be tested and confirm that test credentials will be available. For a SaaS application: standard user, team administrator, billing administrator, organisation owner, support staff, system administrator. Each role adds testing effort. Vendors who do not know how many roles to test cannot bid comparably.
Environment. Production, staging, or both. If staging, specify whether it is production-equivalent. Vendors who discover mid-engagement that the staging environment has stub authentication produce surprise scope additions.
Estimated asset complexity. Number of unique endpoints, approximate lines of custom code, number of third-party integrations, number of authentication mechanisms. This context helps vendors calibrate effort even when they will build their own scope understanding during testing.
Test type. Require vendors to bid on one of:
Black box vs. white box penetration testing: what's the difference covers the trade-offs. Specify which type is required. If you want bids on multiple types, ask vendors to price each separately.
Methodology. Specify whether the engagement should:
Testing approach for specific categories. If specific vulnerability classes are priorities, name them:
Without this specification, vendors who plan comprehensive manual testing across all categories and vendors who plan automated scanning for common signatures bid on the same line item at very different prices.
Define exactly what you need delivered. Ambiguity in deliverables is a major source of bid incomparability because vendors include different items in their standard deliverable set.
Report format. Specify required sections:
What's in a penetration testing report: a buyer's breakdown and what is inside a VAPT report cover the evidence standard in detail. For RFP purposes, requiring proof-of-exploitation evidence for each critical and high finding distinguishes vendors who deliver confirmed exploitable findings from those who deliver scanner output.
Retest policy. One of the most significant sources of bid incomparability is retest: whether it is included, how many rounds, and within what timeframe. Specify:
Vendors who include retest and vendors who price it separately are describing different services. Requiring a standard retest policy in the RFP makes bids comparable on this dimension.
Debrief and knowledge transfer. Whether a post-engagement debrief call is included, what format (written Q&A, video call, live walkthrough with developers), and what the deliverable is from the debrief.
Raw testing evidence. Whether raw request logs, tool outputs, and testing artefacts are delivered alongside the report. Some buyers require this for compliance or internal review purposes. If it is a requirement, state it: it adds to vendor effort.
Required certifications. Certifications that indicate relevant expertise:
Minimum experience requirements. Years of experience relevant to the testing type, specific industry experience if the engagement requires domain knowledge, specific technology stack experience.
Named tester information. Some organisations require that vendor proposals name the specific tester(s) who will conduct the assessment, not just describe the firm's team. If tester credentials are a selection criterion, require named tester CVs and certifications in the proposal.
Independence requirements. Specify whether testers must be independent from the organisation's existing security service providers. Some compliance frameworks and insurance policies require testing by a firm not otherwise engaged for managed security services.
Subcontracting policy. Whether the winning vendor may subcontract the testing work and under what conditions. Some organisations require that the named testers in the proposal conduct the assessment, not undisclosed subcontractors.
If the engagement must satisfy a specific compliance framework, state it explicitly and require vendors to confirm their methodology satisfies it. Vague compliance requirements produce bids that may or may not satisfy the actual obligation.
Specific framework requirements:
Evidence format for compliance. Whether the report must be formatted to satisfy a specific auditor's evidence requirements. Whether the vendor must sign an attestation that the testing was conducted in compliance with the stated framework. Whether the vendor will participate in audit review calls.
Compliance mapping. Whether the report should include a mapping of findings to specific compliance control failures. Some compliance frameworks benefit from reports that map findings to the specific control section they demonstrate failure for.
Penetration testing rules of engagement: what should be in the agreement covers the authorisation and legal documentation that should accompany any engagement. For RFP purposes, require vendors to provide their standard rules of engagement template as part of the proposal so it can be reviewed before engagement award.
Engagement timeline. Start date requirement, duration in working days of active testing (separate from report writing), report delivery timeline after testing completion.
Communication requirements. Frequency and format of status updates during testing. Whether the vendor provides real-time finding notification during the engagement for critical findings. Contact availability during testing hours for questions.
Emergency escalation. Whether the vendor provides 24/7 emergency contact during testing. The procedure for immediate escalation if testing causes an unexpected production impact.
Retesting timeline. After remediation, how quickly the vendor can turn around retest confirmation. For teams with active deployment cycles, retest turnaround within one week is often necessary.
Requiring vendors to price their response in a specific format is the single most effective step for ensuring comparability. When vendors can structure bids freely, comparing them becomes interpretation work rather than comparison work.
Require vendors to price each of the following as separate line items:
Optional items to price separately:
Requiring itemised pricing reveals the all-in cost (base + retest + debrief) and makes it straightforward to compare vendors who include retest in base pricing against those who separate it.
Specify the evaluation criteria and their relative weights so vendors understand how they will be scored. A clear evaluation framework also disciplines the internal review team.
Methodology and technical approach (30-40%). Does the vendor's proposed methodology cover the scope specified? Does it include active exploitation, not just identification? Is the approach specific to the scope or generic? Does it include coverage of the specific vulnerability categories required?
Team qualifications (20-30%). Do the proposed testers hold the required certifications? Is their experience relevant to the technology stack and industry? Are they the actual testers or a sales team citing firm-level credentials?
Deliverables and reporting (20-25%). Does the proposed report format meet the specified requirements? Is retest included? Is the debrief structured as required? Does the report sample (most vendors will provide sample reports on request) demonstrate the evidence quality required?
Commercial terms (15-20%). Total cost for the defined scope. Retest pricing. Timeline to delivery.
References and past performance (5-10%). Client references from comparable engagements. Whether the vendor can provide references in the same industry or with the same technology stack.
8 questions to ask before buying vulnerability scanning services covers vendor evaluation criteria that apply to penetration testing vendor selection.
For penetration testing services in the US that respond to RFPs with methodology specifics, named tester credentials, and sample reports, VAPT services for compliance-grade evidence packages, and PTaaS for continuous testing that replaces the per-engagement procurement cycle, the 10x Pentest platform covers the application security layer. See pricing or get in touch to request a proposal against your specific RFP requirements. The penetration testing checklist before you start covers the pre-engagement confirmation items that should be completed with the selected vendor before testing begins.
Q1. What should a penetration testing RFP include?
A penetration testing RFP should include eight sections: organisation and engagement context (industry, compliance environment, testing history); scope specification (enumerated URLs, IP ranges, API endpoints, user roles, and environments); test type and methodology (black/grey/white box, active exploitation requirement, framework, specific test categories); deliverables specification (report sections, proof-of-exploitation requirements, retest policy, debrief format); tester qualifications and vendor requirements (required certifications, independence requirements, subcontracting policy); compliance and regulatory requirements (specific framework requirements and evidence format); timeline and project management requirements (start date, duration, communication, escalation); and pricing format requirements (itemised line items for base testing, report, retest, and optional items).
Q2. Why do penetration testing bids vary so widely in price?
Penetration testing bids vary widely because vague RFPs leave critical decisions to vendors, who resolve ambiguity differently. One vendor plans a manual ten-day engagement with four testers and active exploitation of every finding. Another plans a three-day automated scanning run with a brief report. A third plans a hybrid with automated baseline scanning and manual follow-up on high-priority targets. All three bid on the same vague RFP. The price difference between the lowest and highest bid is not vendor margin variation: it is different services for different prices. An RFP that specifies test type, methodology (including whether active exploitation is required), scope, and deliverables produces bids that describe the same service and can be compared on quality and price.
Q3. Should a penetration testing RFP require active exploitation?
Yes, for most engagements. Active exploitation distinguishes penetration testing from vulnerability scanning. A scanner that reports "potential SQL injection" has not confirmed that the injection is exploitable: it has matched a signature. A penetration test that requires active exploitation confirms whether the vulnerability can actually be used by an attacker, documents the payload and impact, and produces proof-of-exploitation evidence. For compliance evidence (PCI DSS Requirement 11.4, SOC 2 auditor expectations), confirmed exploitable findings with proof of exploitation carry more weight than potential findings from signature matching. Requiring active exploitation in the RFP ensures that bids proposing scanner-only approaches are correctly distinguished from bids proposing genuine penetration testing.
Q4. How should a penetration testing RFP handle retest?
Specify retest policy explicitly in the RFP and require vendors to price it as a separate line item or confirm it is included in the base price. The standard is one round of retest for critical and high findings, available within a defined timeframe after remediation (typically two to four weeks). Without a specified retest policy, vendors who include retest and vendors who price it separately appear to have different base prices for the same service. Requiring itemised retest pricing makes the all-in cost directly comparable. Also specify the turnaround time the vendor must meet for retest confirmation, particularly for teams with active deployment cycles where rapid retest enables continuous security validation.
Q5. What tester qualifications should a penetration testing RFP require?
At minimum, require that the specific testers conducting the assessment (not just the firm) hold relevant certifications: OSCP for hands-on exploitation capability, CREST for organisational accreditation, or GPEN/GWAPT for specific test types. Require that proposals name the specific testers assigned to the engagement, not just describe firm capabilities. Require references from comparable prior engagements in the same industry or with the same technology stack. If the engagement serves a compliance requirement, confirm whether the framework specifies any tester independence or accreditation requirements: some compliance frameworks specify that testing must be conducted by an independent third-party firm, which affects whether a vendor who also provides managed security services to the organisation qualifies.
The pentest report is the beginning of the security work, not the end. This guide maps the full remediation lifecycle — triage, routing, developer handoff, SLAs, retest, and compliance evidence.
Tejas Dhokane Sep 18, 2026 
Cyber insurers now require penetration testing as a condition of coverage but not every pentest satisfies underwriting requirements. This guide maps what underwriters actually review and why it matters.
Tejas Dhokane Sep 9, 2026 
An AI agent conducting penetration testing has credentials, tool access, and exploit capabilities. These raise legitimate security questions. This guide maps five risk categories and the design controls that address each.
Tejas Dhokane Sep 8, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
