How to Write a Penetration Testing RFP

Q: What should a penetration testing RFP include?

A penetration testing RFP should include: a clear scope definition (systems, applications, IP ranges in scope and explicitly out of scope), test methodology (black box, gray box, or white box), rules of engagement (authorized hours, emergency contacts, data handling), deliverable requirements (executive summary, attack narrative, per-finding remediation steps), re-test terms, and vendor qualification questions covering certifications, methodology, sample reports, and breach history.

Q: How do rules of engagement protect my organization during a penetration test?

Rules of engagement are the written agreement that defines what testers are authorized to do, when they can do it, and how to handle unexpected events. They protect your organization by establishing legal authorization (preventing accidental computer fraud violations), setting hours during which active exploitation may occur, requiring testers to halt immediately if they discover evidence of an active third-party breach, and specifying how any sensitive data encountered must be handled and destroyed after the engagement.

Q: Should a penetration test RFP require a re-test?

Yes. A re-test — also called a remediation verification — is where you confirm that critical and high findings were actually fixed, not just marked resolved. RFPs should require that at least one targeted re-test is included in the base price, covering all critical and high findings within 60 to 90 days of the final report. Without a re-test, you have no independent verification that your fixes worked, which undermines the value of the original engagement and limits your ability to document remediation for insurance or compliance purposes.

Back to Blog

To write a penetration testing RFP, you need six core sections: a precise scope definition that specifies what's in and what's out, test methodology (black, gray, or white box), rules of engagement, deliverable requirements, re-test terms, and vendor qualification questions that go beyond credentials. Most RFPs fail not because they're missing sections, but because the sections they include are too vague to generate comparable responses — and vague RFPs attract commodity vendors who compete on price rather than quality.

If your organization is going through a formal procurement process for penetration testing — whether to satisfy a compliance requirement, appease a cyber insurance carrier, or make a defensible selection between competing firms — the quality of your RFP determines the quality of the engagement before a single test is run. A poorly scoped RFP produces useless proposals. A well-structured one gives you the information you need to evaluate vendors on methodology, not marketing.

This guide walks through each section of a pen test RFP in the order they should appear, with specific language recommendations and the vendor responses that should raise or lower your confidence.

Section 1: Scope Definition

Scope is the single most important section in any penetration testing RFP. It is also where most procurement documents fall apart. Vague scope language — "our network," "our web applications," "our infrastructure" — invites vendors to either underestimate the work (and underprice), overestimate it (and overprice), or define it themselves in the proposal (which makes comparison impossible).

Effective scope language specifies:

IP ranges and subnet blocks in scope. List every CIDR block or specific IP range you want tested. If some segments are out of scope (SCADA systems, production databases, third-party-managed infrastructure), say so explicitly.
Applications in scope. Name specific applications and whether you want black-box (unauthenticated) or authenticated testing. "Web application testing" is not a scope; "authenticated testing of the customer portal at portal.company.com, including the admin interface" is.
Physical and cloud assets. If you have cloud workloads (AWS, Azure, GCP), specify the account IDs and regions. If physical security testing is in scope, say so — social engineering, tailgating, and physical lock testing require separate permissions and are often priced separately.
What is explicitly excluded. Production databases containing live customer PII, third-party SaaS environments you don't control, assets owned by subsidiaries not party to the engagement. Explicit exclusions protect you legally and operationally.

Include a table in the RFP with columns for Asset Type, Asset Name/Range, In Scope (Y/N), and Notes. Ask vendors to return this table with their proposal to confirm they understood the scope as you intended it. Discrepancies between proposals often trace back to scope interpretation differences, not pricing philosophy.

Section 2: Test Methodology — Black, Gray, or White Box

Your RFP must specify the knowledge model for the engagement. These three options have meaningfully different implications for cost, realism, and coverage:

Black Box

The tester begins with no prior knowledge of your environment — just a domain name or IP range. This most closely simulates an external attacker with no insider information. It's realistic but expensive per finding discovered, because testers spend significant time on reconnaissance that might not surface actionable vulnerabilities. Best for: organizations that primarily want to understand their external attack surface.

Gray Box

The tester receives partial information — network architecture diagrams, a standard user account, or a list of key systems. This simulates an insider threat, a compromised vendor credential, or a phishing victim scenario. Gray box is the most common methodology for SMB engagements because it balances realism with cost efficiency. Time isn't wasted on reconnaissance that obscures more interesting attack paths deeper in the environment.

White Box

The tester receives full documentation: network diagrams, system configurations, source code access where applicable, and administrative credentials. This produces the most thorough assessment and is the most cost-efficient for finding a high volume of findings, but it does not simulate real-world adversary conditions. Best for: code reviews, compliance-driven assessments where completeness matters more than realism, and organizations with mature security programs that have already passed gray-box assessments.

Your RFP should specify which methodology you want, or ask vendors to recommend one with justification. A vendor who recommends black box for everything regardless of your situation is optimizing for their billable hours, not your risk reduction.

Section 3: Rules of Engagement

Rules of engagement (ROE) are the written constraints that govern how testing is conducted. They are not bureaucratic paperwork — they are what separates an authorized security assessment from a criminal computer intrusion under statutes like the Computer Fraud and Abuse Act. Your RFP should define:

Testing windows. Active exploitation during business hours can cause service disruptions. Many organizations authorize reconnaissance and scanning during business hours but limit active exploitation to nights and weekends. Specify your preference and ask vendors to confirm they can work within it.
Emergency contact protocol. If the tester discovers evidence of a live, ongoing breach by a third party, what happens? They should halt, document, and contact a named individual immediately. Your RFP should include a field for your emergency security contact with 24/7 availability during the engagement period.
Data handling. What happens to sensitive data the tester encounters? Credentials, personal records, financial data. The ROE should specify that testers document only what's necessary to demonstrate a finding, do not retain copies, and confirm destruction of any sensitive data at engagement close.
Denial-of-service conditions. Most RFPs should explicitly prohibit active DoS or destructive exploits against production systems unless the organization has a redundant test environment and explicitly authorizes it.
Authorization letter. Require vendors to prepare and sign a letter of authorization that you countersign before any testing begins. This is your legal protection — it confirms the testing is authorized and scoped to the specific assets listed.

Section 4: Deliverable Requirements

This is where many RFPs are weakest. "Final report" is not a deliverable specification. Ask vendors to commit to the following in writing:

Executive Summary

A non-technical summary of findings, risk posture, and priority actions written for a business executive with no security background. Ask vendors for a sample executive summary from a previous engagement (redacted). This tells you more about their communication quality than any marketing copy.

Attack Narrative

A chronological account of what the tester did, what they found, and how far they got. This is the section that separates pentesters from vulnerability scanners. A narrative that reads "we used Nessus to identify 47 CVEs" is a scanner report. A narrative that reads "starting with no credentials, we exploited a misconfigured web service to obtain domain user credentials, then used those credentials to move laterally to the finance server" demonstrates actual manual testing.

Per-Finding Detail

Each finding should include: vulnerability name, CVSS score and version, affected asset, proof of exploitation (screenshots or command output), business impact in plain language, and specific remediation steps — not "apply vendor patches," but the actual configuration change, Group Policy path, or code fix. Request that all findings include a risk rating that accounts for your environment's exploitability, not just the theoretical CVSS score.

Remediation Tracking Format

Ask whether findings will be delivered in a format that supports remediation tracking — ideally a spreadsheet or CSV alongside the PDF report, with columns for finding ID, severity, affected asset, assigned owner, target remediation date, and status. This eliminates the step of manually extracting findings from a PDF into a tracking system.

Section 5: Re-Test Terms

A penetration test without a re-test is an incomplete engagement. The original test tells you what's broken. The re-test confirms you actually fixed it. Your RFP should require:

At least one included re-test covering all critical and high findings, delivered within 60 to 90 days of the final report at no additional cost.
Re-test scope. The re-test should target only the specific findings from the original engagement, not a full re-engagement of the entire scope. This keeps it cost-effective while still providing verification.
Re-test deliverable. A short addendum report (5-10 pages) confirming which findings were remediated, which remain open, and any new findings introduced during the remediation process (common when patches or configuration changes create new issues).
Insurance and compliance documentation. Ask whether the re-test addendum can be formatted to satisfy your specific compliance framework (SOC 2, PCI DSS, HIPAA, etc.) or submitted to your insurance carrier as evidence of remediation. Vendors who have done this before know exactly what format auditors want.

Section 6: Vendor Qualification Questions

This section separates the legitimate firms from the ones who bought a Nessus license and called themselves pentesters. Ask every vendor to respond to the following in writing:

Describe the certifications held by the specific testers who will conduct this engagement.

The proposal lists company-level certifications or general staff credentials without naming the testers.

The proposal names the specific individuals, lists OSCP, OSEP, GPEN, or CREST, and confirms they'll be conducting the work personally.

Provide a sample report from a previous engagement of similar scope (redacted).

The vendor declines or provides a template with no real findings, or the sample is clearly a scanner output dump.

The sample includes an executive summary a business leader can read, an attack narrative, and per-finding remediation steps specific to the environment tested.

What percentage of your findings typically come from automated scanning versus manual exploitation?

Any answer close to "most of our findings come from our scanning toolset." Automated scanning should be an enumeration tool, not the testing methodology.

A thoughtful answer acknowledging that scanning identifies targets but manual exploitation validates real risk and often finds logic flaws, chained vulnerabilities, and business context issues that no scanner reaches.

Describe your process for handling a critical finding discovered mid-engagement — specifically one that suggests an active third-party breach.

A vague answer, or one that says "we'd include it in the final report." Active breach evidence requires immediate notification, not a scheduled deliverable.

A specific protocol: halt active exploitation, document the evidence without disturbing it, call the named emergency contact immediately, and agree on next steps before resuming testing.

Has your firm or any of its employees been the subject of a security breach, data incident, or regulatory action in the past three years?

Evasive answers, refusal to disclose, or no professional liability insurance coverage.

Direct disclosure with context (if applicable), plus confirmation of current E&O and cyber liability coverage with limits appropriate to the engagement size.

Evaluation: What Proposals Tell You

The RFP process itself is a quality signal. Observe how vendors behave before the contract is signed:

Signals of a Weak Vendor

Sends a generic proposal with no evidence they read your RFP
Can't name the testers assigned to your engagement
Declines to provide a sample report
Prices are suspiciously low with no scope clarification questions
Methodology section reads like marketing copy
No professional liability or cyber insurance disclosed
Pushes back on re-test requirements

Signals of a Capable Vendor

Asks clarifying questions before pricing
Names specific testers with verifiable credentials
Provides a redacted sample report you can actually read
Explains their methodology in plain language
Confirms ROE and authorization letter process
Includes re-test in base proposal without being asked
Has clear escalation protocol for critical findings

A good vendor will ask you questions before they submit a proposal. They'll want to understand your compliance requirements, your IT team's capacity to remediate findings quickly, whether you've had a previous pentest and what the results were, and whether you have any known sensitive assets that need special handling. If a vendor submits a proposal in 24 hours with no questions asked, that's a red flag — it means the proposal was built from a template, not from an understanding of your environment.

Once you've selected a vendor based on proposal quality, treat the pre-engagement call as a second evaluation. Ask the tester — not the sales rep — to walk you through their planned approach for your specific scope. A competent tester will have a hypothesis. They'll tell you where they expect to find the most risk based on your industry and architecture. That level of preparation before testing starts is what separates a thorough engagement from a compliance checkbox.

For more on what the final deliverable should look like once you've selected a vendor, see our guide to what a penetration test report should actually contain. And if you're early in the decision-making process and haven't yet determined whether a full pentest is appropriate for your organization, our primer on penetration testing versus vulnerability scanning may help clarify which engagement type fits your current needs.

Frequently Asked Questions

What should a penetration testing RFP include?

A penetration testing RFP should include: a precise scope definition (systems, applications, and IP ranges in scope and explicitly out of scope), test methodology (black box, gray box, or white box), rules of engagement (authorized hours, emergency contacts, data handling), deliverable requirements (executive summary, attack narrative, per-finding remediation steps), re-test terms, and vendor qualification questions covering certifications, methodology, sample reports, and incident disclosure.

What is the difference between black box, gray box, and white box penetration testing?

Black box testing gives the tester no prior knowledge of your environment, simulating an external attacker. Gray box provides partial information — such as network diagrams or a standard user account — simulating an insider threat or compromised credential scenario. White box testing gives full documentation and credentials, allowing the most thorough and efficient coverage. Most SMB engagements use gray box because it balances realism with cost efficiency.

How do rules of engagement protect my organization during a penetration test?

Rules of engagement establish legal authorization, define testing windows, specify emergency escalation procedures, and govern how sensitive data encountered during testing is handled and destroyed. Without them, an authorized test can inadvertently create legal ambiguity, operational disruption, or data handling liability. They are the document that turns "someone attacking your network" into "an authorized security assessment."

Should a penetration test RFP require a re-test?

Yes. A re-test confirms that critical and high findings were actually remediated, not just marked closed. RFPs should require at least one targeted re-test included in the base price, covering all critical and high findings within 60 to 90 days of the final report. Without it, you have no independent verification that your fixes worked — which limits the value of the original engagement and weakens your documentation for insurance or compliance purposes.

What certifications should a penetration testing vendor have?

Look for OSCP (Offensive Security Certified Professional) as the practical baseline — it requires passing a 24-hour live exploitation exam, not a multiple-choice test. OSEP, OSED, and OSWE indicate advanced specialization. GPEN and GWAPT are well-regarded. For high-compliance environments, ask about CREST or CHECK accreditation. Be cautious of vendors whose only credentials are CompTIA Security+ or CEH, which are knowledge-based exams with no practical exploitation component.

Ready to Scope Your Penetration Test?

We'll walk you through the scoping process, answer your methodology questions, and tell you exactly what to expect — before you commit to anything.

Book a Scoping Call

How to Write a Penetration Testing RFP: What to Include and Why