Penetration Test vs Vulnerability Scan: What Each Finds and When to Use Which

What is the difference?

A vulnerability scan asks “does this system have a weakness I know about?”. A penetration test asks “how would an attacker get in, and how far would they get?”. The first is answered by software comparing versions, configurations and responses against a database. The second is answered by a person who reads the application, forms hypotheses and tries them, using scanners as one of many tools.

The results differ accordingly. A scan produces a long list of possible issues, many of them informational or false positives, each with a CVSS score copied from a database. A penetration test produces a shorter list of confirmed findings with proof, a severity judged in context, the chain they form and a fix recommendation for each.

Side by side

	Vulnerability scan	Penetration test
Who does it	Software, scheduled	Security engineers, with a scope and rules of engagement
Finds	Known CVEs, missing patches, weak TLS, default credentials, misconfigurations with a signature	Authorisation flaws, business-logic abuse, injection in custom code, attack chains, weak crypto use, hardware and protocol weaknesses
Misses	Logic flaws, anything without a signature, chained attacks, authenticated flows it cannot navigate	Whatever lies outside the agreed scope and time
False positives	Common; someone has to triage	Rare; every finding is reproduced
Duration	Minutes to hours	Days to weeks
Typical cost	Hundreds to a few thousand euros per year	3,000 to 45,000 euros per test, depending on the target
Frequency	Continuous or weekly	Once or twice a year and after major changes
Required by	ISO 27001 controls, PCI DSS (quarterly scans), many customer questionnaires	PCI DSS (yearly), TISAX and many OEM requirements, NIS2 risk management in practice, CRA conformity assessment evidence, customer contracts
Output	Finding list with generic text	Report with reproduction, context, chains and fixes; often a presentation and a retest

Choose a vulnerability scan when

• You need to know, continuously, whether a known weakness appeared in your estate: a new CVE, an unpatched host, a certificate about to expire.
• You run many systems and need coverage more than depth.
• You have to show a compliance framework that scanning happens (PCI DSS asks for quarterly scans by an approved vendor).
• Your budget is small and you have nobody to triage pentest findings yet. Fix what the scanner shows first; a pentest on an unpatched system wastes the tester’s time on things a scanner finds for free.

Choose a penetration test when

• The system has accounts, roles, money or personal data: the interesting bugs are in logic and authorisation, where scanners are blind.
• It is a product you ship: an IoT device, a machine, an ECU, an app. Scanners have little to say about firmware, debug ports, radio protocols or CAN.
• A customer, an OEM, an auditor or a regulation asks for a test with a report and a named tester.
• Before a launch, after a major rewrite, after a change of hosting or identity provider, or after an incident.

Both together

The sensible setup for most companies is a scanner that runs continuously and a penetration test once a year, plus one after major changes. The scan catches the known and the regressions; the pentest catches what only a person finds. Give the tester the scan results: it saves time on the obvious and lets the days go into the hard parts.

Zyberum does penetration tests and can set up scanning for you as part of the Zyberdome managed SOC; we do not sell scanners on their own. If what you need is a scan, say so and we will tell you which tool to use.