Penetration Testing Services RFP Template

Penetration testing is bought on day rates and logos far too often, yet the value of a test depends almost entirely on the skill of the named testers, the honesty of the report and whether findings are retested. This template is a ready-to-issue request for proposal for penetration testing services, either a single engagement or a framework of call-off tests over a contract term. Its numbered requirements cover provider accreditation (including CREST and the NCSC CHECK scheme), tester qualifications, methodology, safe testing, evidence and data handling, reporting, retesting, insurance and commercials, each written so that the answer can be checked and scored. It is vendor-neutral and written for security managers, procurement and evaluation panels. For what the market offers, read the Penetration Testing Provider Buyer's Guide; for defining what is in scope, the Penetration Test Scoping Checklist.

How to use this template

Replace text in square brackets, such as [Organisation], [systems] and [number], with your own details. Delete requirements and test types that do not apply.
Each requirement has an ID (for example PT-RPT-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
Weights, volumes and timings in brackets are illustrative, not benchmarks. Set them before issue and do not change them after responses arrive.
Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
For red team or threat-led engagements, add the Red Team Rules of Engagement Template as a schedule. Regulated threat-led schemes have their own procurement rules: see the Threat-Led Penetration Testing Guide.

1. Purpose and scope

[Organisation] invites proposals for penetration testing services. The aim is independent assurance that [systems] resist realistic attack, findings that are accurate and actionable, and verification that remediation works. Testing supports, and does not replace, [Organisation]'s own vulnerability management.

Engagement model: [single engagement] or [framework of call-off tests for [number] years, estimated [number] tests per year].
Test types in scope: [external infrastructure]; [internal infrastructure and Active Directory]; [web applications]; [APIs]; [mobile applications]; [cloud configuration in named providers]; [wireless]; [social engineering]; [OT environments]; [assumed-breach scenarios].
Out of scope: [denial-of-service testing]; [third-party hosted systems without written permission]; [physical intrusion, unless listed].
Drivers: [regulatory or contractual requirement, for example payment card or public sector obligations]; [new system go-live]; [annual assurance cycle]; [cyber insurance condition].

2. Organisation background and test environment

Item	[Organisation] value
External attack surface	[number] public IP addresses and domains; [number] internet-facing applications
Internal estate	[number] sites; [number] servers and endpoints; directory [type and number of domains]
Applications and APIs	[number]; authentication methods; roles to be tested
Cloud	[providers]; [number] accounts, subscriptions or projects
Unusual technology	[mainframe, OT, bespoke hardware, specialist protocols]
Testing windows and constraints	[business hours or out of hours; change freezes; fragile systems]
Environments available	[production, pre-production, test]; [test accounts provided]
Security monitoring	[in-house SOC or MDR]; [whether detection and response is to be assessed]

3. Instructions to bidders

Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; presentations and sample report review [dates]; decision [date]; first test [date].
Single point of contact: [name, email].
Sample report: submit one redacted report from a comparable engagement. It is scored under PT-RPT.
Named team: name the testers proposed, with qualifications and experience. Substitution after award requires [Organisation]'s written approval and an equivalent replacement.
Response scale: for each requirement state met, partly met (explain) or not met. Claims must be supported by evidence such as certificates, policies or a sample.

4. Provider requirements

4.1 Accreditation and assurance

ID	Requirement	Type
PT-ACC-01	Holds current company accreditation for penetration testing from [CREST or equivalent body]; provide the certificate and the date of the last reassessment.	[M or S]
PT-ACC-02	For [central government, public sector or critical national infrastructure] systems: is an NCSC CHECK company and will deliver CHECK engagements with personnel who meet the current CHECK requirements.	[M where applicable]
PT-ACC-03	Holds [ISO/IEC 27001 certification] covering the testing service, or provides an equivalent independent assurance report.	S
PT-ACC-04	Holds accreditation for [threat-led schemes, for example CBEST, TIBER-EU or STAR] if those engagements are in scope.	I

4.2 Testers

ID	Requirement	Type
PT-TST-01	Every tester holds a recognised practical penetration testing qualification [list acceptable qualifications]; the test lead holds a senior-level qualification.	M
PT-TST-02	Testers are directly employed or named subcontractors; state the proportion and how subcontractors are vetted and bound by the same obligations.	M
PT-TST-03	Testers hold [national security vetting level] where required, and pass [Organisation]'s background checks.	[M where applicable]
PT-TST-04	Demonstrated experience in each test type in section 1, and in [unusual technology]; provide anonymised examples.	S

See the Practical Red Team Certifications Guide.

4.3 Methodology and safe testing

ID	Requirement	Type
PT-MTH-01	Describe the methodology for each test type and the public standards it follows, for example the OWASP Web Security Testing Guide for web applications, OWASP ASVS levels as a coverage reference, and NIST SP 800-115 for infrastructure.	S
PT-MTH-02	Testing is predominantly manual and expert-led; state the proportion of effort that is automated scanning and how scanner output is validated before reporting.	S
PT-MTH-03	Describe the scoping process, including participation of [Organisation] risk owners and technical staff and use of [Organisation]'s current vulnerability assessment.	S
PT-MTH-04	Testing starts only after a signed authorisation covering targets, dates, source IP addresses and contacts; testers stop and escalate immediately on finding a critical vulnerability, signs of a prior compromise, or impact on service.	M
PT-MTH-05	Describe controls to avoid harm: rate limits, avoidance of destructive tests unless approved, handling of fragile systems, and rollback of any changes made (accounts, files, configuration).	M
PT-MTH-06	Covers identity attack paths where in scope: directory misconfigurations, service account and API key exposure, cloud role abuse and token theft.	S

See the Penetration Testing Guide, the Cloud Penetration Testing Guide and the API Penetration Testing Guide.

4.4 Evidence and data handling

ID	Requirement	Type
PT-DAT-01	Test data, credentials obtained, screenshots and reports are stored encrypted in [region], accessible only to the named team, and securely deleted within [days] of report acceptance, with a written confirmation.	M
PT-DAT-02	Credentials and secrets discovered during testing are reported through a secure channel immediately and never reused outside the authorised scope.	M
PT-DAT-03	Testing infrastructure (source hosts, cloud accounts, command-and-control for assumed-breach tests) is owned and controlled by the bidder, hardened, and its IP addresses provided in advance.	M
PT-DAT-04	Report delivery uses [secure portal or encrypted transfer], not unencrypted email.	M

4.5 Reporting

ID	Requirement	Type
PT-RPT-01	Report includes an executive summary in plain language, scope and limitations, methodology, and each finding with description, affected assets, evidence, risk rating and specific remediation.	M
PT-RPT-02	Risk ratings use [Organisation]'s scheme: [HIGH, MEDIUM, LOW, INFORMATIONAL as required for CHECK reports, with CVSS v4.0 as supporting data] and explain any deviation.	M
PT-RPT-03	Gives an opinion on the accuracy and completeness of [Organisation]'s own vulnerability assessment for the systems tested.	S
PT-RPT-04	Findings are delivered in a machine-readable format [CSV, JSON or direct integration with [vulnerability management tool]] as well as the report.	S
PT-RPT-05	Draft report within [5] working days of test end, final within [5] working days of comments; a debrief with technical and risk owners is included.	S
PT-RPT-06	Critical findings are reported by phone and secure message within [hours] of discovery, not held for the report.	M

4.6 Retesting

ID	Requirement	Type
PT-RET-01	Retesting of [high and critical / all] findings within [number] days of request is included in the price, and the report is reissued with each finding's status.	S
PT-RET-02	Retest is performed by a member of the original team where possible.	I

5. Contractual, legal and insurance requirements

ID	Requirement	Type
PT-LEG-01	Holds professional indemnity insurance of at least [amount], public liability of at least [amount] and cyber insurance of at least [amount]; provide certificates.	M
PT-LEG-02	Accepts [Organisation]'s confidentiality terms and a data processing agreement where personal data may be accessed.	M
PT-LEG-03	Will not test systems owned or hosted by third parties without written permission from the owner, which [Organisation] will obtain; follows cloud providers' published testing policies.	M
PT-LEG-04	Discloses conflicts of interest, including remediation products or services the bidder sells and any testing of [Organisation]'s competitors that would create a conflict.	M
PT-LEG-05	Provides its own security incident history for the last three years and its policy for notifying clients of an incident affecting client data.	M

6. Service management

Scheduling: lead time to start a call-off test, and process for urgent tests at [notice period].
Account management: named engagement manager; quarterly review of findings trends across tests.
Quality assurance: describe the technical review each report receives before release, and by whom.
References: [two or three] clients of similar size and sector, at least one using the service for [number] years.

7. Commercials

Cost element	What to state
Rate card	Day rate by grade (tester, senior, lead) and for out-of-hours work
Fixed-price scenarios	Price and days for [three] defined scoping scenarios supplied by [Organisation]
Included items	Scoping, report, debrief, retest, expenses
Cancellation and rescheduling	Notice period and charges
Price stability	Rate fixed for [years]; indexation thereafter

8. Evaluation method and pilot

Criterion	Weight	Evidence
Testers' qualifications and experience (4.1, 4.2)	[25%]	Certificates, CVs, interview with proposed lead
Methodology and safe testing (4.3)	[20%]	Response, presentation
Report quality (4.5)	[20%]	Sample report scored against PT-RPT-01 to PT-RPT-04
Data handling, legal and insurance (4.4, 5)	[10%]	Policies, certificates
Retest and service (4.6, 6)	[5%]	Response, references
Price (7)	[20%]	Fixed-price scenarios, not day rate alone

Scored requirements use 0 to 5: 0 not met; 3 met with gaps; 5 fully met with evidence. A mandatory requirement not met excludes the bid. In place of a product proof of concept, [Organisation] may run a paid pilot test with the top [two] bidders:

A small, defined scope (for example one web application and its API) with [Organisation] planting [number] known issues, such as a test account with weak authorisation and an exposed test API key.
Score which planted and unplanted issues were found, false positives reported and how critical findings were escalated.
Score the report against PT-RPT-01 to PT-RPT-04 and the debrief.
Request a retest of fixed issues and score timeliness.
Confirm data deletion under PT-DAT-01 at the end.

Implementation guidance

This section is for the evaluation panel, not for bidders.

Score people, not brands: the NCSC notes that test quality depends heavily on the testers' skill because tests cannot be fully scripted. Interview the proposed lead and hold the bidder to the named team.
Compare like for like: day rates hide very different effort estimates. The fixed-price scenarios in section 7 are the only fair comparison.
Read the sample report as the reader will: ask a system owner whether they could fix each finding from the text alone. Reports full of unvalidated scanner output score low.
Know what the testers will find: share your vulnerability assessment and measure the gap; a test that finds only what your scanner already knew adds little.
Manage test identities: accounts, API keys and VPN access issued to testers are non-human or temporary identities. Issue them with expiry, record them and revoke them at the end. See the Service Account Security Guide.
Close the loop: feed findings into vulnerability management and track retest outcomes as a metric. See the CIS Control 18 Penetration Testing Guide.

Requirement group	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Independent penetration testing (4.1 to 4.3)	CA-8, CA-8(1)	ID.RA-01	A.8.8 Management of technical vulnerabilities
Red team and threat-led tests	CA-8(2)	ID.IM-02	A.8.8 Management of technical vulnerabilities
Reporting and remediation (4.5, 4.6)	RA-5	ID.RA-01, ID.IM-02	A.8.8 Management of technical vulnerabilities
Supplier due diligence and contract (4.4, 5)	SA-9, SR-6	GV.SC-06	A.5.20 Addressing information security within supplier agreements

Penetration Testing Services RFP Template: Requirements, Weighted Scoring and Pilot Plan