Penetration Test vs Vulnerability Scan: What's the Difference?

A vulnerability scan is an automated check that compares your systems against a database of known issues. A penetration test is a human-led attack that finds, verifies and chains weaknesses to show what an attacker could really do. Both have a place in a security programme — but they are not interchangeable, and plenty of vendors sell one dressed up as the other.

What a vulnerability scan actually does

A scanner probes your systems and matches what it sees — software versions, open ports, response signatures — against a library of known vulnerabilities and misconfigurations. The output is a list of potential issues, each with a severity score.

Scans are genuinely useful. They are cheap, fast, repeatable, and ideal for continuous hygiene across a large estate. But their limits are structural, not a matter of tool quality:

They only detect issues they have signatures or checks for.
They report potential vulnerabilities, so false positives are common and every result needs triage.
They cannot understand business logic, test authorisation between users, or chain low-severity issues into a serious compromise.
They cannot tell you what a finding actually means for your business.

What a penetration test actually does

A penetration test is performed by skilled humans who use scanners as one tool among many. Testers verify each finding by exploiting it, hunt for the flaws automation is blind to — broken access control, logic abuse, authentication weaknesses, chained attacks — and demonstrate real impact with evidence: the customer record they accessed, the privileges they escalated, the internal system they reached.

The deliverable is a report a human wrote: verified findings, proof, business impact, and remediation advice specific to your environment.

The key differences at a glance

Who does the work: software vs experienced security professionals.
Depth: surface-level detection vs verified exploitation and chaining.
False positives: common vs effectively zero (every finding is proven).
Logic and authorisation flaws: invisible to scanners vs a core focus of testing.
Cost: dollars to hundreds per month vs thousands per engagement.
Frequency: continuous or weekly vs typically annual plus after major changes.
Output: a raw issue list vs a prioritised, evidenced report.

When a vulnerability scan is the right tool

Use scanning for what it is good at:

Continuous visibility of known vulnerabilities between penetration tests.
Verifying that patching is actually happening across a fleet.
Meeting compliance requirements that call for regular scans (PCI DSS requires quarterly scanning, for example).
Catching newly published vulnerabilities in software you already run.

If you are not scanning at all, start — it is the cheapest security win available.

When you need a penetration test

A scan will not cut it when:

You are launching a new product or a significant feature and need to know it holds up.
An enterprise customer or auditor is asking for a penetration test report — they mean human-led testing, and experienced reviewers can tell the difference.
You are pursuing SOC 2 or ISO 27001, or you fall under PCI DSS, which explicitly requires both scanning and annual penetration testing.
Your risk lives in authorisation and business logic — multi-tenant SaaS, APIs, payment flows — where scanners find essentially nothing.

For how the two fit into a yearly programme, see how often you should do a penetration test.

How to spot a scan being sold as a pentest

This is depressingly common, so here is what to look for:

The price is too good. A 'full penetration test' for a few hundred dollars is a scan. Human-led testing costs thousands because it consumes days of senior expertise.
No scoping conversation. If nobody asked about your application, user roles, environments or objectives, nothing bespoke is being done.
Impossibly fast turnaround. A real test takes days; a scan takes hours.
The report is scanner output. Generic descriptions, CVSS scores, no evidence of exploitation, no screenshots, no narrative. Ask for a sanitised sample report before you buy.
Every finding is a missing header or TLS setting. No authorisation flaws, no logic issues, no chained attacks — the fingerprint of automation.
No named testers or methodology. Ask who is doing the work and what portion is manual. Vague answers are an answer.

A simple filter: ask the vendor to show you a finding from a past report that a scanner could not have produced. We cover more vendor due diligence in how to choose a penetration testing company.

Use both, on a schedule

The right answer is rarely either/or. Run automated scanning continuously to catch known issues as they appear, and commission a penetration test at least annually — and after major changes — to find what the scanner never will. Each covers the other's blind spots.

FAQ

Is a vulnerability scan ever enough for compliance?

Occasionally, for specific requirements — PCI DSS mandates quarterly scans as their own control. But PCI DSS also requires annual penetration testing, SOC 2 auditors typically expect a pentest report, and ISO 27001 certifiers look for evidence of genuine technical testing. Assume a scan alone will not satisfy an assessor unless they have said so in writing.

How much cheaper is scanning than penetration testing?

Scanning tools range from free to a few hundred dollars a month. Professional penetration tests in Australia generally run AU$6,000–18,000 depending on scope, because you are paying for days of skilled human effort rather than compute time.

Can we run vulnerability scans ourselves?

Yes, and you should. Modern scanners are accessible to any competent IT team, and running them internally gives you continuous coverage at low cost. Save your external budget for the human-led testing you cannot do yourself.

If you would like an honest view on whether your next engagement should be a scan, a pentest or both, get in touch — a free scoping call takes half an hour and you will get a fixed quote within one business day.