Both a vulnerability scan and a penetration test provide you with a document full of findings with severity ratings. Some organisations pay for a penetration test when a scan would have provided assurance.
Others procure penetration testing, but what they receive is a vulnerability scan output wrapped in a pentest report. They cost very different amounts, and to some buyers the reason is not always so obvious.
What a vulnerability scan actually does
A scanner works from a database of known issues, sometimes known as "plugins". It will identify and fingerprint what is running on a host or an application, compare that against published vulnerabilities and coded configuration checks, and report what matches. Nessus, OpenVAS, Burp Suite and ZAP all work on that principle, differing mainly in what they check and in their output formats.
Vulnerability scanning is genuinely useful, and it allows a pentester or a security analyst to quickly enumerate issues on a larger scale. The output from a scan can be used during a pentest to quickly identify low-hanging lateral movement opportunities, or for the client to easily parse through missing patches and misconfigurations.
A scan will find unpatched mail servers, weak TLS configurations, default credentials left on a management interface, and an admin panel exposed to the internet that nobody remembered deploying. It runs in hours rather than days, it costs a fraction of a manual pentest engagement, and it can run every week without procuring independent security testing.
Where a scan stops being useful
A scanner reports what it recognises. It has no understanding of your application's business logic, so it cannot tell that a customer on one account can retrieve another customer's invoices by changing a number in the URL. That request returns a perfectly valid response, and as far as the tool is aware there is nothing wrong.
The same limitation applies when scanning a network. A scanner could list a handful of medium or high-severity findings on separate hosts, but wouldn't be able to identify a privilege escalation or lateral movement attack vector without this check being hard-coded into its plugin database.
Scanners also tend to over-report what might be exploitable, and you'll notice this if you've ever received an uncurated pentest report that has had supplemental vulnerability scanning included. A service banner check might show that a vulnerable version is installed, but determining whether the vulnerability is genuinely exploitable in your environment is manual work. It is the difference between a report saying "this host may be affected" and one saying "we used this to read your customer database, and here are the steps to reproduce it".
The three options side by side
| What you get | Vulnerability scan | Vulnerability assessment | Penetration test |
|---|---|---|---|
| Missing patches and known CVEs | ✓ | ✓ | ✓ |
| Findings reviewed by a person | ✗ | ✓ | ✓ |
| False positives removed before you see them | ✗ | ✓ | ✓ |
| Business logic and access control flaws | ✗ | ✗ | ✓ |
| Individual issues chained into an attack path | ✗ | ✗ | ✓ |
| Impact demonstrated rather than predicted | ✗ | ✗ | ✓ |
| Runs on a schedule without a consultant | ✓ | ✗ | ✗ |
| Typical cadence | Weekly or monthly | Quarterly | Annually, or after significant change |
When a vulnerability scan is genuinely enough
Not every system or application justifies a manual pentest engagement, and providers that state otherwise are selling rather than advising.
Scanning on a sensible cadence is a reasonable control where the system is low-impact, the data it holds is not especially sensitive, and the consequences of it being compromised are limited. A brochure site on managed hosting, an internal tool used by six people, a fleet of workstations you are checking for missing patches. Scanning those weekly or monthly gets you most of what a manual test would find, at a fraction of the cost of a pentest.
This changes where an internal or external network is concerned, where an application handles money or personal data, where it requires segmentation between customer tenants, or where there is business logic a tool cannot discern. This is where the gap between what a vulnerability scan can report and what a skilled penetration tester can achieve becomes wide enough to be worth the time and cost.
What compliance frameworks actually ask for
Compliance standards will generally treat these as two separate activities and auditable proof, rather than as alternatives to each other. PCI DSS is the clearest example, where requirement 11.3 covers vulnerability scanning on a quarterly cycle, and requirement 11.4 covers penetration testing performed at least annually. Passing your quarterly scans with flying colours does not satisfy the pentesting requirement, and an annual pentest does not remove the scanning obligation.
ISO 27001 and SOC 2 are less prescriptive about method, and neither require penetration testing. However, assessors will usually expect to see evidence of a routine scanning process and periodic independent testing.
Using both, for different reasons
Most organisations should ideally be doing both. Vulnerability scanning gives you breadth of coverage and frequency; consider it as a regular check-up. Penetration testing offers the depth, greater assurance in your existing security controls, and granular, contextual remediation advice. A scan that keeps reporting the same unpatched hosts, quarter after quarter, is indicating a problem with the patching process, which is a vulnerability management problem rather than a testing one.
Our vulnerability assessment service sits between the two. It combines automated scanning across your estate with a consultant reviewing the output, removing any false positives, and highlighting the findings that are worth your team's time.
Where you need proof of what an attacker could actually do with those findings, demonstrating exploitability and giving you assurance in your existing security controls, that is a network penetration test. Our article on manual vs automated penetration testing covers how much of that work is run by people, not programs.
