Pentest RFP · scope, methodology, rules of engagement, deliverables
Buy a real penetration test, not a vague scan.
A fill-in RFP template for soliciting penetration testing proposals you can actually compare. It pins down scope and targets, methodology, rules of engagement, deliverables, tester qualifications, and timeline. Without structure, you get wildly different bids and arbitrary prices. With it, you can tell who understands the work and who is selling you a scanner's output.
Why a structured RFP matters
“Penetration test” covers everything from a deep, mostly-manual engagement to an automated vulnerability scan with a logo on top. If you ask three vendors for a quote with a single sentence, you will get three proposals that are impossible to compare and prices that look random. The vendor who scoped the most serious work often looks the most expensive, and the one who quoted a scan looks like a bargain — until you read the report.
A structured RFP fixes that by making every vendor answer the same questions. This template is built from the same engagement structure we use to scope our own penetration testing work. If you want the underlying concepts, the penetration testing and OWASP Top 10 glossary entries explain the terms used throughout.
1. Engagement objectives
- Driver: state why you need the test — a customer requirement, a SOC 2 audit, a compliance mandate, or a pre-launch check.
- Goals: describe what a successful engagement proves, beyond simply producing a report.
- Audience: name who will read the results and what decision they will make from them.
- Compliance mapping: note any framework the test must satisfy so vendors can speak to it directly.
2. Scope & targets
- Targets: list the exact assets in scope — web apps, APIs, mobile apps, networks, cloud accounts — with URLs, IP ranges, or identifiers.
- Test type: specify black-box, grey-box, or white-box, and the access or credentials you will provide.
- Environment: state whether testing is against production or a staging mirror, and any data-handling constraints.
- Out of scope: explicitly list systems, techniques (such as denial-of-service or social engineering), and third parties that are off-limits.
- Size and complexity: give enough detail — number of user roles, endpoints, integrations — for vendors to scope accurately.
3. Testing methodology
- Standards: ask which recognized methodology the vendor follows, such as the OWASP testing guidance or an equivalent framework.
- Manual vs automated: require a clear split, since a real penetration test is mostly manual and not just a scan.
- Coverage: ask how they will test authentication, authorization, business logic, and the relevant OWASP Top 10 categories.
- Tooling: ask what tools they use and how they validate findings to rule out false positives.
- Retesting: state whether you require a verification round after fixes are applied.
4. Rules of engagement
- Authorization: define written permission to test, who signs it, and the legal scope it covers.
- Testing window: specify allowed dates and hours, and whether testing must avoid peak traffic.
- Communication: name a point of contact on each side and the channel for real-time issues.
- Emergency stop: define how testing is paused if something breaks, and who can call it.
- Data handling: require that any sensitive data accessed during testing is handled and destroyed per agreed rules.
5. Deliverables & reporting
- Executive summary: a non-technical overview of risk and posture for leadership.
- Detailed findings: each issue with a severity rating, evidence, reproduction steps, and impact.
- Remediation guidance: concrete, actionable fixes for every finding, not just a description of the problem.
- Retest report: documented verification that fixed issues are actually resolved.
- Format and timeline: when the draft and final reports are due, and how results are delivered securely.
6. Tester qualifications
- Certifications: relevant credentials held by the testers who will actually do the work.
- Experience: similar engagements in your industry or against your kind of system.
- Sample report: a sanitized example so you can judge depth and report quality before you buy.
- References: contacts who can speak to the vendor's work and professionalism.
- Insurance and liability: confirmation of appropriate coverage for the engagement.
7. Timeline & logistics
- Timeline: your required start and end dates, and any hard deadline driving the work.
- Budget: a range or a request for itemized pricing, so proposals are comparable.
- Contract terms: confidentiality, data handling, and any procurement requirements on your side.
- Evaluation criteria: the weighting you will use to choose, so vendors know what matters most.
- Submission: how and by when proposals are due, and who to send questions to.
How to use this template
Start with the objectives and scope sections — they do the most work. Be precise about what is in scope and what is off-limits, because vague scope is the single biggest source of mispriced and mismatched proposals. State your test type (black-box, grey-box, or white-box) and the access you will provide, since that alone can change the effort and the price substantially.
Send the same document to every vendor, give them a clear submission deadline and a point of contact for questions, and define your evaluation criteria up front so the decision is not made on price alone. Ask for a sanitized sample report — it tells you more than any sales call. If the test is for a SOC 2 audit, our SOC 2 pentest prep guide walks through what auditors expect to see.
How this connects to our work
This template mirrors how we scope our own penetration testing engagements — clear scope, a documented methodology, defined rules of engagement, and a report that tells you what to fix and how serious it is. Depending on what you are protecting, that might be a web application pentest or a network penetration test, and we are happy to tell you which one your situation actually calls for.
If you would like us to respond to your RFP, or you want a second opinion on the scope before you send it out, see how engagements are priced or reach out to talk it through.
Frequently asked questions
Why send an RFP instead of just asking for a quote?
Because a one-line quote request gets you wildly different proposals you cannot compare. One vendor scopes a deep manual test, another a quick automated scan, and the prices look arbitrary. A structured RFP makes every vendor answer the same questions about scope, methodology, and deliverables, so you are comparing like for like and can see who actually understands the work.
What is the difference between black-box, grey-box, and white-box testing?
Black-box gives the tester no inside information, simulating an external attacker with no access. White-box provides full access — source code, credentials, architecture — for the most thorough coverage. Grey-box sits in between, typically with a normal user account, and is the most common and cost-effective choice for application testing.
What should the final deliverable include?
An executive summary for non-technical stakeholders, detailed findings with severity ratings and reproduction steps, concrete remediation guidance, and ideally a retest of fixed issues. A good report tells you not just what is wrong but how to fix it and how serious each issue really is — a list of raw scanner output is not a penetration test report.
How do we evaluate a tester's qualifications?
Ask for relevant certifications, a sanitized sample report, the methodology they follow, and references for similar work. Certifications are a useful signal, but a redacted sample report tells you more — it shows the depth of their testing and the quality of their writing, which is what you actually receive at the end.
Related resources & reading
Want us to respond to your pentest RFP?
Send us the scope and we will tell you exactly what we would test, how, and what you would receive — or help you tighten the RFP before it goes out. See how engagements are priced or book a call.