Skip to content
normSight — Cyber Security

9 September 2026

Penetration test vs vulnerability scan: what is the difference?

A vulnerability scan uses automated tools to produce a list of known flaws; in a penetration test an expert actually exploits those flaws to prove their impact and uncover chained attack paths.

These are the two concepts organisations looking to buy security services confuse most often. The large gap between quoted prices for a “vulnerability scan” and a “penetration test” usually comes from exactly this: they are two different pieces of work.

In short: a vulnerability scan produces a list of known flaws in a system. A penetration test proves whether those flaws can actually be exploited and, if so, how far an attacker could get.

What a vulnerability scan does

A vulnerability scan is run with an automated tool. The tool connects to the target systems, identifies running services and their versions, compares them against known vulnerability databases and reports the matches.

Where it is strong:

  • Breadth of coverage. It can scan thousands of assets in a short time.
  • Repeatability. It can be run automatically every week or month, keeping unpatched systems continuously visible.
  • Cost. It requires no expert hours, so it is inexpensive.

Where it is weak:

  • No verification. The tool says “this version may be affected by that flaw”; it does not check whether it actually is. The false positive rate is high.
  • Blind to business logic. One user being able to see another user’s order is not technically a “flaw” — no scanner will find it.
  • Cannot see chains. It cannot notice that three individually low-risk findings combine into full server compromise.

What a penetration test does

In a penetration test an expert behaves, under authorisation, like a real attacker. Scanning is only the first step here; the actual work begins afterwards.

The tester exploits the vulnerability they find, expands the access they gain, moves laterally and demonstrates how far they can reach. The result is not a list but a narrative: “I got in here, escalated privileges this way, and reached this data.”

The practical consequence of the difference is this: a scan tells you what needs patching; a penetration test shows you how the attack would actually go.

A concrete example

In a scan report, these three findings might each be flagged separately as “low” or “medium”:

  1. Directory listing left enabled
  2. A backup file accessible in the web root
  3. An admin panel running with default credentials

None is urgent on its own. In a penetration test the following chain is built: directory listing reveals the backup file, the backup yields database connection credentials, the same password works on the admin panel, and the system is fully compromised. The same three findings become critical together.

Automated tools cannot construct that chain. What constructs it is the tester’s judgement.

Which one do you need, and when?

Vulnerability scanning is the right tool when:

  • You have a large asset inventory and want to monitor patch status continuously
  • A compliance requirement mandates regular scanning
  • You want to maintain visibility between penetration tests

Penetration testing is necessary when:

  • You want to verify a new application or infrastructure before it goes live
  • You want to see real business impact — “can customer data be reached through this flaw?”
  • You want to measure whether your defensive investments actually work
  • You are checking, after a security incident, whether a similar path is still open

Asking the right question

When you request a quote, one question clarifies the distinction: “Are findings verified manually?”

If the answer is no, what you will receive is scanner output. That has value too, but it is not a penetration test and does not warrant that price.

The second question: “Does the report include evidence?” Every finding should come with proof of how it was exploited. No evidence means no verification was done.

The normSight approach

In our penetration tests every finding is verified manually; no unverified scanner output enters the report as a finding. The report pairs an executive summary with technical detail, and post-remediation retesting is included in the engagement.

For an assessment suited to your scope you can get in touch, or look directly at our network penetration testing and web application penetration testing services.

  • penetration testing
  • vulnerability scanning
  • security assessment

Frequently Asked Questions

Can a vulnerability scan replace a penetration test?

No. A scan inventories the surface; a penetration test proves whether that surface can actually be exploited. Scanning is a recurring hygiene activity and testing is a periodic verification — neither substitutes for the other.

How often should we commission each?

Monthly or weekly automated runs are common for vulnerability scanning. For penetration testing, once a year is typical, plus after any major architectural change, new application release or infrastructure migration.

How does a penetration test report differ from a scan report?

A scan report is tool output: most findings are unverified and it contains false positives. In a penetration test report every finding is manually verified, presented with evidence (screenshots, request/response) and rated by real business impact.

We are a small company — do we need a penetration test?

Attackers do not choose targets by size; if you have an internet-facing application or remote access, you are already being scanned. If budget is tight, narrowing the scope to your most critical asset is far more effective than testing nothing at all.

See the real risks in your systems.

Talk to our team about a penetration test or training plan that fits your scope.