Penetration Testing RFP Template

How to use this

There is no file to download here, and that is deliberate. A security RFP that is a filled-in template from a vendor's website reads exactly like one, and experienced providers price accordingly. Copy the headings below into your own document, delete what does not apply, and write the specifics in your own words.

The purpose of an RFP is not to describe what you want in the abstract. It is to make four responses comparable. Every section here exists because leaving it out produces responses that cannot be scored side by side. If you are earlier in the process, read how to buy penetration testing first and come back with a scope.

One structural tip before you start: state up front that responses must follow your section order and page limits. Providers who ignore that instruction have told you something useful about how they will handle your scope constraints later.

Section 1: Background and objectives

Give respondents enough context to propose sensibly, and be honest about the driver. A provider who knows you need a report for a customer security review by a fixed date will propose differently, and better, than one who is guessing.

• A short description of your organisation, sector and size.
• The business driver: audit or customer requirement, regulatory expectation, major release, migration, post-incident assurance, or first baseline.
• The decision the results must support, and who will read them. Board, engineering team, auditor and customer are four different audiences.
• Any previous testing, when it was performed and whether findings from it remain open. Say so if there was none.
• Fixed dates you are working to, including the date you need the final report in hand rather than the date testing must finish.
• The compliance or contractual regimes in play, named. This changes the reporting requirement more than anything else in the document.

Section 2: Scope, in and out

This is the section that determines whether the responses are comparable. Be specific to the point of tedium. If you cannot publish the full asset list in the RFP itself for sensitivity reasons, publish accurate counts and types, and release the detail under non-disclosure to shortlisted respondents.

In scope

• External assets: domains, subdomains, public IP ranges, and whether discovery of unknown external assets is wanted.
• Web applications: how many, roughly how large, and whether they are public, partner-facing or internal.
• APIs: REST, GraphQL or both; whether specifications are available; and how many distinct services.
• Internal networks: subnets, approximate host counts, and whether Active Directory or another directory is in scope.
• Cloud accounts and subscriptions: providers, how many accounts, and whether configuration review is wanted alongside testing.
• Kubernetes clusters: how many, which distributions, and whether they are managed or self-hosted.
• Mobile applications: platforms, and whether source or only the built package will be provided.
• Authentication: the roles to be tested, and whether credentials will be supplied for each.
• Environment for each item: production, staging, or both, and how faithfully staging reproduces production.

Out of scope

• Denial-of-service and volumetric testing, unless separately commissioned and separately authorised.
• Social engineering, phishing and physical intrusion, unless you are explicitly buying them.
• Third-party hosted systems for which you cannot provide written authorisation from the operator.
• Named fragile systems, legacy hosts and anything with a documented history of falling over under load.
• Any destructive action, data modification or data exfiltration beyond the minimum needed to evidence a finding.

Section 3: Testing windows and constraints

Constraints are not a nuisance to be minimised. They are part of the scope, and a provider who is told about them up front will price and plan around them instead of discovering them mid-engagement.

• Permitted testing hours per asset class, including whether any testing must be out of hours and in which time zone.
• Change freezes, peak trading periods and blackout dates.
• Rate limiting, traffic thresholds and any monitoring or protective technology that will need tuning or an allow-list entry.
• Whether defensive teams are informed. State plainly whether this is an announced test or a blind exercise, because the two are different products.
• Escalation: named technical contact, escalation contact and an out-of-hours number, with the response time you expect from each side.
• Stop conditions: what causes testing to pause immediately, and who has authority to call it.
• Access logistics: VPN, jump host, agent deployment, read-only cloud credentials or kubeconfig, and how long each takes your team to provision.

Section 4: Methodology expectations

Ask respondents to describe their methodology against named standards rather than in their own marketing vocabulary. The recognised reference points are the Penetration Testing Execution Standard for engagement phases, the OWASP Web Security Testing Guide for web test cases, the OWASP Top 10 and OWASP API Top 10 as risk taxonomies, SP 800-115 from NIST for the overall assessment process, CIS Benchmarks for configuration baselines, and CREST guidance where accreditation matters to you.

Severity deserves its own question. CVSS from FIRST is the common language, and v3.1 is still what most compliance regimes expect to see. Ask how the respondent adjusts for business context and whether they factor in real-world exploitation signals such as the known-exploited vulnerability catalogue published by CISA.

• Which standards the methodology maps to, and where it deliberately deviates.
• The phases performed, what happens in each, and which are automated versus manual.
• How findings are validated before delivery, and the proportion that are manually confirmed.
• Whether exploitation is performed, what "safe exploitation" means in their hands, and the technical controls that keep it inside scope.
• How false positives are identified and suppressed, and what happens when you dispute a finding.
• How severity is assigned, including any adjustment for asset criticality or compensating controls.
• For continuous or platform-based responses: scan frequency, what triggers an unscheduled test, and how new assets enter scope.

Section 5: Reporting and evidence requirements

State your requirements rather than asking what the provider offers. Then ask for a redacted sample report so you can check the claim against the artefact. Read the remediation guidance in the sample closely: it is the fastest way to tell investigation from detection.

• An executive summary written for a non-technical reader, stating overall risk position and the immediate priorities.
• A scope statement in the report matching the agreed scope, with exclusions and the reason for each.
• Per finding: description, affected asset, how it was confirmed, evidence, severity with reasoning, and remediation specific to your technology.
• Reproduction steps an engineer can follow independently, without a call back to the tester.
• Mapping of findings to the frameworks you named in Section 1, framed as a mapping rather than an assertion of compliance.
• Formats: a document format for distribution and a machine-readable format or API for ingestion into your tracker.
• An attestation or summary letter suitable for sharing with customers, if you need one, and confirmation of what it will and will not say.
• Delivery timeframe from end of testing, and a walkthrough session with the people who did the work.
• Evidence retention: how long the provider keeps evidence and reports, and how you obtain copies later.

Section 6: Retest expectations

Retesting is the most commonly under-specified section of a security RFP and the most common source of a later invoice. Define it precisely, because without it you cannot demonstrate to anyone that a finding was closed.

• Whether verification of remediated findings is included in the fee or charged separately.
• How long after delivery the retest entitlement remains valid, and whether it can be used in more than one pass.
• Whether the retest covers only the original findings or re-examines the surrounding functionality.
• Whether the retest produces an updated report or a separate verification letter, and whether the original report is reissued.
• How new findings discovered during a retest are handled commercially.
• For continuous programmes: whether re-verification happens automatically on the next scheduled run, and how closure is evidenced.

Section 7: Commercial model

Ask for the pricing model in words as well as numbers, and require a three-year total cost view. Different models look very different at year one and very similar, or not at all similar, by year three.

• The model: day rate, fixed scope, per asset per period, credit pool or consumption. Ask respondents to state which they are quoting.
• What is included and what is chargeable: retest, additional roles, additional assets discovered mid-engagement, out-of-hours work, travel.
• How additions are priced mid-term, and whether the same rate applies to assets added after signature.
• For credit models: expiry, rollover and what happens to unused value at renewal.
• Term, renewal mechanism, indexation and notice period. Automatic uplift clauses belong in the evaluation, not in a surprise.
• Payment terms, invoicing arrangements and any prepayment requirement.
• A three-year total cost of ownership under a stated growth assumption, so responses are comparable on the same basis.

Section 8: Security and data handling requirements of the vendor

You are about to hand a supplier a catalogue of your weaknesses. Their own security posture is not a formality, it is part of the risk you are taking on, and this section should be scored rather than filed.

• Certification and independent assurance held by the vendor entity, such as ISO/IEC 27001, with the certificate and the scope statement available on request.
• Where findings, evidence and reports are stored, in which country, and under whose legal jurisdiction.
• Who can access your data, including any offshore support or engineering teams, named by location rather than described vaguely.
• Sub-processors, named, with a mechanism for notifying you of changes.
• Encryption in transit and at rest, key management, and whether tenant data is separated or pooled.
• Access control on the vendor side: role-based access, multi-factor authentication, and audit logging with a stated retention period.
• Retention and destruction: how long data is kept, how deletion is performed and how it is evidenced.
• Personnel: background checks, security training, and whether any work is subcontracted.
• Contract instruments the vendor can sign: master services agreement, data processing agreement, non-disclosure and an authorisation-to-test record.
• Insurance: professional indemnity and cyber liability, with current certificates of currency and the limits stated.
• Incident notification: what the vendor commits to tell you, and within what period, if they suffer a breach affecting your data.
• Exit: return and destruction of your data and reports at termination.

Section 9: Evaluation criteria and weightings

Publish your weightings in the RFP. It disciplines your own scoring, and it tells respondents where to spend their effort, which improves the quality of what you receive. The weightings below are a sensible default for a mid-sized organisation buying an ongoing programme rather than a one-off engagement. Shift them to match your driver: if the test exists to satisfy an auditor, reporting rises; if it exists to protect a critical platform, methodology rises.

Scoring in practice

Score each criterion out of five against written descriptors agreed before you open the responses, then apply the weightings. Two practices are worth adopting: score the sample report blind, with the vendor name removed, and hold a separate reference call before the final score is locked. Price should be scored, not used as a veto, otherwise the weightings are decoration.

Set a minimum threshold on the vendor security criterion. A respondent who cannot answer where your findings will be stored should not be able to win on price.

Common mistakes worth avoiding

• Asking for "a penetration test" without stating asset counts. You will receive four proposals for four different products.
• Omitting the authentication requirement, then discovering that the quoted work was entirely unauthenticated.
• Leaving retest undefined, then paying for it separately at a worse rate.
• Requesting an attestation letter without saying what it must state, and receiving one your customer will not accept.
• Evaluating on day rate alone when respondents are quoting different models.
• Skipping the sample report, which is the only artefact in the process that cannot be written by a bid team.
• Running the process without your legal team, then losing four weeks to a data processing agreement nobody had read.

How PentestOps answers these

If you send us an RFP built on this structure, here is roughly what comes back, so you can decide early whether a continuous platform fits the shape of what you are buying.

Scope and commercials: pricing is asset-wise, so the asset list in Section 2 is also the pricing basis. Scans against an asset are unlimited within fair use, which makes the three-year view in Section 7 straightforward to model. All paid plans start with a 7-day free trial. A card is required to start your trial and is only charged after the trial ends, unless you cancel first. See pricing.

Methodology: a seven-phase process aligned to PTES, the OWASP Web Security Testing Guide v4.2, NIST SP 800-115, CREST testing guidance and CIS Benchmarks, covering external, internal, web application, API, cloud and identity testing. Exploitation is gated by per-tenant rules of engagement with scope enforcement that stops activity outside authorised assets. The detail is on methodology and rules of engagement.

Reporting and retest: findings carry evidence, CVSS v3.1 severity and CISA KEV prioritisation, and map to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. Reports are available in multiple formats including PDF, CSV and JSON/API. Because testing runs on a schedule, re-verification of a fixed finding happens on the next run rather than as a separately purchased retest.

Vendor security: Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified, independently audited by Atom Assurances, and the certificate is available on request. The platform is hosted in Australia on infrastructure operated by Extranet Systems and customer data is stored in Australia. Authorised personnel in our Bahrain and Egypt offices may access customer data where necessary to operate, support and secure the platform. Every customer runs in an isolated environment with its own database, retention runs from 1 year to 7 years by plan with 365-day audit logs, and a signable data processing agreement is available. See Trust Centre and DPA.