Cybersecurity / RFP Template
Penetration testing RFP template
A complete RFP structure you can copy: objectives, scope, the vendor questions that surface real differences, requirement language for methodology and retest, and a scoring matrix. Use it with us or with anyone.
How to use this template
A penetration testing RFP has one job: make proposals comparable. The ten sections below give you a structure that does that. Copy them into your own document, fill in the scope and dates, adjust the evaluation weights, and issue it. Everything is on this page in full, with no form and no gate, and it prints cleanly if your procurement process runs on documents.
The template is vendor-neutral by design: nothing in it steers the evaluation toward us, and it works whether or not we’re on your shortlist. In the interest of transparency: we publish our own answers to several of the qualification questions, including our methodology, a redacted sample report, our retest policy, and the evidence register behind our claims, so you can score us against this template before we ever join a call.
If you haven’t assembled your scope details yet, work through the pentest scoping checklist first; its answers drop straight into section 3. The reasoning behind the qualification questions is unpacked in our guide to choosing a penetration testing vendor.
The template, section by section
- 01
Introduction and administrative details
Tell vendors who is asking, who owns the process, and how to interact with it. Ambiguity here costs you comparable proposals later.
Include in this section
- Issuing organization, primary RFP contact, and the channel for questions.
- Key dates: RFP issue, deadline for vendor questions, answers circulated, proposals due, shortlist conversations, decision.
- Confidentiality terms for the RFP itself, and whether a mutual NDA is required before detailed scoping information is shared.
- Format and length limits for responses, if any, and where to send them.
- 02
Background and objectives
One or two paragraphs on your organization and product, then the reason this test exists. Vendors scope and price against the objective, so state it plainly.
Include in this section
- What the organization does and what the system under test is, in plain language.
- Why now: a compliance driver (SOC 2, PCI DSS, HIPAA, ISO 27001, GDPR) with its audit or deadline date; a customer security requirement; a major release; or a standing program being re-competed.
- What the engagement must produce: the evidence your auditor, customer, or board actually needs out of the test.
- Whether this is a one-time assessment or the first cycle of a recurring program.
- 03
Scope of testing
The scope section carries most of the pricing signal. List what is in scope, what position testing starts from, and what is explicitly out of bounds.
Include in this section
- In-scope assets: web applications, APIs (with specification availability noted), mobile apps and platforms, network ranges and perspective (external, internal, or both), and cloud accounts and services.
- Environments: production or staging replica, and how test data is handled.
- Access model: user roles to be tested, test accounts provided, and whether cross-tenant isolation is in scope for multi-tenant products.
- Explicit exclusions: systems that must never be touched, plus whether denial of service and social engineering are excluded or separately agreed.
- Constraints: testing windows, change freezes, and any notification requirements.
- 04
Vendor qualification questions
These eight asks separate a manual testing practice from a rebadged scan. Require written answers to each; the pattern of what a vendor will and will not put in writing is itself a result.
- 4.1Methodology: which published frameworks (for example the OWASP Testing Guide, PTES, NIST SP 800-115) your testing methodology aligns to. Attach the methodology document itself.
- 4.2Sample report: attach a redacted sample report from a comparable engagement. Responses without one will be scored accordingly.
- 4.3The actual team: name the individuals proposed for this engagement, their individual qualifications and years of experience, and confirm that the lead tester will attend the scoping conversation.
- 4.4Retest: state whether remediation verification is included in the quoted price, the retest window, and whether the final report is updated after fixes are verified.
- 4.5Scoping rigor: describe what you need to know about our environment before your price is final.
- 4.6Independence: disclose whether you resell products your findings might recommend, or bid on remediation work your findings create, and how any such conflict is separated from testing.
- 4.7Data handling: where our findings and evidence will be stored, who can access them, the retention period, and the destruction process, as terms you will commit to in contract.
- 4.8References: two or three references from comparable engagements that we may contact directly.
- 05
Methodology and testing requirements
Requirement language you can paste into the RFP. It holds every bidder to the same testable bar.
Include in this section
- Testing shall be primarily manual, performed by named engineers, with automated tooling used in support. A tool-only assessment does not satisfy this requirement.
- The methodology shall align to at least one published framework (for example the OWASP Testing Guide, PTES, or NIST SP 800-115), and the vendor shall state which.
- Every reported finding shall be demonstrated with reproduction steps and evidence of impact. Findings that cannot be reproduced from the report will be returned.
- Severity shall be assigned on a stated rubric (for example CVSS-based bands) with the reasoning visible per finding.
- Critical findings shall be communicated within an agreed window of discovery rather than held for the final report.
- 06
Reporting requirements
The report is the deliverable your engineers, auditor, and customers will actually use. Specify its audiences and contents up front.
Include in this section
- An executive summary readable by non-technical leadership, stating overall posture and the risk themes found.
- Technical findings with reproduction steps, evidence, affected assets, severity with rationale, and per-finding remediation guidance.
- A scope statement in the report itself: what was tested, from what position, over what dates, and what was excluded (including exclusions requested by us).
- A remediation-priority view ordered by exploitability and impact, so engineering knows what to fix first.
- Delivery through an agreed secure channel, with distribution limited to named recipients.
- 07
Retest and remediation verification
Without verified remediation, the engagement ends with a list of problems and no evidence any of them were closed. Make retest a requirement rather than an option.
Include in this section
- The engagement shall include a retest of remediated findings within an agreed window after fixes are reported.
- Retest shall verify each fix against the original reproduction steps, and the final report shall be updated to reflect verified remediation status per finding.
- The proposal shall state whether retest is included in the quoted price; if priced separately, that price shall be fixed in the proposal.
- 08
Evaluation criteria
Publish your scoring model in the RFP so vendors argue to your criteria instead of their strengths. The weights below are an illustrative starting point; set your own before issue.
Criterion Suggested weight What to score Methodology and technical approach 25% Framework alignment, manual depth, and how findings are demonstrated Team qualifications 20% The named individuals proposed, their credentials, and lead-tester involvement in scoping Reporting quality 20% Judged from the redacted sample report, against section 6 Retest and remediation support 10% Inclusion, window, and report-update commitment in writing Independence and data handling 10% Conflict disclosure and contractual data-handling terms References 10% Comparable engagements, contactable directly Commercial 5% Total cost including retest, and pricing clarity - 09
Timeline and logistics
Close the RFP with the operational frame: the procurement schedule from section 1, plus the engagement logistics a vendor needs to plan delivery.
Include in this section
- Target engagement window and any hard deadline (audit date, customer commitment, release date).
- Kickoff requirements: NDA execution, scoping session with the delivery team, exchange of test accounts and access.
- Communication cadence during testing, the escalation contact on each side, and the channel for critical findings.
- Logistics for retest scheduling and final report delivery.
- Required attachments checklist: methodology document, redacted sample report, named team with qualifications, references, and the completed pricing table (base engagement and retest shown separately).
Companion assets
Three published pieces pair with this template: the scoping checklist feeds section 3, the vendor guide explains what good answers to section 4 look like, and inside a penetration-testing report shows how to judge the sample reports vendors attach. To print this page for a procurement file, use your browser’s print function; the page strips its navigation on paper.