Contents
- The unit of measure: the testing day
- The six factors that decide the effort
- Estimate the effort
- Order of magnitude, by test type
- Black, grey or white box: which costs more
- How to compare two quotes
- How to cut cost without cutting value
- How often to repeat it, and what it means for the budget
- Frequently asked questions
- Sources
In 30 seconds
- The unit of measure is the testing day (person-day): a quote without a number of days cannot be compared with anything.
- Six factors decide the effort: scope, complexity, roles, the information given to the tester, the compliance requirement and execution constraints.
- A test without information risks leaving vulnerabilities undiscovered in the time allocated — NCSC guidance says so too 1.
- The report must say how to resolve each issue 1, and the retest confirms the fixes — PCI DSS requires it explicitly 5.
- The second cycle usually costs less: the scope is already mapped.
The unit of measure: the testing day
The question “how much does a pentest cost?” almost always gets the answer “it depends”. It is not an evasion: a penetration test is paid for by a specialist’s effort. Serious quotes are all built the same way — estimate the number of testing person-days, add reporting and the retest, and multiply by the supplier’s day rate. That is why two very different quotes can both be right: one estimated five days, the other fifteen, because they understood the scope differently.
Scope is fixed before price. NCSC guidance says the scoping exercise should end in a document stating, among other things, the technical boundaries of the test 1; NIST’s technical testing guide also puts planning ahead of the testing itself 2.
The six factors that decide the effort
- Scope size
How many IP addresses, applications, domains and subdomains, mobile apps.
- Functional complexity
An app with three screens and one with eighty are not tested in the same time, even on the same server.
- Roles and flows
Every user role multiplies the authorisation tests: who can see and change what.
- Information given to the tester
Black, grey or white box: with documentation and access, time moves from discovery to real testing.
- Compliance requirement
A test for PCI DSS, ISO 27001 or DORA needs structure, evidence and a documented retest — extra reporting time.
- Execution constraints
Testing only outside working hours, sensitive production, agreements with cloud providers.
Estimate the effort
Estimate the effort for your scope
Indicative, based on our typical projects. The result is in person-days, not money: that is how two quotes are compared fairly.
0 person-days in total
- Testing
- 0
- Report
- 0
- Retest
- 0
What most often increases the effort here: Many forgotten subdomains in scopeNumber of roles and business logicNumber of live hosts, not allocated addressesNumber of domains, trusts, branchesThe backend API, if it has not been tested beforeNumber of accounts, regions and services usedNumber of scenarios and tailored pretexts
- Small scope: the range narrows towards the low end.
- Medium scope: the middle of the typical range.
- Large scope: the range moves towards the high end.
- Black box: roughly a quarter more, spent on discovery — mapping what you already know.
- Grey box: the base range; time goes on testing, not on guessing the architecture.
- White box: the same days, moved from discovery to real testing — deeper findings for the same effort.
- Compliance report: one extra reporting day, for scope, methodology, limitations and evidence in the structure the auditor expects.
- Retest: verifying the fixes, usually about a fifth of the testing days.
Order of magnitude, by test type
The ranges below come from our typical projects: they are testing effort, not prices. Use them as a sanity check on any quote: if someone promises a full test of a complex web application in two days, you are not comparing prices but different depths.
| Test type | Typical testing effort | What most often increases it |
|---|---|---|
| Small web application (site, simple portal) | 3–5 days | Many forgotten subdomains in scope |
| Complex web application (SaaS, banking, multi-role) | 8–20 days | Number of roles and business logic |
| External infrastructure | 3–8 days | Number of live hosts, not allocated addresses |
| Internal infrastructure / Active Directory | 5–15 days | Number of domains, trusts, branches |
| Mobile application (one platform) | 5–10 days | The backend API, if it has not been tested before |
| Cloud environment (configuration and identities) | 4–10 days | Number of accounts, regions and services used |
| Social engineering / phishing | 3–8 days | Number of scenarios and tailored pretexts |
Black, grey or white box: which costs more
Counter-intuitively, black box usually costs more for the same result. Without information, part of the paid days go on discovery — mapping what you already know. NCSC says it plainly: lack of information can leave some vulnerabilities undiscovered in the time allocated for testing 1.
Grey box — test accounts for each role and basic documentation — is the usual choice for web applications: the OWASP testing guide (WSTG, stable version 4.2) has whole chapters of authorisation and business logic tests that need accounts 3. Black box makes sense when you want exactly the view of an outside attacker with no inside knowledge.
How to compare two quotes
Price differences between suppliers rarely come from the day rate; they come from what is delivered. A one-day “pentest” of a complex application is almost always an automated scan with the report exported. NCSC describes a penetration test as a way of gaining assurance, not as the primary method for finding vulnerabilities 1 — and assurance comes from manual work.
- Manual testing of business logic — scanners do not cover it.
- Retest included or billed separately — without it, the real cost is higher than quoted.
- Who writes the report: a tool-generated report and one written by the tester look completely different; the report must say how to resolve each issue 1.
- Report structure for audits: scope, methodology, limitations, findings and a separate retest report with both test dates 4.
- Severity justified in context, not just by the CVSS score.
How to cut cost without cutting value
- Give access and documentation. Every hour the tester spends guessing the architecture is an hour paid for discovery, not testing.
- Narrow the scope to what matters: the systems that hold data and revenue, not the whole inventory.
- Run your own scan first and fix what it finds. Do not pay a specialist to find a missing patch.
- Plan recurring testing: the effort drops in the second cycle because the scope is already known.
How often to repeat it, and what it means for the budget
PCI DSS requires internal and external penetration tests at least every 12 months and after any significant change, plus repeating the test to confirm the fixes 5. Outside regulation, NCSC notes it is not uncommon for a year or more to pass between tests 1. Our recommendation: yearly and after major changes — and a recurring programme makes use of the shorter second cycle.
Frequently asked questions
How much does a penetration test cost on average?
Why do suppliers not publish fixed prices?
Black box or white box — which is more expensive?
Is the retest after remediation paid separately?
How often should the test be repeated?
Sources
Every statement about a law or standard links to its official source. Consulted on the date shown.
- NCSC — Penetration testing (guidance)ncsc.gov.uk · accessed 23 October 2026
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (2008)csrc.nist.gov · accessed 23 October 2026
- OWASP Web Security Testing Guide (WSTG)owasp.org · accessed 23 October 2026
- PCI SSC — Penetration Testing Guidance v1.1 (2017)pcisecuritystandards.org · accessed 23 October 2026
- PCI DSS v4.0.1 — SAQ D for Service Providers, r2 (text of requirement 11.4)pcisecuritystandards.org · accessed 23 October 2026
About the authors
The guides are written by the team that does the testing, not a marketing department. We update them when the law, the standard or what we see in testing changes.