Penetration test and vulnerability scan: what’s the difference

In short: a scan is a continuous check of breadth, a test is a one-off check of depth. They aren’t competitors, and choosing between them means giving up one of those two things.

The scanner wins wherever numbers decide. It goes through 1,000 addresses overnight, compares versions against a database of known vulnerabilities, that is, a list in which each flaw has its own CVE identifier, and flags a missing patch on dozens of servers a person would never have time to open within the scope of a test. That is exactly the job for a tool, not a tester.

• Missing security patches across a large number of machines and devices.
• End-of-life systems that were forgotten during a migration.
• Drift from the configured baseline that crept in between two checks.
• Newly exposed services that nobody in IT knew about.

A scan is also the cheapest way to track this continuously. A test shows the situation on the day of testing, whereas regular checks of the perimeter and internal network track changes between tests.

A scanner has no way of knowing which operation belongs to whom. Whether access is legitimate follows from the rules of a specific company, and those rules aren’t in any database. A typical finding of this kind: an ordinary user calls a function reserved for administrators, because permissions are enforced only by hiding a button in the interface.

Nor does it find flaws in business logic, meaning the rules that apply only in your application. The OWASP guide to web testing says so outright: a scanner won’t find this kind of vulnerability, and it is tested by hand. An order can be canceled after the goods have shipped, loyalty points get transferred twice, a refund is paid before the goods are back in the warehouse. The tool doesn’t know these rules, so it can’t break them.

The third category is chaining. An uninteresting finding on its own, a forgotten test account, and a missing restriction on an admin interface add up to an intrusion, even though each of the three is rated low severity in the scan. Only a manual test where a person verifies the findings makes that connection.

The difference shows even on a single finding. The scanner reports an old library version and assigns it a score from the database. The tester shows that the customer database can be downloaded through it and documents that with the request and the server’s response. For deciding what to fix first, that is entirely different information.

A scan takes up time mainly in evaluation, not in the run itself. The tool finishes overnight, but someone has to go through the findings and separate real flaws from false alarms. In a large environment that work repeats with every run, which is why it pays to automate the scan along with the triage.

That isn’t just our impression: the NIST guide to technical security testing lists scanning among the activities that are labor-intensive precisely because the results have to be interpreted, and warns that scanners have a high false positive rate.

With a test the ratio is reversed. A substantial part of the time goes into manual verification and into looking for paths the tool can’t see, and the duration grows with the number of user roles, environments, and sites. That is why the effort of a test is counted in person-days, while a scan is counted by the number of monitored systems.

A scan is enough where only patches and routine updates have arrived since the last check. A penetration test is needed the moment a feature, a role, an integration, or a whole environment has been added, because the scan will scan it but won’t check the new logic. The tool knows nothing about it.

• Choose a scan if you need a continuous view of patches and exposed services.
• Choose a test if you’ve released a new version of an application with a different data model or new roles.
• Choose a test if you have to document the state of technical measures to someone outside the company.
• Choose both if you run an application with sensitive data and your own network on top.

Czech regulation distinguishes the two and, in the stricter of its two regimes, doesn’t treat one as a substitute for the other. Decree No. 409/2025 Coll. speaks of vulnerability scanning and penetration testing as two separate activities and sets a different frequency for each, even when they concern the same system.

Who it applies to, in which regime, and with what deadlines is a question for a separate explanation. We summarize it where it belongs, in our overview of what the law says about testing and scanning. The full text of Decree No. 409/2025 Coll. is public (in Czech).