A vulnerability scan is not a penetration test

Every week someone shows us a 120-page "penetration test" that is, on inspection, a scanner's output with a cover page. It cost real money. It passed an auditor. And it missed the one flaw that would have mattered. If you buy security testing, this is the distinction that protects you.

What a scanner actually does

A vulnerability scanner is a pattern-matcher. It sends known probes, compares responses against a database of signatures, and reports what matches. That is genuinely useful: it finds missing patches, outdated components and known misconfigurations quickly and cheaply, across thousands of hosts. Every mature security program runs scanning continuously.

But a scanner only knows what it was told to look for, and it cannot reason. It doesn't understand that this user shouldn't be able to see that invoice. It can't chain three low-severity quirks into one critical compromise. And it can't tell a real risk from a theoretical one in your specific context.

What a penetration test adds

A penetration test is a person — a skilled one — trying to break into your systems the way an attacker would. The scanner's output might be an input to that work, but the value is in what only a human does:

• Business-logic flaws. Stacking discount codes, skipping a payment step, escalating a role. Nothing is technically "broken", so no scanner flags it — but it drains revenue or exposes data.
• Access-control flaws. The classic "change the ID in the URL and see someone else's data." Scanners rarely have the authenticated context to find these; they're among the most common serious bugs we report.
• Chaining. Real attacks combine small issues. A low-severity information leak plus a weak reset flow becomes account takeover. A scanner lists two minor findings; a tester shows you the breach.
• Proof and prioritisation. A tester demonstrates genuine impact and tells you what to fix first. A scan hands you hundreds of findings, many false positives, with no sense of which one ends your week.

How to tell which one you're buying

The label on the quote doesn't tell you. These questions do:

• "Who does the testing, and what do they hold?" A real test is done by named senior people with hands-on certifications, not assigned to a tool.
• "Can I see an anonymised sample report?" Look for reproduction steps, chained findings and business impact — not just a severity table lifted from a scanner.
• "Will you find business-logic and access-control issues?" If the answer is vague, you're buying a scan.
• "Is a retest included?" People stand behind their findings and verify fixes. A tool can only re-scan.
• "How many days of manual testing?" A genuine engagement is measured in tester-days, not in how fast a scan completes.

You need both

This isn't scanners versus testers. Run scanners constantly — they're the efficient baseline, and they catch regressions between engagements. Then bring in people for depth, at the moments that matter: before a launch, for a compliance milestone, after a major change. Our vulnerability assessment is the broad, validated baseline; our penetration testing is the depth. The mistake is paying for one and believing you got the other.