The price range is wide because the word covers four different products. Knowing which one you are buying is most of the value.
Ask three firms to quote for a penetration test and the prices may differ by a factor of five. That is not because some of them are overcharging. It is because "penetration test" describes at least four distinct products and nobody agreed which one you were asking about.
The four things sold under one name
The distinction that matters commercially is between automated and human. A vulnerability scan is a tool run against your systems with a report attached. It is genuinely useful, it should be running monthly, and it costs a small fraction of a human test. It also produces false positives, misses anything requiring reasoning, and cannot chain two minor issues into a serious one.
If a quote is dramatically cheaper than the others, the first question is how many days of human effort it includes. Sometimes the honest answer is none, and the deliverable is a scan report with a cover page.
What moves the price
Days of tester time. This is essentially the whole cost model. A small external test might be two to three days. An internal test of a mid-sized network is five to ten. A red team is weeks. Ask for the number of days, not just the price, because it makes quotes comparable instantly.
Scope size. Number of external addresses, number of applications, size of the internal network, whether cloud environments are included.
Credentialed or not. A test with credentials finds considerably more per day, because the tester is not spending time on the easy part. For most organisations, credentialed testing is better value, and the uncredentialed version answers a question you can mostly answer yourself.
Retest. Whether a verification pass after you fix things is included. It should be. Negotiating it afterwards costs more.
Seniority and certification. A test is only as good as the person doing it, and there is a wide range. Ask who specifically will do the work and what they hold.
As a rough orientation for the US mid-market in 2026: an external test of a modest internet footprint is usually a four-figure engagement, an internal test of a typical mid-sized network lands in the low five figures, a web application test depends almost entirely on the application's complexity, and a red team starts well above that. Use these to spot outliers rather than to budget; get a scoped quote.
Scoping, which is where value is won or lost
The question at the top of that list does most of the work. "Are we able to be broken into from the internet" and "if somebody gets a foothold, how far do they get" are different tests with different prices and different value. Most organisations that have never tested should ask the first. Most organisations that have tested externally twice and fixed the findings should move to the second, because that is where the unflattering discoveries are.
Two scoping decisions worth thinking about properly.
Tell or do not tell. If your IT team knows the test is happening, you are testing your defences. If only two people know, you are also testing your detection. The second is more informative and requires an authorisation letter and a stop condition, so that nobody calls the police.
Production or a copy. Testing production is realistic and carries risk. Testing a replica is safe and may not reflect reality, because replicas drift. Our usual advice is production, with a named emergency contact on both sides and an agreed stop condition in writing.
Reading the report
Three parts matter and one does not.
The executive summary should be readable by your board and should say what an attacker could actually achieve, not how many findings were rated high.
The attack narrative is the most valuable section and the one that distinguishes a good firm. It describes the path: this led to that, which allowed this. A report that is only a list of findings is a scan report with better formatting.
The findings, each with reproduction steps and a specific remediation. "Implement defence in depth" is not a remediation.
What does not matter much: the total count, and the severity ratings in isolation. Severity is contextual, and a medium finding on your internet-facing authentication portal may matter more than a high on an internal test server.
What to do with the findings
The failure mode after a test is a spreadsheet of forty items that is still open at the next test.
Sort by what the attack narrative actually used. Fix those first, regardless of their rating, because they are the ones demonstrated to be exploitable in your environment. Then everything rated critical and high. Then decide explicitly, in writing, which of the mediums and lows you are accepting and why.
Book the retest with a date before you start remediating. A deadline changes the completion rate.
Who should buy one, and who should not yet
If you have no MFA, no patching process, unmanaged devices and no backups you have tested, a penetration test will produce an expensive report telling you things you already know. Spend the money on those four first. The test is more useful once the obvious work is done, because then it finds what you could not have predicted.
If you have the basics and you are being asked by clients or an insurer to demonstrate testing, or you handle data whose loss would be material, an annual external test with a retest included is a reasonable baseline, and an internal test every second or third year adds the most new information.
