The cost of a penetration test is driven by effort: how many systems are in scope, what type of test you need, how much the testers are told in advance, how deep they go, and what you need from the report and retest. Most providers estimate that effort in tester days, so anything that adds days adds cost.
That is why two quotes for “a pen test” can differ widely, and why a credible provider will not commit to a fixed price until it understands what you want tested and why. This article explains each cost driver so you can scope sensibly and compare quotes on a like-for-like basis. It does not cover Falx prices: we quote each test after scoping.
Executive Summary & Key Takeaways
- Penetration testing is priced on effort, usually measured in tester days, so scope is the biggest lever on cost.
- The number and complexity of targets matters far more than the size of your organisation.
- Grey box testing, where testers get credentials and some documentation, usually gives the best coverage for the time spent.
- A fixed quote is only as reliable as the scoping behind it. Vague scope leads to padded quotes or mid-test change requests.
- Retests, reporting requirements and testing windows are real cost items, so agree them before work starts.
Why penetration testing is priced on effort
A penetration test is skilled manual work. Tools help, but most of the value comes from a person exploring how weaknesses combine, and that takes time. The NCSC’s guidance on commissioning a test says the output of scoping should state the technical boundaries of the test, the types of test expected, and “the timeframe and the amount of effort necessary to deliver the testing”, which is “usually given in terms of resource days” (NCSC, retrieved 27 October 2026).
Providers then price that effort in one of two ways. Some quote days multiplied by a day rate. Others convert the agreed scope into a fixed price. Either way, the number underneath is an estimate of how many tester days the work needs. If you want the wider picture of day rate and fixed scope pricing across security services, see how cyber security services are priced.
The main cost drivers
Number and complexity of targets
What counts is not how big your business is, but how much there is to test and how complicated it is.
- Infrastructure: the number of live internet-facing hosts, internal network ranges and sites. Scoping by live hosts rather than whole address ranges usually gives a more accurate estimate.
- Web applications: the number of user roles, functions and business workflows. An application with five user roles and a payments flow takes far longer than a brochure site with a contact form.
- APIs: the number of endpoints, the authentication methods in use and whether documentation such as an API specification exists.
- Cloud: the number of accounts, subscriptions or projects, and the services running in them.
- Mobile apps: iOS and Android versions are normally tested separately, as are their back-end APIs.
Type of test
Different tests answer different questions and take different amounts of time. An external infrastructure test is usually shorter than a full web application test. Social engineering and red team exercises are goal-based and run over longer periods. At the far end, regulator-led schemes for systemically important financial firms are major projects: the Bank of England’s CBEST guide puts the average assessment at around 9 to 12 months (Bank of England, retrieved 27 October 2026). If you are unsure which test fits your situation, read which type of penetration test do we need.
How much the testers know
The NCSC describes a spectrum from “open box” testing, where full information is shared, to “closed box” testing, where none is. It notes that with closed box testing “the lack of information can also result in vulnerabilities remaining undiscovered in the time allocated for testing” (NCSC, retrieved 27 October 2026).
| model | What testers get | What it models | Effect on effort |
|---|---|---|---|
| Black box | Little or nothing beyond a target name or address | An outside attacker with no inside knowledge | Days go on discovery; coverage per day is lower |
| Grey box | Test accounts, user roles, some documentation | A user, partner or attacker with stolen credentials | Usually the best coverage for the time spent |
| White box | Architecture, configuration and sometimes source code | A thorough review with full context | Finds the most per day, but more material to review |
Black box sounds more realistic, but real attackers are not limited to a week. In our experience, grey box is the sensible default for most applications.
Depth of testing
A light test that confirms known weaknesses costs less than one that tries to exploit them, chain them together and probe business logic. Depth is where cheaper quotes often differ: fewer days on the same scope usually means less manual work. Ask each provider what proportion of the time is manual testing.
Environment and constraints
Constraints add time. The NCSC lists out-of-hours testing and critical systems needing special handling as things to raise during scoping (NCSC, retrieved 27 October 2026). Internal tests may need someone on site or a remote testing device. Cloud providers set their own rules: AWS allows testing of listed services without prior approval, but simulated events such as phishing campaigns or command and control activity need a request submitted at least two weeks before the start date (AWS, retrieved 27 October 2026). None of this is a reason to avoid testing, but it affects scheduling and effort.
Reporting and compliance needs
A standard report with an executive summary and technical findings is usually included. Extra requirements add time: findings mapped to a specific framework, a separate board summary, or a set scoring method. The NCSC gives examples such as “the inclusion of CVSS scores or use of CHECK severity levels” (NCSC, retrieved 27 October 2026). Compliance can also widen scope. PCI DSS v4.0.1 requirement 11.4.5, for example, requires segmentation controls to be tested if you use segmentation to reduce the scope of your card data environment (PCI SSC, retrieved 27 October 2026).
Retests
Once fixes are in, a retest confirms they worked. Some frameworks expect it: PCI DSS v4.0.1 requirement 11.4.4 says exploitable vulnerabilities must be corrected and “penetration testing is repeated to verify the corrections” (PCI SSC, retrieved 27 October 2026). Check whether a quote includes a retest, how many days it covers and how long after the test you can use it.
Why fixed quotes depend on scoping
A fixed quote is a promise to deliver a defined piece of work for a set price. If the definition is loose, the provider either adds contingency to cover the unknowns or prices tightly and raises change requests later. Neither helps you.
The NCSC describes what happens when testers find systems outside the agreed scope that could affect the systems in scope: the team may suggest a change to scope, “which is likely to alter testing time frames and cost”, or record the exclusion as a limitation on testing (NCSC, retrieved 27 October 2026). Good scoping reduces those surprises.
You can make scoping faster and quotes more accurate by preparing:
- a list of the systems, applications and environments you want tested, with live hosts rather than whole ranges
- the user roles involved and whether you can provide test accounts
- API documentation and any architecture diagrams you are happy to share
- your most recent vulnerability scan and previous penetration test report (the NCSC recommends sharing a current vulnerability assessment at the scoping stage)
- constraints such as testing windows, systems to avoid and change freezes
- the reason for the test, such as an audit, a customer questionnaire or a release, and what evidence you need at the end
Once you have quotes, compare them on days, the experience of the testers, what is included (debrief, retest, report format) and how the work will be done. For the wider questions about choosing a provider, see how to choose a penetration testing company.
Common mistakes
- Asking for “a pen test” with no scope, then comparing prices that cover different amounts of work.
- Choosing black box to keep it realistic, then paying for testers to spend days finding information you could have handed over.
- Leaving the retest out of the quote, then needing a second engagement to show an auditor the fixes worked.
- Scoping by whole address ranges rather than live hosts, which inflates the estimate.
- Cutting days from your most important application to fit a budget, rather than narrowing scope on lower-risk systems.
Frequently asked questions
How can we reduce the cost without reducing the value?
Narrow the scope to the systems that matter most, provide credentials and documentation so testers spend less time on discovery, and fix known issues from your own scans before the test. Testers then spend their days on issues you could not find yourselves, which is the part you are paying for.
Why do quotes for the same test vary so much?
Usually because the quotes describe different work. One may assume more manual testing, more senior testers or a retest, while another assumes mostly automated checks. Ask each provider to state the number of days, who will do the work and what is included, then compare.
Does testing in production or out of hours cost more?
It can. Out-of-hours work and extra care around fragile systems take more time to plan and run. Testing a staging environment that mirrors production can avoid some of these constraints, as long as it is genuinely representative.
Should we test everything at once or in stages?
Either can work. A single larger test gives you one report and one retest. Staged testing spreads cost and lets you test each system when it changes, such as before a major release. The right choice depends on your release cycle and the evidence you need.
Getting started
The quickest route to an accurate price is a clear scope: what you want tested, why, and what you need at the end. Our penetration testing service starts with exactly that conversation, and you get a fixed price before any testing begins.
If you would like help working out what to include, talk to our team.
Jared Henderson
Writing about cyber security and technology at Falx.
