Penetration test or vulnerability scan: what is the difference and when to use which

Penetration test and vulnerability scan are used interchangeably in quotes and policy documents, and that creates the wrong expectations. They are two different things: one is an automated check for known weak spots, the other is manual work in which someone actually tries to get in. If you buy a pentest and receive a scan report, you paid too much. If you assume a monthly scan satisfies an audit requirement, you sometimes only find out during the audit that it does not.

What a vulnerability scan does

A vulnerability scan is an automated process. A tool such as Nessus, Qualys or OpenVAS reaches your systems, establishes which software and versions are running, and compares that against databases of known vulnerabilities. The result is a report of findings, usually sorted by CVSS score.

The strength lies in speed and repeatability. A scan across an entire network takes hours, not weeks, and can run weekly or daily. That makes it ideal for monitoring that patches are being rolled out and that no forgotten servers are still running.

The limitation lies in what a scanner can see. It recognises known vulnerabilities in known software. It does not understand what your application does, so it does not see that user A can retrieve user B's record by changing a number in the URL. That kind of flaw sits in the business logic and appears in no database.

What a penetration test does

In a penetration test, a tester examines your environment with the same mindset as an attacker. There is reconnaissance, combination and pushing through. A pentester uses scanners too, but as a starting point rather than as the end product.

The difference is in combining. A scanner reports three separate findings with low scores. A pentester sees that the first yields a valid session, the second gives access to an internal interface and the third allows a command to run there, demonstrating that the combination does lead to a data breach. That insight does not come out of a tool.

A pentester also finds the categories scanners structurally miss: broken access control, weaknesses in authentication and session management, business logic flaws such as a discount you can apply twice, and misconfigurations that are only problematic in combination.

Depth, lead time and cost

A vulnerability scan is cheap, fast and shallow. A penetration test is more expensive, takes days to weeks and delivers depth. That is not a value judgement: they are instruments with different purposes.

The reporting differs accordingly. A scan report is a list of findings with scores. A pentest report describes per finding how the tester proceeded, what the demonstrable impact is for your organisation, and what remediation is advised. With a good report, a developer can reproduce the finding.

When to use which

Use vulnerability scanning as continuous monitoring. Run it weekly or monthly across your external and internal systems, and tie the results into your patch process. Do not measure the number of findings but the time to remediation, because that figure says something about how your organisation works.

Use a penetration test at moments that matter. Before the go-live of a new application or a major release. On an architectural change, for example a cloud migration or a new interface. Periodically, usually annually, on your most important applications. And whenever a customer, insurer or standard asks for one.

What standards and assessments require

This is where the distinction becomes practical for many organisations. The Dutch DigiD assessment expects a penetration test matching the scope, not just a scan report. For ISO 27001 and SOC 2 the point is demonstrable management of technical vulnerabilities, where scanning and pentesting complement each other: the scan provides continuous monitoring, the pentest provides periodic depth. Organisations that only scan regularly get asked during those audits where the deeper testing is.

What you need to arrange in both cases

The report is not the end. With a scan it is about triage: which findings actually apply, which are false positives, what do you fix first. With a pentest it is about remediation and retesting. A finding that was fixed but never retested remains an open item in an audit.

For a pentest, set the scope, the testing window and the rules of engagement up front: which systems may be reached, which techniques are allowed, who is reachable if something falls over. Without those agreements a test gets halted halfway through, or the most interesting part is left untested.

Secure Audit performs penetration tests on web applications, APIs and infrastructure, and assesses in audits whether scanning and pentesting together provide sufficient coverage. Get in touch if you want to know which combination fits your environment and applicable standards.