Penetration Testing vs Vulnerability Scanning: The Difference

Vulnerability scanning and penetration testing are often used as if they mean the same thing. They don’t, and buying one when you need the other is one of the most common and expensive mistakes in small-business security.

The short version: a vulnerability scan asks “which known weaknesses do these systems have?” A penetration test asks “what could an attacker actually do to us?”

The standards bodies draw the same line. NIST’s SP 800-115 (opens in a new tab) treats vulnerability scanning as a target identification and analysis technique, and penetration testing as a separate target vulnerability validation technique, in which testers “mimic real-world attacks” to find ways around a system’s security. PCI DSS makes the split contractual: quarterly scans under Requirement 11.3 and penetration tests under 11.4 are separate obligations, and one can’t substitute for the other.

What a vulnerability scan does

A vulnerability scanner is software that probes your systems and compares what it finds against a large database of known issues: outdated software versions with published CVEs, weak TLS settings, default configurations, missing security headers and so on.

Scanning is:

• Fast: a scan of dozens of hosts can finish in hours.
• Broad: it checks thousands of known issues consistently.
• Repeatable: ideal for running weekly or monthly to catch regressions.
• Cheap: once set up, running it again costs very little.

But scanners have hard limits:

• They produce false positives. A scanner often infers a vulnerability from a version number without confirming it’s exploitable. Unvalidated reports can contain a lot of noise.
• They don’t understand your application. A scanner doesn’t know that invoice 10482 belongs to customer B, so it can’t notice that customer A can read it. That matters, because broken access control is the most common serious web flaw: OWASP’s 2025 data found it in every application tested.
• They can’t chain issues. Two “low” findings that combine into a serious compromise look like two lows to a scanner.
• They miss logic flaws entirely. Applying a discount twice, skipping a payment step, or approving your own request are invisible to automated tools.

What a penetration test does

A penetration test is carried out by a person. The tester uses tools, including scanners, for speed and coverage, but the core of the work is the tester’s judgment: understanding how your application or network is meant to work, and then methodically trying to make it do something it shouldn’t.

A penetration test:

• Confirms real exploitability, with evidence, instead of guessing from version numbers.
• Tests access control between users, roles and tenants, the category behind many of the most damaging breaches.
• Finds business-logic flaws that no signature database contains.
• Chains weaknesses together to show the realistic worst case.
• Explains impact in business terms, so you can prioritize fixes.

The trade-off is time and cost: a real test takes days of skilled work, not hours of machine time. Our guide to penetration testing cost explains what drives that.

Side by side

	Vulnerability scan	Penetration test
Performed by	Software	A person, assisted by tools
Question answered	Which known issues exist?	What could an attacker achieve?
Finds logic & access-control flaws	No	Yes
False positives	Common unless validated	Removed, since findings are proven
Duration	Hours	Days
Best frequency	Continuous / monthly	Annually and after major changes
Satisfies “independent pentest” requirements	Usually not	Yes

The middle ground: a validated vulnerability assessment

Between a raw scan and a full penetration test sits the vulnerability assessment: scanning across your estate, followed by a person validating each result, removing false positives and ranking what’s left by real risk.

It won’t find logic flaws, but it turns a scanner’s noise into a short, trustworthy fix list, and it’s a sensible, affordable first step for a business that has never been tested. See vulnerability assessments for what’s included.

What the exploitation data says

Scanning has real value, and the evidence for it is strong. Most vulnerabilities attackers exploit are known, patchable flaws in commercial software. In our analysis of CISA’s Known Exploited Vulnerabilities catalog, 82% of the entries added in 2026 had a CVE from 2025 or 2026, and one in ten was for a flaw at least five years old. A scanner that matches your software against that list catches exactly those.

What no catalog contains is the flaws in your code: the missing ownership check, the discount that applies twice, the admin endpoint with no role check. Those only have a CVE if you’re a software vendor who publishes one. Finding them is what the penetration test is for.

Which one do you need?

Choose a vulnerability assessment if:

• You’ve never had any security testing and want an affordable baseline.
• You need broad coverage of many hosts quickly.
• You’re between annual penetration tests and want to catch regressions.

Choose a penetration test if:

• A customer, partner or investor has asked for an independent pentest report.
• You’re preparing for SOC 2, ISO 27001 or PCI DSS: auditors expect a compliance-ready penetration test, not a scan.
• Your application handles payments, personal data or multiple tenants.
• You’re launching a major feature, new authentication system or new API.

Do both if you can: continuous scanning to catch the known issues quickly, plus a periodic web application or network penetration test to find what scanning can’t. For what either costs, see the penetration testing pricing guide.

A simple test for any provider

Ask for a sample report. If every finding reads like a database entry (generic title, generic description, generic “update to the latest version” fix, no evidence specific to the system tested), you’re looking at scanner output, whatever it’s called. A real penetration test report shows exactly what the tester did, what happened, and how to fix it in your system. Here’s what that looks like.

Sources

• NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment (opens in a new tab), sections 5 and 6.
• PCI Security Standards Council, PCI DSS v4.0.1 (opens in a new tab), Requirements 11.3 and 11.4.
• OWASP, A01:2025 Broken Access Control (opens in a new tab).
• CISA, Known Exploited Vulnerabilities Catalog (opens in a new tab).