Penetration testing vs vulnerability scanning

Neither is a weaker version of the other. They answer different questions, and the right mix depends on how much your systems change and what is at stake.

A vulnerability scanner compares what it can see (software versions, open ports, configuration, responses to crafted inputs) with a database of known issues, usually identified by CVE number. OWASP describes dynamic application scanners (DAST) as automated tools that scan web applications from the outside for issues like cross-site scripting, SQL injection and insecure server configuration.

• Coverage at scale. A scanner can check every internet-facing host you own every night.
• Known, unpatched software. If a published vulnerability affects a version you run, a scanner is the fastest way to find out.
• Configuration drift. Expired certificates, newly opened ports, weak TLS settings.
• Regression in CI. Scanners and SAST tools catch common mistakes before they ship.

Free options exist too. In the US, the Cybersecurity and Infrastructure Security Agency (CISA) offers no-cost external vulnerability scanning to eligible government and critical infrastructure organizations, with weekly reports.

A scanner does not know what your application is supposed to do, so it cannot tell when it does something it should not. The highest-impact issues in modern applications tend to fall in that gap:

• Broken access control. User A requesting user B's invoice by changing an ID (IDOR or BOLA) looks like a perfectly normal request to a scanner. Broken access control is ranked first in the OWASP Top 10:2025.
• Business logic abuse. Applying a discount twice, skipping a payment step, or approving your own request.
• Chained attacks. Three low-severity findings that together reach an admin account. Scanners score each one in isolation.
• Authentication and session flaws that only appear across multi-step flows, single sign-on or role changes.
• Context. A scanner cannot tell you that one medium finding exposes your entire customer table while another is harmless.

Scanners also produce false positives, which cost engineering time to triage. A penetration test removes those by proving each finding before it is reported.

Be honest about this: sometimes a scanner is the right purchase and a penetration test would be overkill.

• You run mostly off-the-shelf software and a marketing site, with no custom application holding sensitive data.
• Your main risk is unpatched, internet-facing infrastructure and you have not yet built a patching routine. Fix the basics first; a pentest will mostly report what a scan would have.
• You need a compliance control that specifically calls for scanning, such as the PCI DSS quarterly scans in Requirement 11.3.
• You are tracking known issues between periodic tests.

• You build your own application or API, especially one with multiple users, tenants or roles.
• You hold customer data, payment data, health data or credentials for other systems.
• A customer, auditor or regulation asks for one. PCI DSS v4.0.1 requires penetration testing at least every 12 months and after significant change (Requirement 11.4), separately from its scanning requirement.
• You have shipped a major change: new authentication, a new permissions model, a cloud migration.
• You want to know whether your scanning and patching actually work. The NCSC suggests a pentest should include an opinion on the accuracy of your own vulnerability assessment.

Picture a typical multi-tenant software product: a web app, an API behind it, an admin console and a cloud storage bucket for uploads. Run both approaches against it and the results usually look different in kind, not just in number.

• The scanner reports an outdated JavaScript library, a missing security header, a TLS setting to tighten and a handful of informational items. All useful, all quick to fix, mostly low or medium severity.
• The penetration tester may report fewer items, but of a different type: an API endpoint that lets one tenant list another tenant's users, an admin function reachable by a normal user who knows the URL, and upload links that never expire. Each comes with proof of the data that was reachable.

The scanner's list is about hygiene. The tester's list is about what a determined attacker would actually do with your product. You want both lists, but only one of them answers the question your customers and board are really asking.

Treat scanning as the always-on baseline and penetration testing as the depth check. Run scans continuously, fix what they find, and then let testers spend their limited time on what scanners cannot see. Sharing recent scan results with testers before an engagement avoids paying people to rediscover known issues.

For applications that change every week, the gap between annual tests can be long. That is the case for continuous penetration testing, which keeps human-proven or agent-proven exploitation running between formal tests.