Penetration test RFP: what to include

What belongs in a penetration test RFP and why it decides the quality of the test

A request for proposal for a penetration test tells providers what you need to learn, what they may touch, and how you will judge the result. A good RFP settles the objectives, scope, rules of engagement, approval chain and deliverables before anyone quotes, so that providers price the same test and you can compare them fairly. If a framework, a customer security review, a product launch, an insurer or a due diligence process requires a test, the RFP is where that requirement becomes a defined piece of work.

Start with the risk the test addresses. A point-in-time penetration test examines whether an attacker can chain weaknesses to defeat security controls on the day it runs, using manual work that a scan cannot replicate. A vulnerability scan answers a narrower question, listing known weaknesses across many hosts in minutes per host. NIST SP 800-115 treats planning as its own phase, in which rules are identified, management approval is finalized and documented, and testing goals are set, before any discovery or attack activity begins. Your RFP should mirror that order: state the goal first, then the systems, then the limits. Ask providers to confirm in writing that they will not begin testing until the rules of engagement are signed.

Confirm internally which decisions the RFP must make before release. Name the executive sponsor who accepts the risk, the technical owner who can answer questions during testing, and the people who can stop the test. Decide whether the test is overt or covert, and which knowledge level (black, grey or white box) fits the goal, since the PCI SSC guidance notes that black-box work may need more time and resources to meet PCI DSS deliverables. The more of these choices you make in the RFP, the less a provider has to guess, and the easier it is to explain the final price to your finance or audit team.

Which sections a penetration test RFP needs, in the order providers will read them

This sequence moves from why the test exists to how it will be run, reported and paid for, so each provider answers the same questions in the same order and gaps are easy to spot. Each step closes with a written output you can compare across bids.

State objectives and business context
The buyer writes down why the test is being commissioned: a compliance requirement, a customer security review, a launch, an insurer's condition or a suspected weakness. Include the systems that matter most, the data they hold and any deadline that is fixed by a third party. Providers answer in writing with how they would translate that goal into a test type and what they would not be able to conclude from it. The step is done when a provider can state, in one paragraph, what success looks like for you.
Define scope and exclusions
The buyer lists targets such as domains, IP ranges, applications, cloud accounts, Kubernetes clusters or Active Directory domains, with environments (production, staging) and any systems that must stay out of scope, such as third-party hosted services whose owners have not approved testing. Providers answer with their understanding of the scope, questions about anything ambiguous and any targets they would need to exclude or treat separately. The step is done when the target list and exclusions are agreed in writing.
Specify testing approach and knowledge level
The buyer states whether testing is black box (no information provided), grey box (partial details) or white box (full details of networks and applications), using the definitions in the PCI SSC Penetration Testing Guidance. Say which accounts, roles and documentation will be shared. Providers answer with the knowledge level they recommend, why it fits the goal, and how a black box test would change time, cost and coverage. The step is done when the knowledge level is recorded with the access the tester will receive.
Set methodology and rules of engagement expectations
The buyer asks for the methodology the provider follows and requires it to be named in the report. NIST SP 800-115 does not endorse one methodology, so the buyer should accept a documented combination of recognized approaches. The buyer also asks for a rules of engagement document modeled on the template in Appendix B of NIST SP 800-115, covering testing windows, source addresses, permitted techniques, emergency contacts and stop conditions. Providers answer with a draft rules of engagement and a statement on how much work is manual versus tool-driven. The step is done when both documents are signed by both sides.
Request tester qualifications and independence
The buyer asks who will do the work, their experience on similar targets and the certifications held. The PCI SSC guidance lists credentials such as OSCP, GIAC certifications, CREST certifications and CHECK as indicators of skill, while noting that certifications alone do not establish experience. Ask for named testers, their relevant experience and any conflicts of interest. If the provider holds CREST accreditation, ask for the scope of that accreditation. Providers answer in writing with named roles and a background summary. The step is done when the team is confirmed and any substitution requires your approval.
Require report and retest terms
The buyer specifies the report contents they need, such as an executive summary, statement of scope, statement of methodology, statement of limitations, findings with CVE and CWE references where applicable, and an explanation of how severity was derived, typically from CVSS with traceable adjustments. The buyer also sets retest terms: whether retesting is included, how it is documented and how long after remediation it is available. Providers answer with a sample report, a retest policy and the basis for severity ratings. The step is done when the report outline and retest terms appear in the contract.
Set data handling and insurance requirements
The buyer states how findings, credentials, screenshots and captured data must be stored, encrypted, retained and destroyed, and who may access them. Specify the locations where data may be held and the deletion deadline after closure. Ask for professional indemnity and cyber liability cover and for proof of certificates. Providers answer with their data handling procedures, the controls protecting client material and the insurance limits they carry. The step is done when the data handling schedule is signed and the insurance evidence is on file before testing starts.
Score responses against evaluation criteria
The buyer scores each response against the criteria set earlier, with written weights for methodology, team, scope fit, report quality, retest terms, data handling and price. Ask every provider to state whether the work is primarily manual or tool-driven, since a scan with a report template is not a penetration test. Ask for the quote to split costs into one-time testing, retesting and any recurring elements. The step is done when the scoring sheet and the quotes are kept in the procurement record with written reasons for the award.

What can be in scope for a penetration test and what the RFP must fix

An RFP should name the targets it wants tested, then fix the decisions that determine what the provider actually touches. Each target below has its own detailed method, so the RFP only needs to state what is in, what is out and who decides.

External and internal networks

List the public IP ranges, domains and hosted services for the external test, and the internal segments, VLANs or sites for the internal test. State whether the internal test starts from a workstation, a standard user account or a network jack. Confirm which segments hold regulated data, because PCI SSC's guidance expects segmentation to be verified where it is claimed. Methodology sits in the infrastructure pillar.

Web applications and APIs

Name each application, its version or release, its environments and its API base paths, and say whether the test covers authenticated flows, payment steps and admin functions. Provide the API specification where one exists. Ask the provider how it will handle rate limits and destructive actions on production data. Detailed method is covered in the web and API pillar.

Cloud accounts and Kubernetes clusters

Name the cloud accounts, subscriptions or projects, the regions in use, and the clusters or managed services in scope. Confirm each provider's published testing rules before the window is set, and identify which controls belong to the provider and which to the client. Asking for read-only configuration review alongside active testing should be a deliberate choice written into the RFP.

Identity systems and remote access

Identify the directory, identity provider, single sign-on, VPN and remote access gateways in scope, along with any hybrid identity links to cloud tenants. Decide whether the provider may attempt credential attacks, test MFA enrollment and reset flows, or only review configuration. Active Directory and hybrid identity method is in the infrastructure pillar.

Wireless and physical sites

State the physical locations, wireless networks and SSIDs, and any guest or contractor networks. Decide whether the test includes rogue access point detection, client isolation checks or physical access. Physical and social engineering work needs its own authorization letter and approval chain, so separate it from the network scope.

Exclusions, windows and rules of engagement

Write down systems that must not be tested, third-party hosts the client does not control, and fragile legacy assets. Set testing windows, emergency contacts, stop conditions and how the provider escalates critical findings during the test. NIST SP 800-115 includes a rules of engagement template in its appendix, which many buyers adapt for the RFP.

Choosing black-box, grey-box or white-box testing in the RFP

Under the definition in the PCI SSC Information Supplement *Penetration Testing Guidance* (v1.1), black-box testing is performed with no information provided to the tester beyond what is needed to start. It simulates an outsider who has to discover the target surface unaided, so it can show how an attacker with no insider knowledge would approach the environment. That realism has a cost. PCI SSC notes that a black-box assessment may require more time, money and resources to produce the deliverables that PCI DSS requires, because the tester spends effort on discovery that a grey or white box test would skip. In an RFP, black-box testing is most useful when the goal is to measure external exposure rather than to cover a defined set of systems.

Discovery effort: Ask how much of the budgeted time goes to reconnaissance and how that time converts to tested targets.
Coverage limits: Ask which in-scope assets the provider expects to miss without credentials or documentation, and how they will be reported.
Stated purpose: Ask the provider to explain which question a black-box test answers for your organization, such as external exposure.
Deliverables: Ask whether the report will still meet the specific requirements of your framework if the test is black box.

Check that the RFP does not ask for a black-box test where the auditor will expect full coverage of a named system set.

Questions that separate manual testing from scan resale

A penetration test and an automated scan can look similar in a proposal, but they produce different evidence and take different amounts of tester time. The questions below help you ask providers to show where manual work happens, how tool output is checked and who did the work. Each one should produce evidence you can inspect before you sign.

Share of manual work

Ask the provider to state, in hours or as a share of the plan, how much of the engagement is manual testing and how much is tool execution. PCI SSC describes penetration testing as a mainly manual process, while vulnerability scans run mostly automated tools and finish in seconds to minutes per host. A proposal that does not separate these activities, or that prices the work by host count alone, deserves a closer look before you compare it with others.

Findings from manual exploitation

Ask which findings came from a tester manually defeating a security feature, such as an authentication control, a session boundary or an access check, and which came from a tool report. Request the evidence for each high-impact finding, including the conditions under which it was reproduced and the controls that were bypassed. Findings with no manual confirmation are candidates for validation, not proof of exploitable risk.

How tool output is validated

Ask how the tester confirms that a scanner result is real, how false positives are removed and whether any finding was excluded from the report. The answer should describe a documented validation step per finding, with notes on what the tester checked by hand. OWASP ASVS states that running an automated tool without thorough testing is insufficient for verification, so an answer that relies on the tool alone signals a scan resale offer.

Testers on the engagement

Ask how many testers will work on the engagement, who leads it and what experience each person brings to the target technology. Ask for the names or roles of the people who will perform the manual work, and whether the same team will perform the retest. Certifications such as OSCP, GPEN or CREST individual certifications indicate skill, but PCI SSC notes that certifications alone do not establish experience, so ask for relevant project history too.

Testing logic and authorization flaws

Ask how the tester checks business logic and authorization, such as whether one user can reach another user's records, whether a workflow can be completed out of order or whether a role boundary holds across APIs. These flaws rarely appear in automated output because they depend on application intent. Request a description of the test cases, the accounts or roles used and the evidence captured for each access decision that was tested.

Coverage and tool disclosure

Ask the provider to list the tools used, the scope items covered by each test and the areas where automated tools were not appropriate. The report should disclose the testing methods and any statement of limitations, consistent with the reporting practice that ASVS and PCI SSC describe. A provider that cannot name its tools or explain its limits is harder to audit and harder to trust with production systems.

Weakness categories a penetration test RFP should require providers to cover

This table lists the weakness categories a buyer should expect a penetration test to address, how each usually appears in a typical scope, and why it matters to the buyer's risk. Use it to check that an RFP names each category explicitly, so providers cannot quietly narrow coverage to what an automated tool finds.

Weakness category	How it appears in a typical scope	Why it matters to the buyer
Broken access control	Role boundaries, object-level permissions and tenant separation tested with more than one account per role	Users reaching data or functions outside their role is a common route to a material breach and is hard for scanners to detect
Authentication and session weaknesses	Login, password reset, multi-factor enrollment, token lifetime and session termination reviewed in the live application	Weak controls here undermine every other safeguard and often map directly to compliance requirements
Security misconfiguration	Cloud settings, server hardening, default accounts and verbose error handling checked against the agreed baseline	Misconfiguration is a frequent cause of exposure and is usually fixable quickly once the owner knows about it
Exposed services	External address ranges and hostnames inventoried, with open ports and unexpected services identified and verified	Forgotten or shadow services widen the attack surface without appearing in asset registers
Weak network segmentation	Tests from a low-trust zone attempting to reach restricted zones, where the RFP defines those zones	Segmentation is often the control that limits the blast radius of a compromise, and PCI DSS scope depends on it
Vulnerable dependencies and components	Versions of frameworks, libraries and self-hosted platforms compared against vendor advisories and known vulnerability records	Known-vulnerable components are easy to exploit once identified, so the report should show which findings are confirmed in the environment
Business logic flaws	Multi-step workflows such as payments, approvals, refunds and account changes tested for abuse of intended rules	Automated tools rarely model business rules, so these flaws often carry the highest impact and need manual testing time
Injection and input handling	Input validation and output encoding reviewed across forms, APIs and file handling, with confirmed issues recorded as findings	Input handling defects remain common in custom code, and the RFP should require confirmed evidence rather than scanner output alone

What methodology the RFP should ask providers to disclose

Ask every provider to name the testing method they follow, or the combination of methods they use, before you compare prices. NIST SP 800-115 describes four phases: planning, discovery, attack and reporting. It does not endorse one methodology over another, so a provider can legitimately combine several frameworks. That flexibility is exactly why the RFP must make them state their choice. Ask which framework or internal playbook guides each phase, how they map their work to your targets (web, API, cloud, network, identity), and whether they adapt the method for each engagement or run the same steps every time. A vague answer such as "industry best practice" tells you nothing you can check.

Ask for the phases in writing, with the deliverable and the evidence produced at each one. Planning should show the rules of engagement and approvals. Discovery should show how assets were identified and enumerated. The attack phase should show which weaknesses were tested by hand and which were only flagged by tools. Reporting should show how findings were validated. Ask how manual work is recorded, such as tester notes, test logs and time spent per target, so you can confirm that the engagement involved human judgment rather than tool output. The OWASP ASVS guidance on certification says the organization should disclose its testing methods in the report and that running an automated tool without thorough testing is insufficient. Make that disclosure a contractual deliverable.

Finally, require the provider to document limitations in the report. Ask them to state which targets, accounts, environments or attack paths were out of reach, which tests were not performed, and which findings depend on the test window or the access granted. The PCI SSC suggested report outline includes a statement of methodology and a statement of limitations for this reason. Confirm with the provider how they will handle a limitation discovered mid-test, and whether it changes the scope or price under the agreed terms. Your auditor or customer will read these statements, so the RFP answer should match what the report will eventually say.

How to ask about tester qualifications without relying on certificates alone

Certificates tell you a tester has studied for an exam, not that they have run a test like yours. A strong RFP asks for named people, documented experience, sample work and company-level accreditation, then checks that the pieces agree.

Named testers and their roles

Ask the provider to name the people who will do the manual testing, the lead tester and any reviewer, and to state the role each one plays. Confirm whether the people in the proposal are the people who will be on your engagement, since a firm's marketing team and its delivery staff are often different. Ask for the testers' tenure with the provider so you can judge continuity if the work runs across weeks.

Years of relevant experience

Ask each named tester how many years they have spent on the specific test type in your RFP, such as external network, web application, cloud or Active Directory. General IT experience does not show that someone can chain weaknesses or judge business impact. Request a short description of recent engagements of a similar technology and size, with client identities removed.

Sample reports with identifying details removed

Ask for a redacted sample report that shows how findings are written, how severity was reasoned and how limitations are stated. Check that the sample includes a statement of methodology and a statement of limitations, as the PCI SSC report outline expects. A report that lists scanner output with little manual validation is a sign of scan resale.

Credentials PCI SSC names as indicators

PCI SSC's Penetration Testing Guidance lists OSCP, GIAC GPEN and GWAPT, CREST certifications and CHECK as indicators of tester skill. PCI SSC does not validate or endorse these, and the guidance states that certifications alone do not establish experience. Ask which credentials each named tester holds, when they were obtained and whether they are current, then match them against the experience you verified.

CREST accreditation as a company signal

CREST describes itself as a not-for-profit company registered in the UK that accredits member companies and certifies individuals in disciplines including security testing and red teaming. Company accreditation speaks to the firm's processes and governance, while individual certification speaks to the person. Ask whether the firm holds a CREST accreditation that covers the work in your RFP, and confirm the status directly with CREST.

Data handling, safe testing and insurance terms to write into the RFP

The RFP should require the provider to state how evidence and credentials gathered during testing are handled, because a penetration test often produces copies of customer records, session tokens, password hashes and administrative secrets. Ask the provider to specify where this material is stored (the provider's own systems, your environment or an encrypted workspace), who on the tester team can access it, how long it is retained after the report is delivered, and how it is destroyed at the end of that period. Ask for written confirmation that credentials are used only for the agreed targets, are not reused outside the engagement, and are removed or rotated at close. Ask also whether any production data is copied at all, and if it is, what masking applies. These answers belong in the proposal and are later recorded in the signed rules of engagement.

The RFP should also require a description of how the provider keeps testing from disrupting production services. Ask which tests run only in agreed windows, which rate limits and request ceilings the team applies to denial-of-service-sensitive functions, how the team will stop immediately if a service degrades, and who on your side receives that call and at what contact point. Ask whether the team tests against staging or production, and how it treats destructive actions such as account lockouts or data changes. On insurance, ask the provider to confirm in writing that it holds professional liability (errors and omissions) cover and general liability cover, and to name any cyber or other policies relevant to the work. Confirm the limits, currency and policy periods with the provider and its broker rather than assuming them, and check that the cover is in force for the full engagement and any retest window.

How the RFP differs for compliance, customer reviews and launches

When the test is required by a framework, the RFP has to be built around the assessor's expectations rather than a general wish for a good test. For PCI DSS, requirements 11.4.2 and 11.4.3 call for internal and external penetration tests at least every 12 months and after significant changes, and requirement 11.4.4 requires exploitable findings to be corrected and the test repeated to verify the fix. The RFP should therefore state the requirement numbers, the in-scope environment that the assessor has agreed, and the segmentation testing expected where it applies.

Named requirements: cite the exact clauses the test supports, such as 11.4.2 or 11.4.3, so the provider scopes to them.
Methodology statement: require a stated approach, with the knowledge level (white, grey or black box) justified against the assessor's expectations.
Report structure: ask for the scope, limitations, methodology and segmentation results sections that the PCI SSC outline describes.
Retest included: specify how the verification test after remediation is priced and timed.
Tester qualifications: request evidence of skills as the assessor will look for them.

Before issuing the RFP, confirm with the qualified assessor or your acquirer what evidence they accept, which tester qualifications they recognise, and whether the test must be performed by an independent party.

Questions buyers ask before they write a penetration test RFP

What drives the cost of a penetration test?

Cost follows the amount of skilled manual work, which is set by scope size, the number of targets and environments, the test type and how deep the testers go. Black-box work usually needs more time than grey or white-box work because testers must first find what they are testing, and PCI SSC notes that a black-box assessment may need more time, money and resources to produce deliverables that meet PCI DSS requirements. Reporting depth, retesting and any compliance-specific deliverables add further effort. Ask every bidder to price these components separately so you can see which one changes the total.

How long does a penetration test take?

Duration depends on scope, and PCI SSC describes penetration testing as a mainly manual process that may last days or weeks depending on scope. A narrow external test of a few applications will be much shorter than an internal test of a segmented network with hybrid identity. Add time for planning, rules of engagement, testing windows, the report and the retest, which are separate stages. Ask the provider to show the phases and the calendar dates they expect each one to take, and to state what would extend the schedule.

What does the client need to provide for a penetration test?

The client provides the information and access that make testing accurate, and this effort is often larger than buyers expect. NIST SP 800-115 treats planning as the phase where rules are identified, management approval is documented and testing goals are set, and no testing occurs before that. Expect to supply target lists, network diagrams, test accounts with defined roles, named technical contacts, testing windows, exclusions and emergency stop contacts. Asking for white-box or grey-box access usually means more of this preparation, so budget staff time on your side as well.

Can our own team run the penetration test internally?

Internal staff can run tests, but they must meet the same independence and evidence expectations as an external tester if the results will go to an auditor or customer. NIST SP 800-115 notes that overt testing, done with IT staff knowledge, is less expensive and carries less risk than covert testing. The questions to answer honestly are whether the team has current manual testing skills, whether testers are independent of the systems they assess, and whether the report will be accepted by the assessor who needs it. Confirm the acceptance requirement with your assessor before choosing an internal approach.

How should we compare penetration testing quotes?

Compare quotes on the same written scope, not on the headline figure. Each quote should list the targets, environments, test type, testing windows, named testers' experience, deliverables, retest terms and any exclusions. A quote that omits the report depth or the retest is not comparable to one that includes them. Also check whether the provider performs substantial manual testing or mainly runs automated tools, since PCI SSC contrasts scans that take seconds to minutes per host with manual penetration testing. DeployOpen does not publish a price list, and a quote follows from the written scope.

What does a fixed-scope written penetration test engagement include?

A fixed-scope engagement defines the targets, the test type, the methodology, the rules of engagement, the deliverables, the timelines and the retest terms in writing before work starts. DeployOpen works this way for most engagements. The written scope should name what is out of bounds, who approves testing, how critical findings are reported during the test, how data collected during testing is stored and deleted, and what happens if the environment changes mid-test. Check that the agreement also states who is responsible for changes you request after signing.

How often do we need to repeat a penetration test?

PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes. Other frameworks set their own rules, so confirm the cadence your assessor expects before pricing a recurring program. For budgeting, treat the annual test and the change-triggered tests as recurring costs, and the first engagement as a one-time setup cost that may include scoping work. Ask whether a retest after fixes is included, since PCI DSS requirement 11.4.4 expects corrections to be verified by repeating the test.

How DeployOpen responds to a penetration test RFP

DeployOpen answers a penetration test RFP with a written scope before any testing begins. Most engagements are fixed-scope, which means the targets, test type, knowledge level, testing windows, deliverables and timelines are agreed in writing first. Because DeployOpen does not publish a price list, the quote follows from that written scope, so a clear RFP that names the systems, accounts, exclusions and the reason for the test (a framework requirement, a customer review or a launch) lets the proposal be compared on equal terms. Expect the scope to be checked against the rules of engagement and the planning stage described in NIST SP 800-115 before any testing starts.

DeployOpen runs security testing across applications and APIs, cloud and infrastructure, AI systems and agents, and red teaming, so one provider can cover several targets in the same engagement. Reports are written to support a remediation decision, with the scope, methodology, limitations and findings recorded so the client can show what was tested and how. Retesting is agreed as part of the written scope, so the client knows in advance whether corrections will be verified and at what point a new engagement would be needed. Ask DeployOpen to confirm the exact retest terms, the report format and who receives the evidence before you sign.

DeployOpen prepares systems, controls and test evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which evidence they expect from a penetration test. For ongoing needs, retainers are available for continuing support and recurring testing, which suits organizations that must test after significant changes. To receive a written scope and quote, send your RFP with the objectives, target list, testing windows, required report content and any data handling or insurance requirements your organization sets.

Penetration test RFP