How to Write a Penetration Testing RFP (with Checklist)

What an RFP is for

The United States Federal Acquisition Regulation (FAR) describes the purpose well: "Requests for proposals (RFPs) are used in negotiated acquisitions to communicate Government requirements to prospective contractors and to solicit proposals." It goes on to say an RFP for a competitive acquisition should, at a minimum, describe the requirement, the anticipated terms and conditions, the "Information required to be in the offeror's proposal" and the "Factors and significant subfactors that will be used to evaluate the proposal and their relative importance."

Those four elements work for private buyers too. For a penetration test they translate into a clear scope, the constraints and terms testers work under, a fixed response format, and evaluation criteria bidders can see in advance. Get those right and the responses become comparable. Leave them vague and every bidder quotes a different engagement.

Describe the result, not the hours

The FAR's guidance on performance-based work tells agencies, to the maximum extent practicable, to "Describe the work in terms of the required results rather than either 'how' the work is to be accomplished or the number of hours to be provided."

That is good advice for a penetration test. "Five days of web application testing" says nothing about what you need to know. "Determine whether one customer can reach another customer's data through the application or its application programming interface (API), and whether an unauthenticated user can reach any customer data at all" gives bidders something to estimate against, and gives you something to hold the result to.

What to include

Background and objectives

Start with what the system does and why it is being tested now: a new release, a customer security review, an audit, an acquisition. Then state the questions the test must answer. A good bidder will tell you if a smaller or different engagement would answer them better.

Scope

Be specific. List each application, network, cloud account or API in scope, with enough detail to estimate the work: the number of user roles, tenants, hosts or environments. List exclusions just as clearly.

The National Institute of Standards and Technology (NIST) makes the same point about test planning. Its guide says the assessment plan "should identify which systems and networks are authorized to be examined and tested," should list systems that are not authorized, and notes that where systems sit on a third party's network, "the owner of the other network usually must also consent in writing to the assessment plan." Flag any cloud or hosting provider in the RFP so bidders can account for it.

If you are unsure where the boundaries should be, it is reasonable to say so in the RFP and ask bidders how they would scope it. Red Cell can help define the scope before you issue one.

Constraints

Name the testing windows, any systems that cannot tolerate load, production limits and anything you do not want done at all. The PCI Security Standards Council's penetration testing guidance lists questions the rules of engagement typically settle, including "During what time window will testing need to be performed?" and "What steps will be taken if the tester detects a previous or active compromise to systems being tested?" Raising them in the RFP means bidders price them in. Our guide to rules of engagement covers the rest.

Access and documentation

Say what you will provide: test accounts for each role, API documentation, architecture notes, source code. The same PCI Security Standards Council guidance recommends that "Whenever possible, detailed documentation of any components within the scope should be made available to the tester." More starting knowledge usually means more coverage in the same time.

Deliverables

Describe the report you need. The PCI Security Standards Council's guidance is direct on this: "Merely reporting lists of vulnerabilities is not helpful in this endeavor and does not meet the intent of the penetration test." It also says "The report should clearly document how the severity/risk ranking is derived." Ask for an executive summary, technical findings with evidence and reproduction steps, remediation guidance, and a stated severity method. How to read a penetration testing report explains what good looks like.

Retest terms

Ask how many retest cycles are included, which findings qualify and how long the window stays open. Retest terms are where otherwise similar proposals differ most, and the difference is easy to miss in a total price.

Compliance evidence

If the report must satisfy an assessor or a customer's security review, name the framework and the reviewer. Testing can support compliance evidence and customer assurance requirements. Scope and evidence mapping depend on the applicable requirements, so this belongs in the RFP, not in a request after the report arrives.

Response format and evaluation criteria

Ask every bidder the same questions in the same order, and say how you will weigh them. Ask who will do the work and what experience they have with your technology. The PCI Security Standards Council's guidance notes that "Appropriate penetration testing experience and qualifications cannot be met by certifications alone," and suggests asking: "Has the penetration tester performed assessments against organizations of similar size and scope?" Ask for a sample or redacted report.

The checklist

Copy this into your RFP or use it to review a draft before it goes out:

After the RFP

Once you choose a provider, the RFP becomes the starting point for three documents: a statement of work (SOW) that fixes scope, deliverables, retest terms and fee; rules of engagement that fix the window, intensity, escalation contacts and stop conditions; and written authorization naming the specific systems. Our approach page describes each one.

Price follows from the scope you describe. What drives penetration testing cost explains the drivers, and our pricing page publishes Red Cell's starting prices, each reflecting a defined scope. To send an RFP or talk through a scope first, get in touch.

Sources

1. 01Federal Acquisition Regulation, 15.203 Requests for proposalsAccessed 2026-09-26
2. 02Federal Acquisition Regulation, 37.602 Performance work statementAccessed 2026-09-26
3. 03NIST, Special Publication 800-115, Technical Guide to Information Security Testing and Assessment (PDF)Accessed 2026-09-26
4. 04PCI Security Standards Council, Information Supplement: Penetration Testing Guidance, version 1.1 (September 2017)Accessed 2026-09-26