Penetration Testing RFP Template

1. Introduction and objectives

[Organization name] (the "Organization") invites qualified penetration testing providers to submit proposals for a one-time penetration test covering web application penetration testing. This document sets out the scope, methodology, rules of engagement, deliverables, timeline, vendor requirements, evaluation criteria and submission instructions. Proposals must follow the structure of Sections 2 to 9 so that they can be compared directly.

[Describe the Organization in two or three sentences: what it does, the products or systems under test, the users they serve and the data they handle.]

Objectives

• Identify and demonstrate exploitable vulnerabilities in the in-scope systems, including business logic, authentication and authorization flaws that automated scanners do not find.
• Rate every finding by severity and business impact, with clear reproduction steps and remediation guidance that the Organization's engineers can act on.
• Validate remediation through retesting, so closed findings are verified rather than assumed.
• Establish a repeatable testing relationship with a provider whose testers, methodology and reporting meet the requirements in Section 7.

2. Scope

The following assets are in scope. Quantities are the Organization's best current estimate and will be confirmed during scoping; proposals must price each scope item separately (see Section 8).

Testing approach

Testing will be performed grey box: testers receive test accounts for each user role, basic architecture documentation and target lists, so effort goes to exploitation rather than discovery. This is the Organization's preferred default.

Environments

[State whether testing runs against production, a production-like staging environment, or both. Where staging is used, confirm that it mirrors production configuration and data shapes, and name the URLs, IP ranges and application identifiers for each environment.]

Out of scope

[List any systems, third-party services or test types that must be excluded, for example denial-of-service testing, systems operated by a managed service provider, or physical access to data centers.]

Vendors must state every assumption they make about scope and quantities, and must identify any item in the table above that they cannot test with their own employees.

3. Methodology and standards

Proposals must describe the methodology in enough detail for the Organization to judge depth, and must align with the following standards where they apply to the scope:

• OWASP Web Security Testing Guide (WSTG) and OWASP Application Security Verification Standard (ASVS) for web applications and APIs, including the OWASP API Security Top 10.

Minimum methodology requirements

• Manual testing must form the majority of the effort on application, API, mobile and AI scope. Automated scanning is acceptable for discovery and coverage but is not a penetration test on its own. Proposals must state the expected manual versus automated share and name the tools and any AI agents used in each phase.
• Authenticated testing across every user role listed in Section 2, including horizontal and vertical privilege escalation, insecure direct object references and business logic abuse.
• Every reported vulnerability must be validated by a tester with a working proof of concept. Unvalidated scanner output will be rejected.
• Severity ratings must use CVSS v4.0 (or v3.1) base scores adjusted for business context, with the rationale for each rating documented.
• Findings must be chained where possible to show realistic attack paths and actual impact rather than isolated weaknesses.

4. Rules of engagement

The following rules apply to every vendor and every scope item. Proposals must confirm acceptance of these rules or state, clause by clause, any exception requested.

• Testing window: [testing window]. Testing outside business hours, or within a specific maintenance window, must be agreed in writing before the engagement starts.
• Authorization: The Organization will provide written authorization naming the in-scope assets, the authorized testers and the testing window before any testing begins. No testing may proceed against assets that are not named in the authorization.
• Production safeguards: No denial-of-service, resource exhaustion or destructive testing. Exploitation of a confirmed vulnerability must stop at the point that demonstrates impact, and any data accessed must be limited to the minimum needed as evidence.
• Source addresses: The vendor must provide the fixed IP addresses that testing will originate from, so they can be allowlisted and distinguished from real attacks in monitoring.
• Credentials and access: The Organization will provision test accounts for each role within five business days of kickoff. The vendor must confirm receipt and report any access problems within one business day.
• Communication: A named engagement lead on each side, a shared channel (email, Slack or the vendor's portal) for status updates, and a kickoff call and a closing readout.
• Critical findings: Any finding rated Critical, and any evidence of an existing compromise, must be reported to the Organization's engagement lead within 24 hours of confirmation, with interim remediation advice.
• Stop conditions: The Organization may pause or stop testing at any time. The vendor must stop immediately on instruction and on any sign of service degradation.
• Data handling: All evidence, credentials and data obtained during testing must be stored encrypted, accessed only by the named testers, and securely deleted within 30 days of final report acceptance, with written confirmation.
• Third-party platforms: Testing of assets hosted by cloud or SaaS providers must follow the provider's penetration testing policy. The vendor is responsible for confirming the rules for each platform in scope before testing starts.
• Cleanup: All accounts, web shells, implants, scheduled tasks and test data created during the engagement must be removed at the end of testing and listed in the report.

5. Deliverables and reporting

The following deliverables are required. Proposals must include a redacted sample report from a comparable engagement so the Organization can judge the reporting standard before award.

• Technical report: Executive summary; scope, dates, testers and the methodology actually used; a findings table sorted by severity; for each finding the affected asset, CVSS score and rating, description, evidence and proof of concept, reproduction steps, business impact and specific remediation guidance; the tests performed without findings; and the cleanup record.
• Executive summary: A standalone two to four page document for leadership and the board that explains the risk posture, the highest-impact findings in plain language and the recommended priorities, without technical reproduction detail.
• Attestation letter: A signed letter on the provider's letterhead confirming the scope, dates, methodology, the testers involved and the result, suitable for sharing with auditors, customers and partners. The letter must be reissued after retesting to reflect the remediated state.
• Retest report: The status of every original finding after remediation (fixed, partially fixed, not fixed, risk accepted) with new evidence for each.
• Findings export: All findings in a machine-readable format (CSV or JSON) in addition to the report, so they can be loaded into the Organization's tracking tools.
• Reporting timeline: The draft report within five business days of testing completion and the final report within five business days of the Organization's comments.

Retest policy: one retest of all findings within 60 days of the final report, included in the fixed price. Every retest must record the status of each original finding with new evidence.

6. Timeline and milestones

Vendors must confirm that they can meet these dates or propose alternatives with their reasons. Capacity to start on the target date is an evaluation criterion.

7. Vendor requirements and evaluation criteria

Mandatory requirements (pass/fail)

• The vendor must hold a current CREST accreditation for penetration testing services at the company level, not only individual CREST certifications, and must provide the details needed to verify it in the CREST member directory.
• All testing must be performed by the vendor's own employees. Subcontracting or the use of freelance testers is not permitted without the Organization's prior written approval.
• The proposal must name the penetration testers who will perform the work, with their certifications, years of experience, relevant published research or CVEs, and confirmation that the same people will deliver the engagement.
• A mutual non-disclosure agreement must be executed before detailed scoping information is shared. Vendors must accept the Organization's NDA or submit their own for review with the proposal.
• The vendor must accept the rules of engagement in Section 4 and the minimum methodology requirements in Section 3, or state each requested exception in the proposal.

Weighted evaluation criteria

Each criterion is scored 0 to 5 by every evaluator, multiplied by its weight and averaged across evaluators. Proposals that fail any mandatory requirement are not scored. The Organization may request a clarification call, or a short paid pilot on one asset, before award.

8. Pricing and commercial terms

Proposals must present pricing in the following format, as a fixed price per scope item. Time-and-materials pricing will only be considered with a stated day rate, a definition of what a day covers and a not-to-exceed cap.

• Retest policy: One retest of all findings within 60 days of the final report, included in the fixed price. State whether retests are included in the fixed price and the price of any additional retest.
• Continuous option: In addition to the one-time price, provide a price for a 12-month continuous program covering the same scope, billed monthly or annually, and describe what each cycle includes.
• Price validity: Prices must remain valid for at least 90 days from the proposal due date.
• Payment terms: State the proposed terms. The Organization's standard is [net 30 days from invoice, invoiced on delivery of the final report].
• Currency and taxes: All prices in USD [or state the required currency], excluding applicable taxes.
• Change control: Describe how scope changes discovered during testing are priced and approved, and confirm that no additional charges apply without the Organization's written approval.
• Guarantees and service levels: State any result-based guarantee, the committed report delivery dates, the Critical finding notification time, and the remedy if a commitment is missed.

9. Questions for vendors

Answer each question in the order given, in the proposal or in an appendix. Answers are scored against the criteria in Section 7.

1. Who exactly will perform the testing? Name the penetration testers, their certifications and years of experience, and confirm whether they are employees or subcontractors.
2. What share of the effort is manual testing versus automated scanning for this scope, and which tools, including any AI agents, are used in each phase?
3. How do you find business logic, authorization and access control flaws that scanners miss? Give two anonymized examples from engagements of similar scope.
4. Provide a redacted sample report for a comparable engagement. How are severity, business impact and remediation guidance presented, and how do you show what was tested without findings?
5. Confirm that your company holds a firm-level CREST accreditation for penetration testing services, and provide the details needed to verify it in the CREST member directory.
6. How many CVEs or public vulnerability disclosures have your testers published, and where can we review your research?
7. How do you communicate during testing? Describe how and when we learn about Critical findings, and whether findings are visible in a portal as they are confirmed.
8. What is included in retesting, how quickly is a retest turned around after we report a fix, and what does an additional retest cost?
9. How do you scope and price this engagement: fixed price per scope item, or time and materials? What assumptions drive the price, and what would change it?
10. Where are our data, evidence and reports stored, who can access them, when are they deleted, and in which countries are your testers and systems located?
11. If you find no High or Critical vulnerabilities, how do you demonstrate coverage, and do you offer any guarantee tied to the result?
12. Describe your continuous testing option: cadence, how new releases are tested, how findings are delivered between cycles, and how pricing differs from a one-time test.
13. Provide three references from clients with comparable scope in the last 18 months, and state your professional indemnity and cyber liability coverage levels.

10. Submission instructions

• Deadline and address: Submit proposals by [proposal due date] to [contact email] with the subject line "RFP response: penetration testing services".
• Questions: Questions may be submitted until [one week before proposals are due] to the same address. Answers will be shared with every invited vendor.
• Format: PDF, no more than 25 pages excluding appendices, structured to follow Sections 2 to 9 of this RFP.
• Required attachments: the completed pricing table from Section 8, a redacted sample report, tester biographies and certifications for the named testers, CREST accreditation details, three client references and a signed confirmation of acceptance of the rules of engagement in Section 4.
• Evaluation: Proposals are scored against Section 7. Shortlisted vendors may be invited to a 45-minute clarification call. The Organization expects to select a vendor within two weeks of the proposal due date.
• Conditions: The Organization is not obliged to accept the lowest-priced or any proposal, and will not reimburse costs incurred in preparing a response.
• Confidentiality: This RFP and any information shared during the process are confidential and may be used only to prepare a response.