Automated scanners are useful. We use them too. They can cover a lot of ground quickly and surface known weaknesses worth investigating.
A penetration test starts where the scanner stops: validating what is real, looking for what automation missed, chaining weaknesses together, and determining what an attacker could actually accomplish.
We routinely see organizations buy what they believe is a penetration test and receive little more than automated vulnerability output wrapped in a polished report.
The problem is not just wasted money. It is the false sense of security that can follow. A clean scanner report does not prove there is no attack path. It proves the scanner did not report one.
Both have value. They answer different questions.
This is a realistic, hypothetical attack path. Not every cross-site scripting (XSS) finding leads to account compromise. The point is to show the difference between identifying a weakness and investigating what that weakness could actually enable.
Stored XSS
The application appears vulnerable to cross-site scripting.
Can the payload execute in someone else's browser?
Can that browser context expose or abuse privileged access?
What sensitive functions become available once that access is obtained?
Can a new privileged account or another durable foothold be created?
That outcome is not guaranteed. Finding out whether the path exists is the work.
If a large firm quotes $5,000 for a one-week penetration test, the price alone does not tell you whether the work is good or bad. It should make you ask where the time goes.
Across a 40-hour week, that is $125 per hour before accounting for anything else required to deliver the engagement.
Project management, meetings, reporting, quality assurance, internal coordination, sales and administrative overhead, tooling, benefits, and margin all come from the same fee.
Cheap does not automatically mean bad. Expensive does not automatically mean good. But if the economics do not support meaningful tester time, ask whether you are buying a penetration test or a vulnerability scan with a penetration-testing label.
The goal is not to make testing as inexpensive as possible. It is to spend enough time testing the environment to learn something useful before an attacker does.
A penetration test is always constrained by an engagement window. An attacker is not working from your statement of work or trying to finish by Friday.
Someone determined to get in can spend far longer enumerating, testing assumptions, changing techniques, and waiting for an opportunity. The penetration tester has to compress as much of that adversarial process as possible into the time available.
If a scanner, script, or AI-assisted workflow can surface a likely weakness, enumerate a target, or eliminate a dead end faster, that leaves more of the engagement for manual investigation.
One forgotten service. One authorization mistake. One reusable credential. One weakness that becomes something more when combined with another. Defenders have to account for every meaningful path they can find.
Artificial intelligence can make security testing faster and more capable. We use it where it helps. Like scanners and custom tooling, its job is to accelerate the work that can be accelerated so the tester can spend more time on the work that requires judgment.
Generating test ideas, creating payload variations, analyzing responses, correlating information, and accelerating repetitive work.
Understanding context, recognizing unusual trust relationships, choosing which path is worth pursuing, and adapting when assumptions fail.
Attackers will use scanners and AI too. They will also improvise, chain weaknesses, test assumptions, and keep going when the obvious technique fails.
We have entered environments that had recently received what was effectively a clean bill of health from a prior assessment and reached Domain Admin roughly 15 minutes into our own testing.
That does not prove every prior tester was incompetent, and it does not mean automation has no value. It means the previous result did not identify the attack path that was actually there.
Anonymized example from our testing experience. Client and provider details are intentionally omitted.Tool names and methodology language are easy to put in a proposal. The useful questions expose how much actual testing is behind them.
Our penetration testing vendor guide and scorecard includes questions covering manual testing, staffing, tester access, exploitability, reporting, and post-engagement support.
You are paying to understand what an attacker can actually do with them, what the tools missed, how weaknesses connect, and what deserves your attention first.