Penetration Testing RFP and SOW Template: Scope, Evidence and Retesting

Last updated: November 4, 2026.

A penetration testing RFP should make vendors price and deliver the same security task. If the request lists only domains and dates, proposals will differ in authentication, business-logic depth, production safety, reporting and retesting. Those differences make price comparisons misleading.

Use the following structure as a procurement starting point. Legal, privacy, compliance and insurance language should be reviewed by the organization’s responsible teams.

For the assessment framework, consult NIST SP 800-115 and map the relevant guidance to the actual environment and authorized scope.

RFP scope fields

Provide enough information for a defensible estimate without sending secrets in the procurement document.

Vendor response requirements

Ask the vendor to explain methodology, assigned roles, automated and manual coverage, evidence handling, escalation, expected customer effort and important exclusions. Require assumptions behind price and duration.

• Relevant experience without requesting confidential customer details.
• Named methodology and how it adapts to the supplied architecture.
• How authentication, multi-role and business-logic testing are handled.
• Production safety, rate control and emergency contact process.
• Report sample or redacted structure, evidence format and severity method.
• Retest scope, timing, closure states and additional fees.

Statement of work acceptance criteria

The SOW should name authorized targets, dates, contacts, prohibited actions, third-party boundaries, data handling, communication cadence and deliverable dates. Acceptance should depend on completion of the agreed scope and usable evidence, not on finding a minimum number of vulnerabilities.

Reusable procurement checklist

1. Confirm asset and identity owners.
2. Approve rules of engagement and stop conditions.
3. Provision test credentials and synthetic data.
4. Confirm reporting and evidence expectations.
5. Set remediation and retest dates.
6. Record final scope changes and limitations.

Questions buyers should ask

• Are all vendors pricing the same roles, workflows and environments?
• Does the proposal state what is excluded?
• Are evidence handling and production safety contractual?
• Is retesting included with explicit closure criteria?

Conclusión

A good RFP converts security objectives into comparable scope and evidence. Keep one procurement package for RFP, proposal and SOW variants, and make authorization, safety, reporting and retesting explicit before work begins.

Sources and standards

• NIST SP 800-115
• Guía de pruebas de seguridad web OWASP
• CISA Secure by Design