Last updated: August 2026
Penetration Testing RFP Template
A structured template covering the three sections most penetration testing RFPs leave dangerously vague: scope, SLAs, and retesting. Vague terms in any of these three areas produce vendor responses that aren't actually comparable to each other, since each vendor ends up answering a slightly different, self-defined question.
The seven sections this template covers
- Precise scope definition
- Testing frequency and continuity model
- SLA requirements by finding severity
- Retesting and remediation verification process
- Required reporting format and deliverables
- Tester qualifications and methodology standard
- Vendor response evaluation criteria
1. Scope: be precise, not general
List specific systems, applications, IP ranges, and network segments in scope — not a general description like "our web application." Specify explicitly what's excluded (third-party integrations you don't control, production databases if testing is restricted to staging) and any testing constraints (blackout windows, rate limits on automated scanning). A vendor quoting against vague scope will either pad the estimate to cover ambiguity or under-scope and generate change orders once real work begins.
2. Testing frequency: continuous or point-in-time?
Specify whether you need point-in-time testing on a fixed schedule (quarterly, annually) or continuous/near-continuous testing. This depends on how frequently the target environment actually changes — a system with infrequent releases may be well served by scheduled point-in-time testing; a system with continuous deployment benefits from continuous testing, since a point-in-time test only reflects the environment as of the test date and can miss vulnerabilities introduced by later changes.
3. SLAs by finding severity — the section most often left vague
| Severity | RFP should specify |
|---|---|
| Critical | Maximum hours from discovery to notification |
| High | Maximum business days to notification |
| Medium / Low | Included in final report timeline, defined explicitly |
Require the vendor to commit to specific timeframes for each severity tier, not a general "prompt notification" clause — the specific numbers are what make responses across vendors actually comparable.
4. Retesting: specify terms before signing, not after
Specify whether retesting of remediated findings is included in the base price or billed separately, the expected turnaround time for retesting once a fix is deployed, and whether retesting covers only the specific finding or includes a broader regression check. Leaving this to post-contract negotiation typically results in either unexpected additional cost or an informal, undocumented retesting process that doesn't produce a clean audit trail.
5-7. Reporting, tester qualifications, and evaluation criteria
Require a specific reporting format (executive summary plus technical detail, CVSS scoring, remediation guidance per finding) rather than accepting "a report will be provided." Require the vendor to specify which methodology standard they follow — OWASP Testing Guide and PTES are the commonly referenced frameworks for web application and infrastructure testing respectively — and how their process maps to it, which gives a more concrete comparison basis than a general "industry best practices" claim.
Finally, define your own evaluation criteria before responses arrive — weighting scope coverage, SLA commitments, retesting terms, and tester qualifications explicitly — so the comparison is structured rather than an ad hoc judgment call once proposals are in hand.
Working with Code Ninety
Code Ninety publishes its penetration testing results and methodology directly, and responds to structured RFPs following this exact scope-SLA-retesting framework.
Frequently asked questions
What should a continuous penetration testing RFP cover?
A well-scoped RFP for continuous penetration testing should specify: precise testing scope (which systems, applications, and network segments), testing frequency and whether it's continuous or point-in-time, SLA requirements for how quickly findings of each severity level must be reported, the retesting process for verifying remediated findings, required reporting format and deliverables, and the methodology standard being followed (such as OWASP or PTES).
Why do most penetration testing RFPs leave scope, SLAs, and retesting vague?
These three areas require the buyer to make specific decisions before the RFP goes out — exactly which systems are in scope, what response time is actually needed for a critical finding, and whether retesting is included or billed separately — and it's easier to leave them general and let vendors propose their own terms. The result is responses that aren't directly comparable to each other, since each vendor is answering a slightly different question.
Should penetration testing be continuous or point-in-time?
This depends on how frequently the target environment changes. A system with infrequent releases may be adequately served by point-in-time testing on a fixed schedule (quarterly or annually). A system with continuous deployment and frequent infrastructure changes benefits more from continuous or near-continuous testing, since a point-in-time test only reflects the environment as it existed on the test date, and can miss vulnerabilities introduced by changes made afterward.
What retesting terms should be specified in the RFP, not left to negotiation later?
Specify whether retesting of remediated findings is included in the base engagement price or billed separately, the expected turnaround time for retesting after a fix is deployed, and whether retesting covers only the specific finding or includes a broader check for regression. Leaving this to post-contract negotiation typically results in either unexpected additional cost or an informal, undocumented retesting process.
What methodology standards should a penetration testing vendor follow?
OWASP Testing Guide and PTES (Penetration Testing Execution Standard) are commonly referenced methodology frameworks for web application and infrastructure testing respectively. Requiring a vendor to specify which standard (or combination) they follow, and how their process maps to it, gives a more concrete basis for comparing vendor responses than accepting a general claim of following industry best practices.