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.
Consider an illustrative attack path. A scanner may correctly identify cross-site scripting (XSS). A tester keeps asking what that weakness makes possible.
Stored XSSAutomation identifies a potentially exploitable weakness.
Can the payload execute in an administrator's browser and expose or abuse the session?
What functionality becomes available with that access?
Can a new privileged account or another durable foothold be created?
Not every XSS finding leads to this outcome. That is exactly why the weakness has to be investigated in the context of the application.
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.
Divided across a 40-hour workweek, that is $125 per hour before accounting for anything else involved in delivering the engagement.
Project management, kickoff and status calls, reporting, quality assurance, internal coordination, sales and administrative overhead, tooling, benefits, and margin all have to come from somewhere.
Cheap does not automatically mean bad. Expensive does not automatically mean good. But if the economics do not support meaningful tester time, it is reasonable to ask whether you are buying a penetration test or a vulnerability scan with a penetration-testing label.
Artificial intelligence can make security testing faster and more capable. We use it where it helps. That does not remove the need for experience, judgment, or an attacker's mindset.
Generating test ideas, creating payload variations, analyzing responses, correlating information, summarizing large data sets, and accelerating repetitive work.
Understanding context, recognizing unusual trust relationships, deciding which hypothesis is worth pursuing, adapting when assumptions fail, and knowing how far a path can realistically go.
Attackers will use scanners. Attackers will use AI. They will also improvise, chain weaknesses, test assumptions, and keep going when the first technique does not work.
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.