Penetration testing RFP: template, scoring and what real RFPs leave out

By The PenTest Index · Public RFPs and guidance read October 10, 2026

A penetration testing RFP is a written request that gives every provider the same scope, rules and questions, so their proposals can be compared line by line. Copy the template below. You only need a full RFP if your purchasing rules require one or the job needs a formal, scored comparison. Otherwise a one-page quote request is faster.

We read 9 public penetration testing RFPs to see what buyers send out. None of the 9 stated user roles per application, an API count or a deadline for retesting. Only two stated a budget. The template is built to close those gaps before a provider has to ask.

If a short request is all you need, use our one-page quote request and skip the rest of this page.

Penetration testing RFP template

Copy this, fill in the brackets and send the same version to every provider. Where you don't know something, write "Unknown." Unknown is not zero, and a provider who has to guess will price the guess.

Three terms first. A penetration test (pentest) is a planned attempt to break into your own systems, inside agreed limits, to show what an attacker could do. A vulnerability scan is software that checks for known weaknesses. A retest is a second look that confirms your fixes worked.

Request for proposals: penetration testing

1. Summary and key dates

[Organization name] is asking for proposals for [one penetration test / a program of N tests over N months] of [short description of the systems]. Reference: [number and version].

Send proposals to [contact and channel]. Proposals must stay valid for [N] days.

2. Why we need the test and who will read the report

We need this test because [customer request / audit / internal goal / rule, with the exact source]. The report will be read by [customer, auditor, assessor, board, internal team], who will use it to [decision]. What they have asked for: [paste or attach their request]. What they have not yet confirmed: [open questions and who owns each].

A provider's general compliance claim is not confirmation from our report reader. Tell us plainly which of their requests your proposal covers.

3. Scope

Price the scope below as written. Give live counts, not the size of an address range.

Access we will provide: [test accounts, documentation, source code, a network connection, or none of these]. Access not ready yet: [what and by when].

The exact address list and other sensitive details will be shared with [shortlisted bidders / the selected provider] under a confidentiality agreement. They are not in this document.

4. Out of scope and limits

Do not test: [systems, outside services, techniques]. Testing hours: [days, hours, time zone]. Blackout dates: [ ]. Activities that need our approval first: [for example, anything that could interrupt a service].

5. How the work must be done

Automated scanning alone [is / is not] acceptable for this purchase. [Our report reader has / has not confirmed this.]

In your proposal, separate the work done by people from the work done by scanners or AI testing, and say who reviews the findings. State the effort in a unit we can check: days of human testing, hours, or credits with a definition of one credit.

6. Our requirements

Answer each line. Do not change its meaning.

Add or remove rows. "Assumed" means we have not confirmed it yet. Tell us if your proposal depends on it.

7. What we must receive

A written report that states what was tested and what was not, the dates, the methods, the limits, and each finding with evidence, a severity rating with its reasoning, and how to fix it. Also: [summary letter for customers / other deliverable].

With your proposal, send a sample report with client details removed, for work similar to this.

8. Retesting

We [do / do not] need fixes checked. If we do, tell us:

• how many rounds are included
• whether a person or a tool does the check, and what is rechecked
• the last date we can ask, and what starts that clock
• whether that date is a deadline to ask or a deadline to finish
• whether a contract end date can cut it short
• the price of any round beyond what is included
• whether we get an updated report

9. Budget

[The budget for this work is $N.] / [We expect proposals between $N and $N.] / [The budget is not disclosed.]

10. How we will choose

First we check every Mandatory line in section 6. A proposal that does not meet one, in writing, does not go forward unless it is revised. Then we compare the proposals that remain on: [your criteria in order, with weights that add up to 100 if your process uses them].

A blank answer is an unanswered question. It is not agreement.

11. Price form

Every bidder fills in the same table. Mark any required item you cannot price yet as "unpriced." Do not leave it blank.

Also state the minimum term, renewal terms, when unused credits expire, and what we owe if we reschedule or cancel.

12. Questions every bidder must answer

1. For each line in section 3, is it included, excluded or conditional? Where will you test everything and where will you sample?
2. Who will do the testing? Name the lead, describe the team's experience with systems like ours, and say whether any work is subcontracted.
3. How many days of human testing does your price buy?
4. Which published methods do you follow, and which version?
5. How do you tell us about a serious finding before the report is done?
6. What happens if you find signs of a real break-in during the test?
7. What are your dates for access, test start, test end and final report, and what does each depend on from us?
8. What would change the price or the dates, and how is a change approved?
9. Where will our data and your evidence be stored, who can see it, and when is it destroyed?
10. If you use AI services on our data, what is shared, with whom, how long is it kept, and is it used to train any model?
11. Where are your testers located?
12. What insurance do you carry, and with what limits?
13. Do you have any conflict of interest on this work, such as having built or managed the systems being tested?
14. Which of our requirements can you not meet, and what do you propose instead?
15. What have we left out that you need to know?

13. Terms and what this document is not

The selected provider will sign [our confidentiality agreement] before receiving sensitive details. Required insurance: [types and limits, set by your risk or legal team]. Data handling: [where data may be kept; destruction within N days of the final report]. Other terms: [tester location, subcontractors, background checks].

This RFP does not authorize testing. Before any testing, both sides must agree in writing on the exact targets, the permitted activities and the rules for the test, including any approval needed from a company that hosts or runs the systems.

Never put passwords, keys or customer data in this document.

What do real penetration testing RFPs leave out?

The details a provider needs to price a web application. None of the 9 public RFPs we read stated how many user roles to test or how many APIs were in scope, and none gave a deadline for retesting.

Here is what the 9 stated. They come from eight public bodies, because one utility appears twice.

And each one, row by row:

"Days to respond" is our count of calendar days from the issue date to the proposal deadline.

How we did this: we read each document on October 10, 2026 and recorded only what its text says. We did not contact the issuers or see the proposals they received. The sample is small, all public sector, and mostly network tests. Private companies often write shorter requests. Treat it as 9 real examples, not a survey of the market.

Even so, the pattern is useful. Most of these buyers counted their networks carefully and then said little about the things that move the price of an application test or decide whether a retest is still free when the fixes are ready.

What will providers ask if you leave it out?

They'll ask for counts, the budget and the retest terms, and you'll answer in writing while your deadline gets closer. The City of Memphis received 208 numbered questions on one RFP.

That RFP capped the networks at "not more than 100" public addresses and "not more than 5000" internal ones, but gave no count of web applications. Bidders asked for that number more than a dozen times. The answer was 10 applications and 3 APIs. They asked for the budget too, and were told it "can not be disclosed at this stage" (Memphis Addendum 2, read October 10, 2026).

What goes in the scope section?

Counts a provider can price from, plus the two things most RFPs skip: who can sign in, and what sits behind the website.

For each application, list the roles that see different things. An admin and a standard user are two roles. Twelve job titles with the same permissions are one. Then list each API and say whether it must be tested directly. Our scope brief walks through this field by field, with a filled-in example, and you can paste the result into section 3.

Is it safe to publish our IP ranges?

Put counts in the RFP and keep the list back. A count lets a provider price the job. The actual addresses, hostnames and diagrams can go to shortlisted bidders, or only to the winner, under a confidentiality agreement. If your organization is subject to public records rules, ask your procurement team what a published RFP exposes before you attach anything.

If you can't fill in the scope table yet, that is the thing to fix first. An RFP with blanks gets guesses priced into it. Find My PenTest Match walks you through the questions for your kind of system and gives you a scope checklist to copy or print. It is free and asks for no contact details. It does not pick a provider for you, and its compared offers are mostly web application and API tests.

Find My PenTest Match

Do you need a full RFP, or just a quote request?

Use a full RFP when a rule requires formal competition or you need a scored, documented choice. A private company with a known scope and two or three providers in mind can get the same comparison from a one-page request.

Two neighbors of the RFP are worth knowing. An RFI (request for information) asks providers what they can do before you have fixed what you're buying. An RFQ (request for quotation) asks for a price on work you have already defined. Many organizations use "RFP" for all of these, so follow your own purchasing rules on which document counts.

How do you score penetration testing proposals?

Check the must-haves first, pass or fail. Then compare what's left. A proposal that leaves out something you require is out, however good its price looks.

This is the same method we use across the site, which we call a Purchase Check. Each requirement gets one finding. Supported means the proposal's words cover it. Mismatch means the proposal says something that doesn't fit. Unresolved means it is silent or vague. Conflicting means two parts of it disagree. Supported is about that one line only. It says nothing about how good the testing will be.

Fictional example. Every requirement, proposal, date and price below is invented to show the method. These are not real quotes, market prices or opinions about any company. Amounts are US dollars before tax.

Say you run a 40-person software company. You want one test of your staging web app and its API, about 35 endpoints, covering the Member and Administrator roles and the wall between two test customer workspaces. Your customer needs the report by November 20, 2026. Your team will need about six weeks to fix what's found, so you must be able to ask for a retest 45 days after the findings are reported.

Offer B goes forward. It covers everything in writing and has a finished total.

Offer A is the lowest number on the page and it is for a smaller job. It fails two must-haves. It could come back in with a revised proposal, but its $4,800 would need to be confirmed for the revised scope.

Offer C might be fine. You can't tell yet. Its total is incomplete, and a missing required charge is not zero. Send this: "What is the required platform fee, and can we request a retest by a person 45 days after findings are reported? Please confirm both in writing."

If your process uses weighted scores, add them after this step, to the proposals still standing. Three of the RFPs we read published their weights. Cost counted for 30% in Memphis, 40% at the Maine Community College System and 15% at the Ontario Centre of Innovation. Those are three buyers' choices, not a standard. What matters is that a high score can't buy back a missed must-have.

Already holding proposals? Check each one against 12 lines before you sign.

Should you put your budget in the RFP?

Usually yes, or at least a range. It spares you a round of questions and keeps away proposals you could never accept.

Only two of the 9 RFPs we read stated a budget, and both came from the same utility. In 2023 the Greenville Utilities Commission wrote, "The budget for this project is $45,000.00," for a scope of 38 external addresses, 510 internal endpoint accounts, 233 servers and one business application. Its 2025 RFP gave the same figure for 22 external addresses, 510 internal accounts and 195 servers. That is one public body's stated budget, read October 10, 2026. It is not a price anyone paid and not a market rate.

If you can't name a figure, a ceiling works. If your rules forbid stating anything, write "the budget is not disclosed" in section 9 so nobody has to ask.

For prices providers publish themselves, see penetration testing cost.

How do you stop a scan being sold as a penetration test?

Say in the RFP whether scanning alone is acceptable, and make each bidder state how much of the work people do. Only three of the 9 RFPs we read ruled out scanning alone.

The ones that did were blunt. The Maine Community College System wrote that "fully automated pen-testing services will not be considered." The Village of Ossining wrote that "automated scanning alone is not permissible" and that findings must be checked by a tester. The other six did not explicitly rule out scanning alone.

There is published support for the distinction. The PCI Security Standards Council's guidance describes a penetration test as "a manual process that may include the use of vulnerability scanning or other automated tools" (Penetration Testing Guidance v1.1, September 2017, section 2.1). That document is supplemental guidance for card-payment environments. It is not a rule for every buyer.

So don't assume the answer. Whether an automated or AI-led test is enough depends on who reads your report. Ask them, write their answer into section 5, and let question 3 in section 12 do the rest. If you want the difference in more depth, read penetration testing vs vulnerability scanning.

Should the RFP require OSCP, CREST or other certifications?

Ask for named testers and their relevant experience first. A certificate is a useful signal. It is not proof that this team can test your systems.

Three of the 9 RFPs named certifications. The same PCI guidance lists several as examples, including OSCP, CEH, GIAC and CREST certifications. It adds that these "are not required certifications," that the Council does not validate or endorse them, and that experience "cannot be met by certifications alone" (sections 3.1 and 3.2). Its own example questions are better RFP material: how many years the tester has done this work, whether they have tested organizations of similar size, and what experience they have with the technologies you run.

One more point from that guidance is worth borrowing. It says the tester should be organizationally independent of whoever manages the systems being tested (section 3). That is why question 13 in the template asks about conflicts.

If you do make a listing mandatory, check it yourself on the issuing body's own list. A logo on a proposal is the provider's claim.

How long should providers get to respond?

The 9 RFPs we read gave between 15 and 72 days, with a median of 32. Two gave 15 days or fewer.

A short window is not wrong, but it only works if the RFP answers the obvious questions up front. Every question you have to answer in writing eats into it.

Work backward from the day you need the report. In this example the 32 days is the median above, and the other durations are placeholders you should replace with your own.

That is 76 days from sending the RFP to holding a report, before any fixing or retesting. If your reader needs proof that the fixes worked, add your fix time and the retest on top. And put the report date in the RFP. Two of the 9 gave bidders no explicit report date or number of days.

What retest, insurance and data terms belong in the RFP?

Write the retest count, deadline and price into the RFP itself. They are much harder to add after the findings arrive, and none of the 9 RFPs we read gave a retest deadline.

Retesting. Section 8 of the template asks the seven things that matter. The one people miss is the clock. A window that starts when findings are reported can close before a busy team ships its fixes. The PCI guidance notes that when fixes take a long time, a new test may be needed to reflect the system as it stands (section 4.3.2). A late retest can turn into a second purchase.

Insurance. Five of the 9 RFPs set a minimum for cyber or network security cover. The amounts were $2 million per claim (Ossining), $5 million per occurrence (Greenville Utilities, both years), $10 million per claim and in aggregate (Memphis) and $10 million (Grand Valley State University, for suppliers who use, store or have access to private, confidential or protected data). The limit is your risk or legal team's call. Just know that a high limit can rule out smaller specialist firms, so set it on purpose.

Data. Ask where findings and evidence are kept, who can see them and when they are destroyed. Ossining required destruction within 30 days of accepting the final report, except where retention is required by law. The PCI guidance recommends checking the contract wording on keeping and destroying evidence before testing starts (section 5.3.2).

How is an RFP different from a statement of work and rules of engagement?

The RFP asks for proposals. The statement of work records what you agreed to buy. The rules of engagement say how the test may run. None of the three is permission by its label alone.

These can live in one signed agreement. The PCI guidance says that documenting and agreeing the conditions of the test is what "authorizes the tester to test the environment," and that if a hosting provider's agreement requires its approval, you must get that approval first (sections 4.1.3 and 4.1.4). CREST's buyer guide makes the same point: the tester "must be authorised to perform any tests on your systems" (A Guide to Penetration Testing, December 2022, Part 4). CREST is a membership body for testing firms, so read its supplier advice with that in mind.

If any target is hosted or run by another company, or the contract has liability terms you don't understand, that is the moment for a lawyer.

What should carry into the final agreement?

Everything the winning proposal promised. Before you sign, hold the proposal next to the contract and check that nothing fell out.

• The exact scope table and its version
• Each requirement ID the provider accepted, and every exception
• The named testers, and the rule for swapping them
• Dates for access, test start, test end and final report
• The report contents and any extra letter
• Retest rounds, who does them, the deadline and what starts it
• The complete price, the payment dates, and reschedule and cancel fees
• Where data is kept and when it is destroyed
• How a change of scope is approved
• Written authorization for the real targets

Who should you send it to?

At least three providers that do the kind of test you need. CREST's guide suggests building a shortlist from at least three suppliers and choosing the one that meets your specific requirements, not the one with the most impressive list of services (Part 3, step 7).

Fit matters more than size. A firm that mostly tests web applications is a poor match for a factory network, and the reverse is true too. If you're buying a web application or API test, our comparison of published offers shows who tests, what each provider publishes on price, and their retest terms. For devices and other specialist systems we don't list matches, so ask each candidate for relevant past work.

Happy with your current provider? Send them the same RFP. You lose nothing, and you get their terms in writing.

Questions before you send it

Can I use this template for a public-sector bid?

Use it for the technical and commercial content, inside your organization's own process. Submission rules, contract terms and public records duties come from your procurement team, not from us.

Can one RFP cover several tests?

Yes. Rhode Island Housing asked for four tests at six-month intervals in one RFP. If you do this, ask for the price of each test separately, and ask what happens to the later tests if you end the contract early.

Do I need a different RFP for a PCI or SOC 2 test?

The template is the same. What changes is section 2 and the requirements table. Ask your assessor or auditor which systems must be covered and what the report must show, and write their answer in with its source. They decide whether the report is accepted. No provider and no template can promise that.

Is this a template for writing a proposal, or a list of open RFPs?

Neither. It helps a buyer write the request and judge the replies. Open bids are listed by the organizations that issue them.

Sources and how we checked

We read every source below on October 10, 2026 and report only what its text says. The template, the tallies and the fictional example are our own work. We do not perform, authorize or certify penetration testing, and none of the organizations named here endorses this site. This page is not legal or compliance advice.

How our findings work is explained in how to read a Purchase Check.