How to Write a Penetration Testing RFP in 2026: Template and Key Requirements

You budgeted $50k for penetration testing. The vendor delivers a 200-page PDF of low-severity findings your scanners already caught, charges $15k for retesting, and misses a critical auth bypass that surfaces on Twitter three months later. This happens because most RFPs never ask the right questions.

Modern applications deploy continuously across microservices and APIs. Traditional annual testing cannot keep pace. You need vendors who can test distributed systems, construct multi-step attack chains, and provide continuous validation, not compliance theater.

This guide gives you a complete RFP structure with specific requirements for evaluating modern pentesting: code-aware methodology, performance-based pricing, and deliverables developers can actually use. You will learn how to scope complex environments, evaluate vendor depth, and structure a contract that aligns with security outcomes rather than page count.

Where this connects: an RFP decides who you hire. The contract clauses decide what they actually test once hired. This guide covers the first half. Pair it with the contract guide for the second.

Pre-RFP Alignment: The Internal Decisions Vendors Cannot Price Around

The most common failure mode is a three-way disconnect: security wants depth, procurement wants a fixed price, and engineering wants minimal disruption. These are not incompatible, but they need explicit decisions before any vendor proposes.

Define your primary objective

Pick one. You cannot optimize for all three at once, and a vendor priced for one will underdeliver on the others.

• Compliance-focused testing. Goal: audit evidence for SOC 2, ISO 27001, PCI DSS, or HIPAA. Scope: external systems, black box. Timeline: annual or semi-annual. The cost driver is report quality and auditor acceptance.

• Risk-reduction testing. Goal: find exploitable vulnerabilities before attackers do. Scope: full stack, authenticated workflows, business logic. Timeline: quarterly or continuous. The cost driver is exploitation depth and attack-chain construction.

• Pre-launch validation. Goal: validate a new feature before release. Scope: a specific feature set, time-boxed. Timeline: sprint-aligned, one-to-two-week turnaround. The cost driver is speed and availability.

Map your technical constraints

Document the operational reality in the RFP so vendors price against facts, not assumptions.

• Production testing windows: approved hours, blackout periods, rate-limit thresholds, acceptable performance impact, rollback procedures.

• Environment access: is production testing allowed, does staging mirror production, is test data synthetic or anonymized.

• Authentication: test accounts per role, MFA handling (bypass or static TOTP seeds), API authentication (OAuth flows, JWT tokens).

A concrete constraint statement removes more ambiguity than a page of prose:

Assign remediation ownership before you issue the RFP

Decide who triages findings, who implements fixes, and what the timeline expectations are (critical in 7 days, high in 30). Settle the retesting logistics too: unlimited retesting or a per-fix charge, turnaround (24 to 48 hours vs a week), and whether you want continuous testing or quarterly re-scans. A finding with no owner and no retest path is a finding that ages into next year's audit.

The Essential RFP Components

A strong RFP has eight sections. The detail level in each is what separates a real proposal from a boilerplate one.

1. Company background and context. A brief overview of your organization, industry, regulatory environment, and why you are issuing this RFP (compliance requirement, incident response, maturity improvement).

2. Objectives and success criteria. Specific goals beyond "find vulnerabilities": validate SOC 2 controls, test a new API platform, assess cloud-migration security. Define measurable success criteria.

3. In-scope assets and testing boundaries. This needs real specificity: domains and subdomains, web applications, APIs (REST endpoints, GraphQL schemas, gRPC services, webhooks), mobile apps with version numbers, cloud accounts and specific services (ECS, Lambda, S3, RDS), and CI/CD (GitHub Actions, GitLab CI, Jenkins). A usable scope line reads like "Customer portal (React/Node.js), 47 REST endpoints, 12 GraphQL mutations, AWS (ECS, RDS, S3), Auth0 SSO, 3 user roles."

4. Out-of-scope items. The systems, networks, and third-party services to avoid, plus prohibited techniques (DoS, social engineering). This is what prevents scope creep mid-engagement.

5. Testing approach and methodology. Specify the testing mode explicitly.

The emerging standard is code-aware gray box: the vendor analyzes your codebase to understand routing, authentication middleware, and data flows, then conducts adversarial testing with that inside knowledge. It finds what external-only testing misses. We break the three modes down in Black Box vs White Box vs Gray Box Penetration Testing.

6. Deliverables and report requirements. For each finding, require a CVSS v3.1 score with vector string, a working proof-of-concept exploit, file-and-line remediation, a business-impact explanation, and compliance mapping.

7. Retest policy. State it in the RFP, do not leave it to the SOW.

8. Pricing model and terms. Name the model you want (fixed-price, time-and-materials, retainer, or performance-based) and force the hidden costs into the open: retesting fees, travel and on-site expenses, tool-licensing pass-through, and a change-order cap (say 20%) without re-bidding.

Scope: Defining the Modern Attack Surface

Precise scope is what determines whether you get shallow scanning or deep testing. Two worked examples show the level of detail to aim for.

A SaaS web app plus REST API:

Microservices behind an API gateway:

Methodology: Separating Deep Testing From Scanner Output

The methodology section is where you filter out the vendors who will hand you scanner output with a logo on it.

• Anchor on PTES and OWASP WSTG. Require the vendor to map their methodology to the seven phases of the Penetration Testing Execution Standard (PTES): pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. For web apps, require coverage across the OWASP Web Security Testing Guide (WSTG) categories.

• Require attack-chain construction. The defining trait of professional pentesting is chaining multiple issues into a working exploit that demonstrates real business impact, not a flat list of isolated findings.

• Require business logic and authorization testing. These are exactly the flaws automated scanners cannot reason about, so make them explicit RFP questions: how the vendor tests business logic (price manipulation, workflow bypass, race conditions), how they test Broken Object Level Authorization and IDOR across APIs, and an example of an authorization flaw they found that required understanding the application's data model and role structure.

  

• Require a code-aware explanation. If you are giving source access, make the vendor earn it by explaining how they use it: tracing data flows, identifying authentication and authorization middleware, discovering undocumented endpoints, and understanding business logic implementation, with examples of vulnerabilities found through code analysis that external-only testing would have missed.

Deliverables: What an Audit-Grade Report Actually Contains

Split the report for two audiences. The executive summary carries business impact, compliance-control violations, aggregate risk, and a remediation timeline. The engineering appendix carries file-and-line code references, reproducible PoC exploits, CVSS scores with justification, step-by-step remediation with code, and verification steps.

Per finding, insist on all five of these. A reproducible PoC:

# Broken Object Level Authorization
curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 200 OK with user 742's data (should be 403 Forbidden)

# Broken Object Level Authorization
curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 200 OK with user 742's data (should be 403 Forbidden)

# Broken Object Level Authorization
curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 200 OK with user 742's data (should be 403 Forbidden)

A CVSS v3.1 score with its vector, so the severity is auditable rather than asserted:

Code-level remediation that shows the fix, not just the flaw:

# Before (vulnerable)
def get_profile(user_id):
    return User.query.get(user_id)

# After (secure)
def get_profile(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        abort(403)
    return User.query.get(user_id)

# Before (vulnerable)
def get_profile(user_id):
    return User.query.get(user_id)

# After (secure)
def get_profile(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        abort(403)
    return User.query.get(user_id)

# Before (vulnerable)
def get_profile(user_id):
    return User.query.get(user_id)

# After (secure)
def get_profile(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        abort(403)
    return User.query.get(user_id)

And a verification step so your team can confirm the fix closed the issue:

curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 403 Forbidden

curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 403 Forbidden

curl -X GET 'https://api.example.com/users/742/profile' \
  -H 'Authorization: Bearer <user_123_token>'
# Expected: 403 Forbidden

Finally, require compliance mapping in the report itself, since assembling it afterward is what turns a clean test into a scramble before the audit.

Vendor Evaluation: A Weighted Scorecard

Score every proposal on the same weighted rubric so the decision is defensible, not a gut call.

The sample report is your single most useful evaluation artifact. In it, check that findings include PoC exploits with curl commands, that remediation is file-and-line specific, that findings map to compliance controls, and that there is a clear distinction between confirmed exploits and theoretical ones.

Red flags that should disqualify a vendor: vague scope acceptance with no clarifying questions, refusing to share a sample report, an inability to explain methodology beyond "proprietary techniques," pricing 40% below competitors (usually automated scanning only), and no retest policy or a per-retest charge.

Green flags worth weighting up: detailed tech-stack questions during scoping, unlimited retesting as standard, code-aware testing options, and performance-based pricing where you pay only for a confirmed working exploit.

2026-Specific Requirements: The Modern Attack Surface

A generic RFP template written five years ago misses most of what actually gets breached today. Add explicit requirements for four modern surfaces.

• API and microservices. Require GraphQL testing for Broken Object Level Authorization across every query and mutation, including query manipulation, field injection, and batching attacks, with the specific queries that retrieved unauthorized data. Require gRPC testing that analyzes .proto definitions to enumerate RPC methods and tests authorization on each. And require service-to-service testing that attempts to forge service identity tokens and bypass service-mesh policies to show lateral movement. The cloud pentesting guide and the hybrid attack-chain guide cover these paths in depth.

• Cloud identity and infrastructure. Require three things here: secrets scanning across repositories, container images, CI/CD pipelines, and cloud storage, cloud IAM testing that attempts privilege escalation from an application service account to admin, and CI/CD testing that reports the blast radius of a compromised pipeline.

• AI and LLM security. This is the newest gap in most templates. Require prompt-injection testing (both direct user input and indirect poisoned data sources), data-leakage testing for PII and secrets in model responses, and tool-abuse testing for LLMs with function-calling, showing how tool abuse chains into broader compromise. Be honest with yourself about scope here: many traditional firms have no LLM-testing capability at all, so if you run AI features, make it a named requirement rather than an assumption.

Pricing Models and the Contract Clauses That Protect You

Match the pricing model to your engagement shape. Fixed-price suits a well-bounded project but invites change orders on scope creep. Time-and-materials fits exploratory testing but has no efficiency incentive. A retainer buys ongoing capacity for frequent deployments. Performance-based, where you pay only for a confirmed exploitable vulnerability, aligns the vendor's incentives with your security outcome, provided you define "confirmed exploit" clearly.

Three contract clauses are worth insisting on regardless of model:

A Worked Example: A Filled-In Mini-RFP

Every section above is a rule. Here is what they look like assembled into one short, sendable RFP for a fictional SaaS company, Northwind Health, a HIPAA-regulated telehealth platform. Lift the structure, swap in your own specifics.

Notice what this does that a generic template does not: it names the objective and its priority order, enumerates the real surface down to endpoint and role counts, calls out the exact critical flows, ties deliverables to the specific compliance controls the auditor will ask for, and makes the working PoC a payment condition rather than a hope. A vendor who cannot answer this cleanly is a vendor who was going to send you scanner output.

Stop Buying Page Count. Buy Proof.

A good RFP is a filter. Written well, it attracts vendors who can test modern architecture and deliver findings your engineers can act on, and it screens out the ones who will send a 200-page scanner dump. Before you send it, make sure four things are non-negotiable: scope precision (enumerate the real surface, not "the application"), evidence-based deliverables (PoC exploits, CVSS with vectors, file-and-line remediation), methodology depth (attack chains, code-aware testing, unlimited retesting), and the 2026 requirements (API, microservices, cloud, and AI/LLM).

For teams deploying weekly or faster, there is a deeper point the RFP process surfaces: an annual engagement is a point-in-time answer to a continuously changing question. That is where CodeAnt AI fits. The same code intelligence that reviews your pull requests conducts the adversarial testing, so it tests from the outside with inside knowledge of your codebase, traces data flows, maps authentication middleware, and builds the attack chains external-only testing misses. Every finding lands with a working PoC and a file-and-line fix, retests are unlimited, and pricing is performance-based, you pay only when a high or critical is confirmed exploitable.

Where to start this week

Take your last pentest RFP (or the generic template you were about to send) and add three requirements to it: a mandatory working PoC for every critical and high finding, a required sample report before shortlisting, and an explicit AI/LLM testing clause if you ship AI features. Those three additions alone will screen out the scanner-only vendors before they ever reach your shortlist.

Run a free code-aware pentest →

Related reading

• SaaS Penetration Testing: The Contract Clauses That Decide What Gets Tested: the clause language for after you have chosen a vendor

• What Is VAPT? Vulnerability Assessment vs Penetration Testing: the distinction that shapes what you should even be asking for

• Automated Penetration Testing: why continuous validation is replacing the annual engagement

• Continuous vs Annual Penetration Testing: the cadence question every RFP implicitly answers

• Black Box vs White Box vs Gray Box Penetration Testing: which testing mode to specify in your RFP