How to Buy Penetration Testing Services Without Wasting the Budget
Half of penetration test spending goes on findings a free scanner would have caught. Here is how to get the part you are actually paying for.
A penetration test is one of the few security purchases where you can spend a serious amount of money and get almost nothing useful, without ever knowing it went wrong.
The output looks the same either way: a long PDF with severity ratings and a lot of red. Telling the difference between a genuinely valuable test and an expensive scanner run takes knowing what to look for.
Do the cheap work first
The single biggest waste in penetration testing is paying human beings to find things a machine would have found for free.
If you have never run dependency scanning, never done an access review, and have no idea what is currently exposed to the internet, a penetration test will spend most of its budget documenting that. You will get a report full of known vulnerabilities in outdated libraries, which is information you could have had automatically.
Close the obvious holes first. Then the test can spend its time on the thing you are actually paying for, which is a person thinking creatively about your specific system.
Scope decides everything
"Test our application" is not a scope. It is an invitation for the tester to guess, and their guess will be shaped by what is easy rather than what matters to you.
A useful scope names what you are worried about. Can someone reach another customer's data. Can a low-privilege account escalate. Can an attacker who compromises one service move sideways into the rest. Those are questions. A good tester will answer questions.
Also decide explicitly whether it is black box, where they start with nothing, or grey box, where they get credentials and some documentation. Black box tests spend a large portion of the budget on reconnaissance, which produces an exciting narrative and less coverage. For most companies who want to actually find problems rather than simulate an attacker, grey box gives more value per pound.
The report is the product
You are not buying an attack. You are buying a document your engineers can act on.
Ask to see a sample report before signing, with the client details removed. Three things separate a good one:
Reproduction steps. Precise enough that a developer can trigger the issue themselves. If they cannot reproduce it, they cannot verify the fix.
Severity that reflects your business. A critical finding in an internal admin tool used by three people is not the same as the same finding on a public endpoint. Generic severity ratings copied from a scanner are a bad sign.
A retest included. You fix the findings, they verify. Without this, you have a list of problems and no confirmation you solved them.
The findings that matter most
Chained findings.
Any scanner produces a list of individual issues. What a skilled tester produces is a path: this low-severity information disclosure gives you a username, which combined with this weak rate limit gives you an account, which through this misconfiguration gives you everything.
None of those three findings is critical alone. Together they are the actual breach. If a report contains no chains, you probably paid a person to run a tool.
How often
Annually is the common answer and it is a compromise, not a principle.
The honest version depends on how much your system changes. A product shipping weekly is a different system every quarter, and a test from ten months ago describes something that no longer exists. A stable internal system that changes twice a year genuinely does not need testing more often than that.
Between tests, the gap is covered by automation: dependency scanning, external surface monitoring, and access reviews. Those are cheap, continuous, and catch the ordinary problems, which is most of them. That combination is how our managed cybersecurity work is structured, and where the systems being tested are ones we build or run, the fixes tend to land considerably faster.