Penetration Test RFP and Scoping Checklist

A penetration test RFP should define the business objective, authorized targets, access roles, test boundaries, operating limits, reporting evidence, and retest expectations. Give every bidder the same scope. A proposal called “application penetration testing” is difficult to compare when one supplier assumes a public website and another assumes authenticated access to the entire service.

This guide is for buyers preparing a scoped engagement, not for running an unapproved test. It proposes a practical RFP and rules-of-engagement structure using official sources reviewed on October 19, 2026. We did not conduct a penetration test, evaluate providers firsthand, or obtain pricing. Technical review is pending. No affiliate links or paid placements are included.

Write the decision the test must support

Start with why the organization is commissioning the assessment. You may need evidence before a major release, a review of a sensitive customer workflow, or validation after a significant architectural change. Identify the person who will use the findings and the decisions that should follow.

“Find every vulnerability” is not an achievable scope statement. A useful objective might ask whether defined roles can access records outside their authority, whether a deployment boundary exposes unintended administration, or whether the assessed application protects a particular transaction. State what evidence would be useful without promising complete assurance.

The ethical hacking introduction explains the general purpose of authorized testing. The buyer’s next job is to turn that purpose into a specific, approved engagement that both the organization and provider understand.

Build an asset and boundary schedule

List the actual targets: domains, applications, APIs, mobile builds, cloud accounts, environments, and supporting services. Use precise identifiers in the controlled engagement record. Identify who owns each target and who can authorize testing. A system used by your organization may still belong to a supplier whose permission is required.

Show the relationships among targets. A browser interface may call an API in a different environment. A mobile application may use the same identity service but store local data. A cloud assessment may include permissions and control-plane configuration rather than only network-facing hosts. Mark which relationships are included and which are outside scope.

Do not put sensitive access details or confidential infrastructure information into an unrestricted public RFP. Provide enough information for comparable proposals, then use an approved secure exchange for the detail the selected assessors need.

Specify access and test perspectives

Explain whether testing begins without credentials, with ordinary user access, with multiple business roles, or with architectural information. Avoid relying on color labels alone; suppliers may interpret them differently. Describe the accounts, permissions, documentation, and support the organization will provide.

For an application with several roles, identify representative pairs. A standard user and an administrator may not cover the boundary between two customers, two departments, or a contractor and an employee. Give bidders enough context to explain how they will examine the important business boundaries.

Ask who prepares and validates the accounts before the test starts. An engagement can lose time to unusable credentials or incomplete test data. Define what happens if access is delayed, the application changes, or an environment becomes unavailable, including how the scope and delivery date will be revised.

Use standards as a shared reference

NIST SP 800-115 provides a foundational process reference for planning technical assessments, analyzing findings, and developing mitigation strategies. It was published in 2008. Use it for planning discipline while checking current technology-specific guidance and provider rules.

OWASP ASVS can help specify application verification requirements. Identify the chosen version, relevant requirements, and any exclusions. Ask the supplier to explain how the proposed work addresses the selected requirements and where the engagement uses sampling or time-limited judgment.

A standards reference should make coverage easier to discuss. It should not become a promise that every requirement is fully assessed simply because the project name appears in a proposal. Require a coverage statement with the final report and an explanation of important untested areas.

Agree on rules of engagement before execution

The rules should identify who authorizes the work, the approved dates and source locations, emergency contacts, prohibited activities, stop conditions, handling requirements, and communication routes. Keep written approval separate from a purchase order that does not describe technical authority.

Discuss potentially disruptive techniques explicitly. The organization and provider should agree on whether social engineering, denial-of-service activity, credential attacks, sensitive-data access, persistence, or testing of shared infrastructure is permitted. Do not assume a broad word such as “comprehensive” grants those permissions.

For cloud-hosted targets, review the provider’s current policy for the exact services and activities. AWS publishes its penetration-testing policy, including service and activity boundaries. Customer authorization does not override platform restrictions or grant authority over another tenant.

Define a real stop procedure

Name the person who can stop the engagement and the provider contact who receives that instruction. Specify how the team confirms testing has stopped and how work resumes. Include a route that still works if the assessed application or ordinary messaging service is unavailable.

Agree on the evidence to preserve if testing discovers an unrelated active compromise or causes an unexpected effect. Do not improvise investigation, cleanup, or destructive remediation under a vague testing agreement. Escalate the event under the approved incident process and clarify any additional scope.

Request evidence that supports repairs

Describe the reporting output you need: scope and limitations, tested roles, confirmed findings, reproducible evidence, business context, affected assets, and actionable remediation guidance. Ask for both an executive decision summary and technical detail appropriate to the people doing the repair.

Request a sanitized example finding before selection where available. Evaluate whether it identifies the tested boundary, expected behavior, observed behavior, and consequence. A severity label or a screenshot without context can be difficult for an engineer to reproduce and difficult for a manager to prioritize.

Clarify how sensitive evidence is collected, stored, transferred, and deleted. Ask for minimization: the assessor should demonstrate impact without collecting unnecessary customer content. The exact handling terms depend on your organization and contract; have the appropriate reviewer confirm them.

Make retesting part of the purchase decision

Ask which findings can be retested, how long the window remains open, what changes require new scoping, and how additional work is quoted. Clarify whether the retest examines only the original proof or also agreed related cases and the legitimate workflow.

Define closure outputs. A retest should state which finding, application build, environment, roles, and scenario were examined, the result, and remaining limits. “Retest included” is incomplete if nobody knows what evidence the organization receives afterward.

Assign the internal owner responsible for delivering a deployed repair and valid retest prerequisites. If the provider is ready but the test environment contains an older build, the resulting report will not establish the state of production. Link the repair record to the version actually assessed.

Compare proposals on the same assumptions

Create a comparison sheet with the agreed target set, access roles, environments, test window, reporting outputs, retest scope, and operating limits. Ask each bidder to mark deviations. A supplier may offer a sensible alternative, but preserve it as an alternative rather than silently treating it as equivalent.

Request the effort assumptions and the responsibilities left to your staff. Distinguish assessor time from elapsed calendar time. Record whether environment preparation, coordination meetings, findings review, retesting, and travel or specialist services are included or separate.

Use written quotations for price. This article does not supply a universal rate or a market range. A cheaper bid may cover less work, or it may be efficient for the defined scope. The decision requires the assumptions and evidence behind the proposal, not a price comparison detached from coverage.

Use a readiness meeting to accept the final scope

Before the test window, have the coordinator walk through a representative business action with the application owner and assessor. Confirm the exact environment, approved identities, synthetic records, permitted operations, and expected evidence. This is a readiness check, not permission to begin testing early.

Resolve how test activity will be recognized by operations staff. Record approved source identifiers where appropriate, the communication route for unexpected alerts, and who determines whether an event belongs to the test or a separate incident. Do not automatically suppress monitoring simply because a test is scheduled; agree on the operating arrangement and preserve its limits.

Use the meeting to reconcile changed assets and accounts against the signed scope. If the team discovers an extra API, a production redirect, or an unavailable role, update the controlled schedule and obtain the required approval. An assessor should not have to infer authorization from an architecture diagram that conflicts with the target list.

Finish with an explicit ready, ready with named limitations, or not-ready decision. Assign an owner and next action to every missing prerequisite. A short, evidence-based delay is preferable to paying for a window that cannot examine the business boundary the organization intended to assess.

Scoping mistakes that become delivery disputes

Leaving APIs implied by a website name. Identify whether authenticated API behavior and role boundaries are part of the engagement. A browser assessment can otherwise leave a shared backend incompletely addressed.

Using production by default. Discuss environment realism and operational risk. If testing occurs outside production, document differences that limit conclusions. If production is required, agree on specific techniques, monitoring, and stop conditions.

Assuming the provider can authorize a supplier’s target. Assign permission gathering to a named owner and obtain the required written authority. Scope uncertainty should be resolved before execution.

Buying a report without a repair handoff. Include a findings review and a route for technical questions. The organization’s ability to act on the evidence is part of the engagement’s usefulness.

Questions to settle before signing

Can we use one RFP for several test types?

Yes, when the scope schedule separates the surfaces, access, techniques, and evidence expected for each. Ask bidders to identify shared work and boundaries rather than quoting one unexplained package label.

Should we disclose architecture to the assessor?

Choose the information supplied according to the assessment objective and document that choice. Additional context can help a time-limited review focus on relevant boundaries. It changes the perspective being tested, so the report should explain what the assessor knew.

What if a target changes after approval?

Use a written scope change. Record the new target or behavior, ownership and authorization, operational effects, effort, and delivery implications. Do not rely on an informal message that later readers cannot reconcile with the signed rules.

Send a scope that can be accepted and verified

Complete the asset schedule, role matrix, rules of engagement, reporting requirements, and retest terms before requesting final prices. Ask the application owner and security lead to confirm the same scope. Keep unanswered questions visible until they are resolved.

Use the penetration testing overview and existing service review as background, not as substitutes for the engagement record. The useful next step is a short scoping meeting that leaves both sides able to state what is authorized, what evidence will be delivered, and what remains outside the test.