How Much Does a Penetration Test Cost? Drivers and Budgets

The price of a penetration test is set almost entirely by how many skilled tester days the provider needs to cover your scope, so the honest answer to "how much does a pentest cost" is "it depends on what you ask them to test, how deeply and how often". Published price lists rarely survive contact with a real estate: two quotes for "a web application test" can differ by a factor of several because one assumes five user roles and an API, the other a brochure site. This guide explains the drivers that move the effort estimate, how a quote is built from days, grades and fixed items, how to budget a year of testing rather than a single test, and where buyers overspend or underspend. It deliberately quotes no market prices, because rates vary by country, scheme and provider and change every year; instead it gives you the model to estimate and challenge any quote. It is for security managers, budget holders and procurement teams. Choosing the provider is covered in the Penetration Testing Provider Buyer's Guide; agreeing a single engagement's boundaries in the Penetration Test Scoping Checklist.

Key takeaways

Price equals days times rate, plus fixed items. Almost every quote reduces to tester days by grade, multiplied by a day rate, plus reporting, project management, retest and expenses. Ask for that breakdown and every quote becomes comparable.
Scope drives days, not company size. Number of roles, endpoints, IP ranges, sites, segmentation boundaries and unusual technology set the effort. Headcount and turnover do not.
The cheapest quote is usually the fewest manual days. When one bid is far below the others, check the days before you check the rate; a test that is mostly automated scanning is a different product.
Budget the programme, not the test. Annual and post-change obligations, retests, new systems going live and at least one unplanned test make up the real yearly cost.
The biggest saving is preparation. Working test accounts, a stable environment, a clear scope and a known vulnerability baseline stop paid days being lost to waiting and to findings your scanner already had.

How a penetration test quote is built

The NCSC says the output of scoping should define the technical boundaries, the test types, the timeframe and the effort, which it notes is usually expressed in resource days, and that changes to scope are likely to alter timeframes and cost. Every credible quote can therefore be decomposed into the same parts. If a provider will not show them, you cannot tell what you are buying.

Component	What it covers	What to ask
Testing days by grade	Hands-on testing by junior, senior and lead testers	Days per test type and per grade; who is named for each grade
Day rate per grade	The provider's charge per tester day, sometimes higher for out-of-hours or cleared staff	Rate card for each grade, out-of-hours uplift and vetting uplift
Scoping and preparation	Scoping call, rules of engagement, test account checks	Whether it is free, fixed or charged in days
Reporting and QA	Writing, technical review, executive summary	Report days shown separately from testing days
Project management and debrief	Coordination, status calls, findings walkthrough	Fixed fee or days; whether a debrief is included
Retest	Verifying fixes for agreed findings	Days included, time window for using them, scope (critical and high only or all)
Expenses and travel	On-site work, internal tests, physical or wireless testing	Fixed or at cost; remote alternatives
Cancellation and rescheduling	Charges if the test slips because the client is not ready	Notice period and fee; whether days can be moved

Penetration testing as a service (PTaaS) platforms often price per application, per asset or by subscription credits rather than days. The same question still applies: how many hours of manual testing sit behind each unit, and what is automated. Ask the platform to translate one of your scoping scenarios into hours so it can be set beside consultancy bids.

The cost drivers, by test type

Effort estimates are driven by measurable features of the target. Give providers these numbers in writing; a scoping questionnaire answered vaguely produces a padded quote or a later change request. Test types and methods are explained in the Penetration Testing Guide; the table below covers only what moves the day count.

Test type	Main effort drivers	Typical cost surprises
External infrastructure	Number of live public IP addresses and hosts, exposed services, VPN and remote access gateways	Address ranges that turn out to contain many more live hosts than declared
Internal infrastructure and Active Directory	Sites and network segments, number of domains and forests, whether an assumed-breach starting point is given, segmentation boundaries to verify	Travel to several sites; segmentation testing of each boundary charged separately
Web application	Number of user roles, distinct functions and workflows, authentication methods, file upload and payment flows, multi-tenancy	Roles added late; testers unable to log in for the first day
API	Number of endpoints and methods, authentication schemes, availability of a specification (OpenAPI) and example requests	No documentation, so testers spend paid days discovering endpoints
Mobile application	Platforms (iOS, Android), whether back-end APIs are in scope, anti-tampering controls	Each platform priced as a separate test
Cloud configuration	Number of accounts, subscriptions or projects, services in use, identity configuration	Read-only access not ready on day one
Wireless, physical and social engineering	Sites, buildings, number of staff targeted, travel	Out-of-hours and travel uplifts
OT and specialist technology	Fragile systems, safety constraints, specialist skills, testing windows	Fewer qualified testers and slower, more cautious testing

Cross-cutting drivers apply to every type:

Depth of approach: black box testing spends days on discovery that a grey box test with documentation and credentials spends on finding weaknesses. Giving testers information usually improves value per day.
Environment: the PCI SSC penetration testing guidance notes that testing production during business hours may affect operations and that a separate, equivalent environment may be used, but exploitable issues found there must still be fixed and retested in production. Out-of-hours windows add cost.
Tester profile: CHECK engagements, national security vetting and specialist skills (OT, mainframe, hardware) narrow the pool of testers. The NCSC advises flagging unusual systems such as mainframes or bespoke hardware in the bid.
Reporting requirements: bespoke formats, several audiences, CVSS for every finding or reports mapped to a scheme add report days.
Methodology standard: a test run against a defined methodology such as the OWASP Web Security Testing Guide, or to the CREST Defensible Penetration Test specification, may need more structured evidence. CREST describes that specification as recommendations on how tests should be scoped, delivered and signed off. See Penetration Testing Methodologies Compared.

Estimating effort before you ask for quotes

Build your own rough estimate first so you can challenge bids that are far above or below it. This is an internal sizing method, not a price list.

Inventory the scope. For each target record the measurable drivers from the table above: IP addresses, roles, endpoints, sites, accounts, boundaries.
Group into test units. One web application with its API, one internal network per site, one cloud account set. Each unit is quoted separately so you can drop or defer one later.
Ask each provider for days per unit and grade, using identical written scenarios. The Penetration Testing Services RFP Template asks for fixed-price scenarios for this reason. Day rates alone hide very different effort estimates.
Add the fixed items. Report and QA days, project management, debrief, retest days and expenses, each as a separate line.
Add contingency. Hold a small reserve for scope found during testing (an unknown host, an undeclared role), agreed in advance as a change process rather than a surprise invoice.
Compare the spread. Where days for the same unit differ widely, ask each bidder to explain their assumptions. The low bid often omits roles or authenticated testing; the high bid sometimes assumes a black box approach you did not ask for.

Worked scenario: a mid-sized software company

A company with one customer-facing web application (four user roles, a public REST API with an OpenAPI file), a single office network with one Active Directory domain, and two cloud accounts asks three providers to quote. Its written scenario lists the roles, the endpoint count and the number of live external addresses. Bid A shows the fewest days but lists the API as "included" with no separate effort and no authenticated testing of two roles. Bid B shows days per unit and grade, report and retest days separately. Bid C is highest because it assumed a black box external test with full discovery. After clarifying, B and C are within a narrow range of each other; A is excluded because it was not testing the same thing. The lesson: compare day counts per unit against the same scenario before comparing totals.

Budgeting a year of testing

A single test is a project cost; testing as a control is a recurring budget line. The NCSC observes that it is not uncommon for a year or more to elapse between penetration tests and that routine security testing should continue in between, so the budget should cover both the scheduled tests and what happens around them. Link the line to your wider plan in the Security Budget and Investment Planning Guide and the Security Budget Template and Cost Model.

Budget line	Basis for the estimate	Driver or obligation
Scheduled annual tests	Test units from the inventory, sized as above	PCI DSS requires internal and external testing at least annually and after significant change; customer contracts; ISO/IEC 27001 surveillance evidence
Change-triggered tests	Number of planned go-lives, major releases and infrastructure changes on the roadmap	PCI SSC guidance leaves what counts as significant change to the entity's risk assessment
Segmentation tests	Number of segmentation methods and boundaries	PCI SSC guidance requires testing of segmentation controls where they are used to reduce scope
Retests	Retest days per test, or a pooled allowance	Remediation should be retested to confirm the fix addresses the original risk
Unplanned tests	One reserved test unit or a call-off allowance	Acquisitions, incidents, urgent customer requests
Threat-led or red team exercises	Separate engagement, scoped on objectives	Regulated schemes such as DORA threat-led penetration testing for identified financial entities
Internal effort	Staff time for scoping, test accounts, escort, remediation and retest coordination	Usually unbudgeted; often larger than expected

DORA's recitals make clear that only financial entities identified for advanced testing need threat-led penetration testing, and that microenterprises are exempt from it, so check whether you are in scope before budgeting for it. See the Threat-Led Penetration Testing Guide and the Penetration Testing Requirements Map for which rules set frequency.

Commercial models and when each fits

Model	How it is priced	Fits when	Watch for
Fixed-price single engagement	Agreed days and deliverables for one scope	One or two tests a year, stable scope	Change requests when scope was under-declared
Time and materials	Day rate times actual days	Exploratory or poorly understood scope	Open-ended cost; cap the days
Framework or call-off contract	Rate card fixed for a term, tests called off as needed	Many tests a year across teams	Rates fixed but days per test still need challenge
Pre-paid day bank	Days bought in advance, often at a lower rate	Predictable volume, flexible timing	Expiry of unused days
PTaaS subscription	Per asset, per application or credits	Frequent releases, many web and API targets	How much is manual testing versus scanning

Small organisations: one fixed-price contract that includes a retest and a debrief is usually simplest. Combine tests into one engagement where the same testers can cover them, to save repeated scoping and reporting.
Large organisations: a framework with two or three providers and a fixed rate card keeps day rates stable; the effort estimate per test remains the thing to manage. Compare days per unit across providers to spot drift.
Frequent releases: where testing is needed every sprint or month, compare subscription units with the day equivalent, and keep an annual deep manual test. See Penetration Testing vs DAST and CTEM vs Penetration Testing for what continuous tools can and cannot replace.

Getting more value per paid day

Share your vulnerability baseline: the NCSC suggests sharing your current vulnerability assessment during scoping, and says penetration testing should be a way to gain assurance in your vulnerability management, not the main way of finding vulnerabilities. Paying testers to rediscover scanner output wastes days.
Prepare before day one: working test accounts for every role, firewall allow-listing where agreed, VPN access, desk space and a technical contact available throughout. The NCSC lists these preparations explicitly.
Issue tester identities as temporary non-human access: accounts, API keys and VPN certificates given to testers should be recorded, time limited and revoked at the end. See the Service Account Security Guide.
Choose grey box where the goal allows: credentials and documentation move days from discovery to finding real weaknesses.
Bundle the retest: agree retest days and a window in the original contract rather than buying a new engagement later; PCI SSC guidance notes that a long gap between test and remediation may require a new engagement.
Use the debrief: a short walkthrough with the testers helps engineers fix correctly the first time. See How to Read a Penetration Test Report.

Common failure patterns

Buying on day rate alone: a lower rate with more days, or a higher rate with fewer, can produce the same total for very different depth. Always compare days per unit.
Under-declared scope: listing two roles when the application has six, or a /24 range "with a few hosts", leads to either a shallow test or a change request mid-engagement.
Losing paid days to readiness: broken test accounts, an environment under change, or a blocked source IP on day one burn budget with nothing to show. Readiness checks a few days before the test prevent this.
No retest in the contract: findings are fixed but never verified, or the retest is bought later at full engagement cost.
Testing the wrong thing cheaply: buying a penetration test to answer a red team question, or a red team when a vulnerability scan would do. See Red Team vs Penetration Test vs Vulnerability Scan.
Ignoring internal cost: staff time for scoping, escorting, remediation and retest coordination can exceed the invoice and is rarely budgeted.

Measuring whether the spend works

Days lost to readiness: paid days where testing could not proceed, per engagement. Target zero.
Findings not already known: share of findings that were absent from your own vulnerability assessment. The NCSC says testers should ideally find little you did not already know, so a high share points to gaps in internal processes.
Retest pass rate and time to retest: proportion of critical and high findings verified as fixed, and days from report to verified fix. See the Penetration Test Remediation Tracker Template.
Repeat findings: issues of the same class found again in the next test, which shows whether spend is buying improvement.
Effort variance: actual days against quoted days per unit, tracked across providers and years to refine your own estimates.
Coverage: share of in-scope systems tested within their required interval.

Framework mapping

Framework	Reference	Relevance to cost and budgeting
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing; CA-8(1) Independent Penetration Testing Agent or Team; CA-8(2) Red Team Exercises	Defines frequency and independence, which set recurring cost
NIST SP 800-53 Rev. 5	RA-5 Vulnerability Monitoring and Scanning	The baseline that keeps paid tester days off known issues
NIST CSF 2.0	ID.RA-01; ID.IM-02; GV.SC-05	Vulnerabilities identified and validated; improvements from tests; security requirements in supplier contracts
CIS Controls v8.1	Control 18 Penetration Testing	Programme, periodic external and internal tests and remediation; see the CIS Control 18 Penetration Testing Guide
ISO/IEC 27001:2022 Annex A	5.20 Addressing information security within supplier agreements; 8.8 Management of technical vulnerabilities	Contract terms with the testing provider; testing as vulnerability evidence
PCI DSS	Requirement 11.4 penetration testing	Annual and post-change internal, external and segmentation testing; see the PCI DSS Requirement 11 Guide

Practitioner checklist

Inventory every test target with its measurable effort drivers before requesting quotes.
Split the scope into test units that can be quoted, deferred or dropped separately.
Send every bidder identical written scoping scenarios and ask for days per unit and grade.
Require report, project management, retest and expenses as separate lines.
Compare day counts per unit before comparing totals; question any outlier.
Agree a change process and a small contingency for scope discovered during testing.
Run a readiness check of accounts, access and environment before day one.
Budget the year: scheduled, change-triggered, segmentation, retest, unplanned and internal effort.
Track days lost to readiness, findings not already known, retest pass rate and effort variance.

How Much Does a Penetration Test Cost: Drivers, Effort Estimates and Annual Budgets