Penetration Test vs Vulnerability Scan: The Difference

A vulnerability scan is software checking your systems against a database of known flaws and printing a list. A penetration test is a person trying to break in, chaining those flaws together until something gives. A scan costs a few hundred dollars to low four figures and finishes in hours; a credible penetration test starts around $5,000 and runs for weeks. Both belong in a mature program, and they answer different questions. The scan asks "what is exposed?" The test asks "what can an attacker actually do with it?" And if a vendor just quoted you $900 for a "penetration test," you are almost certainly buying a scan with a new label. More on how to catch that below.

Key takeaways

• A scan is software checking your systems against a database of known flaws and printing a list. A test is a person trying to break in, chaining those flaws together until something gives.
• Scanners cannot find what has no CVE: business logic flaws, authorization bypass, multi-step workflow abuse, session handling edge cases, and API parameter tampering.
• PCI DSS 4.0.1 requires both, in different control numbers: 11.3.x for scanning (authenticated internal, ASV external) and 11.4.x for penetration testing. A QSA will not accept a scan report as evidence for 11.4.
• SOC 2's CC7.1 names neither method, but auditors expect a documented scanning and remediation program at minimum, and in practice an annual penetration test for software companies.
• Buy scanning first. A penetration test before you have a vulnerability management program reports things a scanner subscription would have told you, at consulting rates.

What a vulnerability scan actually does

A scanner (Nessus, Qualys, OpenVAS, and the cloud-native equivalents) fingerprints every host and service in scope, then compares what it finds against a signature database of known vulnerabilities. Missing patches, expired TLS configurations, default credentials, exposed admin panels, outdated software versions with published CVEs. It checks each system independently, scores each finding with CVSS, and hands you a report.

Scans come in two flavors, and the difference matters for compliance. An unauthenticated scan probes from the outside, seeing only what an anonymous attacker sees. An authenticated scan logs in with credentials and inspects the system from the inside: installed packages, registry settings, local misconfigurations. Authenticated scans find dramatically more, which is exactly why PCI DSS now mandates them (more on that in the compliance section).

Scanners are genuinely good at what they do. They are fast, cheap, repeatable, and they never get bored on host number 4,000. Run them monthly at minimum; weekly or continuous is better. What they cannot do is think. A scanner will not notice that your password reset flow lets anyone take over an account, because that flaw has no CVE. It will not chain a low-severity information leak with a misconfigured CORS policy into full account takeover. It evaluates findings one at a time, in isolation, against patterns someone else already documented. We wrote about why that gap matters in Penetration Testing: Beyond Checkbox Compliance.

What a penetration test actually does

A penetration test puts a human attacker against your environment under contract. The tester starts where a scanner stops: they take the raw findings, add reconnaissance and manual probing, and then attempt real exploitation. Not "this version is theoretically vulnerable" but "here is a screenshot of your customer database, reached through this exact chain of steps."

That chaining is the core difference. In most first engagements we see, no single finding is catastrophic on its own. A default credential on an internal service, a flat network segment, an over-permissioned service account. A scanner rates each one medium at best. A tester strings them into domain admin in an afternoon.

Testers also cover territory scanners cannot enter at all: business logic flaws, authorization bypass (can user A read user B's invoices by changing an ID in the URL?), multi-step workflow abuse, session handling edge cases, and API parameter tampering. These make up a large share of the findings that matter in modern SaaS environments, and every one of them is invisible to signature matching.

The deliverable is different too. A real pen test report contains a narrative of what was attempted, what worked, reproduction steps, evidence of exploitation, business impact written for executives, and a retest of your fixes. A scan report is a sorted list of findings, many of them false positives you still have to triage yourself.

The price reflects the labor. As of August 2026, a scoped external network test starts around $5,000, the floor of DeepStrike's published external band; a thorough web application and network engagement for a mid-size SaaS company commonly lands in the $15,000 to $40,000 range, which is our own observation rather than a published survey figure. Compare that to hundreds or low thousands per year for scanning, and the temptation to conflate the two becomes obvious. For the buyer and, unfortunately, for some vendors.

At a glance

Neither replaces the other. A pen test is a point-in-time snapshot; without continuous scanning you are blind for the other 50 weeks of the year. Scanning without occasional human testing means the flaws that hurt most go unexamined indefinitely.

What compliance actually requires

As of August 2026, the current PCI DSS version is 4.0.1, and it is the most explicit standard on this question because it requires both, separately, in different control numbers. Requirement 11.3.1 mandates internal vulnerability scans at least quarterly, and 11.3.1.2 specifically requires those internal scans to be authenticated scans, a requirement that became mandatory with the March 2025 future-dated deadline (see the standard itself at the PCI Security Standards Council document library). Requirement 11.3.2 covers quarterly external scans by an Approved Scanning Vendor.

Then, entirely separately, the 11.4.x family requires penetration testing: a documented methodology (11.4.1), internal penetration testing at least annually (11.4.2), and external penetration testing at least annually (11.4.3), performed by a qualified internal resource or independent third party. A QSA will not accept a scan report as evidence for 11.4. The standard was written specifically to prevent that substitution.

SOC 2 is looser, which causes most of the confusion. No Trust Services criterion requires a penetration test or a vulnerability scan by name; the words appear only in points of focus, and the AICPA states that use of the criteria does not require an assessment of whether each point of focus is addressed. CC7.1 asks for procedures that detect vulnerabilities and monitor for security events; how you satisfy that is between you and your auditor. In practice, we see auditors accept a documented vulnerability management program (regular scans plus tracked remediation) as the floor. Most auditors now also expect an annual penetration test for any company whose product is the thing being audited, and nearly every enterprise customer security questionnaire asks for your latest pen test report regardless of what the auditor accepted. If SOC 2 is being driven by a specific deal, check what that customer's questionnaire asks for before deciding scan-only is enough.

HIPAA and ISO 27001 sit in similar territory: periodic technical evaluation is required, penetration testing by name is not, and assessors increasingly expect it anyway.

The rebranded-scan problem

Here is the uncomfortable part of this market. A meaningful number of "penetration tests" sold today are vulnerability scans with a cover page. The vendor runs Nessus, exports the findings into a template with the words "penetration test" in the header, and charges $2,500 for a deliverable that cost them an hour of compute. The buyer files it as pen test evidence, and nobody notices until a QSA rejects it or an actual attacker succeeds where the "test" never tried.

Five questions expose this quickly:

1. Who is doing the testing, and what are their credentials? Ask for the individual tester's certifications (OSCP, OSWE, GPEN, CREST). A scan-reseller cannot name a tester because there isn't one.

2. Can I see a sanitized sample report? A real report shows exploitation chains, screenshots, and step-by-step reproduction. If the sample is a CVSS-sorted list that reads like scanner output, it is scanner output. Nessus plugin names appearing verbatim as finding titles is the giveaway.

3. How many hours of manual testing are included? A legitimate engagement quotes days of human effort. Vagueness here ("our platform tests continuously") means automation.

4. Will you find vulnerabilities that have no CVE? Business logic flaws, authorization bypass, workflow abuse. If the vendor cannot explain how they test for these, they do not.

5. Is remediation retesting included, and what is the timeline? Real firms scope kickoff, testing windows, and a retest. A "penetration test" delivered 24 hours after kickoff was never a penetration test.

Price is the crude but reliable filter. Human exploitation time cannot be sold profitably at scan prices. An offer of a full network and application penetration test for under roughly $4,000 should make you ask hard questions.

When each is the right call

Buy scanning first. If you have no vulnerability management program at all, a pen test is premature; we will charge you five figures to report things a $3,000-a-year scanner subscription would have told you, and that is a bad trade. Get scanning running, burn down the patch backlog, then test. We tell prospects this directly, and it occasionally costs us an engagement. It is still the right sequence.

Buy a penetration test when: a framework explicitly requires it (PCI DSS 11.4.x), a large customer's questionnaire demands one, you have shipped a major architecture change, your scan results are consistently clean and you want to know what the scanner is missing, or you are about to go through diligence for funding or acquisition.

And run both on a calendar, not as one-off events. Continuous scanning plus an annual human-led test is the pattern every mature framework converges on, because each covers the other's blind spot.

Frequently asked questions

Does SOC 2 require a penetration test or a vulnerability scan?

Strictly, neither. The Trust Services Criteria (CC7.1 in particular) require vulnerability detection and monitoring processes but never name a specific method. In practice a documented scanning and remediation program is the minimum any auditor will accept, and most auditors expect an annual penetration test for software companies. Enterprise customers will ask for a pen test report in security reviews regardless, so scan-only SOC 2 programs usually end up buying a test anyway.

Can I just run Nessus myself and call it done?

Running Nessus (or Qualys or OpenVAS) yourself is a legitimate and cost-effective way to handle the scanning half, and for internal PCI DSS scans it is acceptable if the person running it is qualified and independent of the system administrators. It does not produce a penetration test, though: no exploitation, no chaining, no logic-flaw coverage, and a QSA or serious enterprise customer will not accept the output as one. External PCI scans also specifically require an Approved Scanning Vendor, which a self-run Nessus instance is not.

How much should a real penetration test cost?

Expect a floor around $5,000 for a narrowly scoped external network test, with $15,000 to $40,000 typical for a combined web application and network engagement at a mid-size company. Pricing well below that range usually signals automated scanning sold under a different name. The honest comparison is labor: days of skilled human time cannot be delivered at software prices.