Penetration testing vs. vulnerability scanning

A prospect called us last year, frustrated. They had paid a well-known vendor for what the invoice called a "penetration test," handed the report to a client who asked for one, and the client rejected it. The report was 180 pages of scanner output. No attack path, no proof anything was actually exploitable, no business context. The client's security team took one look and knew exactly what it was.

It was a vulnerability scan wearing a more expensive name.

This happens constantly, so it is worth being precise about the difference. The two activities overlap, they sometimes use the same tools, and plenty of firms blur the line on purpose because scans are cheap to run and pentests are not. But they answer different questions, and buying the wrong one wastes money and, worse, creates false confidence.

What a vulnerability scan actually does

A vulnerability scanner connects to your systems, compares what it finds against a database of known issues, and produces a list. Missing patch here, outdated TLS version there, a default credential it recognized. Good scanners are fast, they cover a lot of ground, and they are excellent at catching the obvious stuff that piles up when nobody is watching.

What a scanner cannot do is think. It does not know that the low-severity information disclosure on one host hands an attacker the exact detail they need to exploit the medium-severity issue on another. It rates each finding in isolation, against a generic severity scale, with no idea what your business does or which systems matter. It reports that a door is unlocked. It does not walk through the door, into the next room, and out with your customer database.

That is not a criticism. Scanning is a control you should run continuously, ideally automated and feeding a real remediation process. It just is not a penetration test.

What a penetration test adds

A penetration test is a person, usually a few of them, deliberately trying to break in the way a real attacker would. They chain weaknesses together. They take the unlocked door, find that it leads to a service account with more access than anyone realized, use that to reach a system the scanner flagged as low risk, and demonstrate that the combination gets them to something that would actually hurt you.

The deliverable is different in kind. Instead of a list ranked by a tool's opinion, you get attack paths ranked by what they would cost your business, with proof. "We started from an unauthenticated position on your marketing site and reached read access to the production customer database in four steps. Here is each step, here is the screenshot, here is exactly what to fix to break the chain."

That is the part a scanner will never give you, and it is the part that changes decisions.

When each one is the right answer

Run vulnerability scanning when you want broad, continuous coverage and a feed for patch management. It should be always on. If you are only scanning once a year because an auditor asked, you are using it wrong.

Commission a penetration test when you need to know whether your defenses actually hold against someone competent and motivated. Before a major launch. When a customer or insurer requires one. When the board asks the uncomfortable question of how an attacker would really get in. When you have invested in security tooling and want to know if it works under pressure rather than in a vendor demo.

Most mature programs do both, on different cadences, for different reasons. Scanning runs weekly or continuously. Testing happens annually at minimum, plus before significant changes.

How to tell what you are actually buying

Ask the vendor three questions before you sign.

First, who does the work, and what do they hold? A real test is run by people, not a scheduled scan with a logo on the cover. Ask for the testers' certifications and whether the same seniors who scoped the work will execute it.

Second, can you see a sample report with the client details removed? You are looking for narrative attack paths and remediation you can act on, not a CSV export reformatted into a PDF. If the sample is a list of CVEs sorted by CVSS, you have your answer.

Third, will they re-test after you fix things? A test that ends at the report is a test that does not care whether you got safer. Retesting should be included, because confirming the fix worked is the entire point.

If the answers are vague, the price is suspiciously low, and the timeline is "we can run it tomorrow," you are buying a scan. That might be exactly what you need. Just make sure it is what you meant to buy.