When the print dialog opens: choose "Save as PDF", then uncheck "Headers and footers" under More settings.
Penetration Testing RFP Template & Buyer's Guide
Executive Summary
A penetration testing RFP gives your organisation leverage. It forces vendors to commit to scope, methodology, qualifications and pricing in writing — and lets you compare apples to apples. This document distils what should go in an effective pentest RFP and provides a ready-to-customise template you can use immediately. It is vendor-neutral with a Fireline section at the end that you can drop or keep based on your needs.
Key takeaways
- A structured RFP shifts negotiation power back to the buyer. Vendors that respond well demonstrate operational maturity; vendors that respond poorly self-disqualify.
- The most common procurement mistake is buying on price alone. The cheapest pentest is rarely the most useful — and often the most expensive when measured in real risk reduction.
- Methodology requirements, deliverables and re-test policy should be in the RFP, not negotiated after award.
- Vendor qualifications matter more than tooling. A senior tester with relevant experience finds in two days what a junior tester misses in a week.
- A defined evaluation matrix prevents post-hoc rationalisation. Decide your weights before you read the proposals.
Who should read this
- Procurement officers running penetration testing tenders for the first time or refreshing existing templates.
- CISOs and security leads defining the technical requirements for offensive security engagements.
- Compliance officers driving NIS2 Article 21(6), DORA Pillar 3 or ISO 27001 control 8.29 evidence requirements.
- Anyone evaluating multiple pentest vendors and needing to compare them on a consistent basis.
Why a Structured RFP Matters
Penetration testing is one of the few cybersecurity services where the gap between the best and worst vendors is enormous. Two firms quoting the same price can deliver wildly different outcomes — one finds a single CVSS-medium configuration issue, the other finds a chain of vulnerabilities that lead to full domain compromise. The difference is rarely tooling; it is people, methodology, scope discipline and reporting quality.
A structured RFP forces vendors to commit. They have to describe their methodology in writing. They have to nominate the actual people who will perform the work. They have to commit to deliverables and re-test policy. And critically, they all answer the same questions, so you can compare them on the same basis.
A bad RFP — one that is essentially a one-line "need a web app pentest, please quote" email — produces a bad procurement. Vendors guess at the scope, pad their quotes for safety, and the buyer ends up paying more for less. Good RFPs are not bureaucracy; they are leverage.
A structured RFP typically reduces the spread between competing quotes by 30-50% (because vendors are not guessing at scope), shortens the time from RFP issue to award by 2-3 weeks (because there is no clarification round), and produces measurably better engagement outcomes (because expectations are clear from day one).
Section 1: Project Scope
Scope is the most important part of any pentest RFP. Vendors that get unclear scope will either pad their quote or under-deliver. Provide as much detail as you have, and explicitly call out what is OUT of scope — that is often more revealing than what is in.
Section 2: Methodology Requirements
Vendors should describe their methodology in writing. The list below is the minimum you should expect. Vendors that cannot answer these questions are immediately disqualified.
Which industry standards does the methodology align with? PTES, OWASP Testing Guide, OSSTMM, NIST SP 800-115, CREST, TIBER-EU? Specify which standards are mandatory for your engagement.
Describe each phase (reconnaissance, threat modelling, exploitation, reporting) and the deliverables produced at each. A vendor that cannot articulate their phases is improvising.
How much of the test is automated vs manual? Automated tooling has its place but a pure tool-based test is barely a pentest. Expect at least 50% manual testing for any application engagement.
How does the vendor demonstrate that all scoped attack surface was actually tested? Coverage metrics, test logs, attack tree, or a simple Excel sheet — pick one.
Daily check-ins? Weekly status calls? Immediate notification of critical findings? Define the rhythm in the RFP and require vendors to commit to it.
Is a re-test of remediated findings included in the price? How long after the initial engagement? How many findings can be re-tested? This is one of the most-disputed contract terms — settle it in the RFP.
Specify the report sections you expect: executive summary, methodology, findings (with CVSS, business impact, evidence, reproduction steps and remediation), risk register, attack chains. Provide a sample structure if you have one.
Section 3: Vendor Qualifications
The single biggest predictor of pentest quality is the experience of the people doing the work. The RFP should require vendors to commit to specific named individuals and to provide evidence of their qualifications.
Vendor commits to specific named testers — not "a tester from our team". Each named tester provides a CV with relevant experience, certifications and past engagements.
Minimum years of pentest experience for the lead tester. Five years is a sensible floor for application work; more for red team or specialised engagements.
OSCP, OSWE, OSEP, GPEN, GWAPT, CRTO, CRTE — list which are mandatory and which are preferred. Certifications are not everything, but they provide a baseline.
Has the team performed engagements in your sector before? Healthcare pentesting, banking pentesting and industrial-control-system pentesting are not interchangeable.
Three customer references at the same scale and similar sector. Vendor must commit to making references available — and the buyer should actually call them.
Professional indemnity insurance with a minimum coverage level. Penetration testing carries operational risk. Insurance is not optional.
The vendor must agree to a written Rules of Engagement document and a permission letter signed before any testing begins. This is the legal foundation of the engagement.
Avoid vendors that quote a single price without naming the testers. The named-tester requirement is the most effective way to prevent the bait-and-switch problem where the senior tester sells the engagement and a junior tester delivers it.
Section 4: Evaluation Matrix
A defined evaluation matrix prevents post-hoc rationalisation. The example weights below are illustrative — adjust to your priorities, but commit to them BEFORE you start reading proposals. The discipline matters more than the exact percentages.
Notice that price is only 15%. If you find yourself weighting price above 25%, you are buying compliance theatre, not security testing. Pentest engagements have a clear quality floor below which the exercise is worthless.
Section 5: Pricing Models
Penetration testing engagements are typically priced one of three ways. The right model depends on the engagement type, the scope clarity and the relationship maturity. Expect vendors to be flexible — anyone who insists on a single model regardless of context is selling something.
Section 6: Red Flags to Watch For
Some vendor behaviours are immediate disqualifiers regardless of price. The list below is the consensus from procurement teams who have run dozens of pentest tenders. If you see any of these in a vendor response, the rest of the proposal does not matter.
- Vendor refuses to name the actual testers who will perform the work, or describes them only in generic role terms.
- No re-test commitment in the proposal, or re-test is offered only at additional cost.
- Sample report is poor quality: thin findings, missing reproduction steps, no business-impact analysis, generic remediation advice.
- Methodology section is one paragraph long and uses marketing language instead of technical specifics.
- Quote is dramatically lower than other vendors with no explanation. The cheapest pentest is rarely the most useful.
- No professional indemnity insurance or refusal to provide proof of coverage.
- No clear Rules of Engagement document or permission letter template.
- Vendor pushes back on customer references or provides only references unrelated to your sector and scale.
- Promise of "automated" testing as the bulk of the engagement. Tools are part of the toolkit, not a replacement for skilled testers.
- Lead time of less than two weeks. Quality engagements need preparation; vendors that can start immediately probably cannot do justice to the scope.
Why Orizon Fireline Stands Out
Fireline is Orizon's penetration testing service. It is built around the principles in this document — named testers, structured methodology, audit-ready reporting and a re-test commitment that is included in every engagement, not bolted on as an upsell.
Contact: [email protected] · orizon.one/services/fireline · EU sovereign infrastructure.