Penetration Test vs Vulnerability Scan: What's the Difference?

A vendor sent over a 40-page "penetration test" for $1,800. Your enterprise customer's security team read two pages and asked for the methodology and the proof. There wasn't any, because it was a scan.

Here's how to tell the two apart before you pay, and before a reviewer does it for you.

Applies 2026

• A vulnerability scan is automated, matches known signatures and doesn't attempt to exploit what it finds (TechTarget, Fortinet).
• A penetration test attempts to exploit weaknesses to show their effect. Methodologies include OWASP WSTG, PTES and NIST SP 800-115 (TechTarget, Safe Security).
• PCI DSS v4.0.1 asks for internal and external vulnerability scans at least every three months (Requirement 11.3), and penetration testing at least once every 12 months and after significant changes, with a retest of corrections (11.4.3, 11.4.4). Source: CompliancePoint's summary of the requirement text. PCI SSC is the primary source.
• Published market guides put scans at about $100 per IP per year and manual pentests at one day to three weeks (SecurityMetrics). Pentest price ranges are on the cost page.
• Anything priced around $2,000 is almost always a vulnerability scan with a cover page (BD Emerson).

All sources checked 2026-09-26.

What is the difference between a vulnerability scan and a penetration test?

What the report can prove. A scan says "this version of this library has a known issue" or "this parameter responds to a pattern that looks like injection". A penetration test says "we sent this request, got this response, and here is the data we shouldn't have been able to read".

Most guides split them into automated and manual. That split stopped working once AI pentests arrived. They're automated, but they send real requests, chain them and replay what they find. The useful question is whether the report proves anything.

Both belong in a security program. Where it goes wrong is paying for a scan, calling it a pentest and finding out during a customer review.

What does the same finding look like in a scan and in a pentest?

The clearest test is one finding, reported twice. Take a SQL injection in an order lookup endpoint.

The scanner column isn't useless. It found the parameter.

What it can't tell your developers is whether Tuesday's release is at risk, or whether the rule fired on a harmless error page. The pentest column answers that. It's why reviewers ask for a real report with named findings and proof, the standard we describe as proof-backed pentesting.

Not sure which one you're looking at? Run the free pre-pentest check on your app first. It's a scan, and the report says so.

Is a $2,000 penetration test really a vulnerability scan with a cover page?

Usually, yes. The price is a clue, not proof. Four things in the document settle it in ten minutes:

1. Every finding shows the request that was sent and the response that came back. A scan shows a rule name.
2. The report lists which test cases were run and which passed, against a named methodology such as OWASP WSTG. A scan lists plugins.
3. Findings include authenticated and multi-role tests, for example one tenant reading another tenant's data. A scan has no roles.
4. The document names its limits: what was out of scope and what wasn't tested. A scan lists everything it "checked".

If two or more are missing, you bought a scan. Ask for proof-of-concept exploits, not just vulnerability reports, before you accept the invoice.

Common mistake. Sending a scan report to an enterprise security reviewer as "our latest pentest". Reviewers read the methodology page first. A scan report fails it, and the cost lands on your deal, not on the vendor.

When do you need a scan, and when do you need a pentest?

Run a scan whenever code or infrastructure changes, and at least monthly. Run a pentest before a launch, before an audit or customer review, after a significant change and at least once a year.

PCI DSS v4.0.1 puts scans at every three months and pentests at every 12 months plus significant changes. Treat that as the floor.

The scan keeps the surface clean between pentests: headers, TLS, exposed services, known library versions. The pentest answers the question a scan can't, which is whether someone can get in and what they reach. Pairing them is cheapest, because the scan clears away noise the pentest would otherwise spend time on.

What a scan can never do is stand in for the pentest in a review. If a questionnaire asks for a penetration test, a scan is the wrong answer, however long the PDF is.

Scans repeat often. Can pentests?

Yes. Pentests used to run once a year mostly because every run meant booking tester days. Continuous AI pentests don't have that constraint. They run on a schedule, daily or weekly for example, and every run is still a real test that checks its findings against the live app before reporting them.

That changes the pairing above. The pentest no longer waits for its annual slot. It can run on the same rhythm as your releases, and each run is compared with the last one, so findings come back labelled new, still open, resolved or regressed.

A scan that runs daily gives you a daily list of maybes. A pentest that runs daily gives you daily proof.

The PCI DSS floor stays the same, yearly and after significant changes, but a team testing continuously is rarely anywhere near it. Continuous AI pentesting covers how schedules and change-triggered runs work.

How Barrion does it

We offer both and keep them separate on purpose.

The passive scan is read-only and production-safe. It checks TLS, HTTP security headers, cookie attributes, CORS, DNS and email authentication, exposed services and known CVEs in shipped JavaScript libraries. It never submits forms or touches state-changing routes. It's a scanner, and we say so.

The AI pentest is the active engagement. Specialist agents test your web app or API from a per-engagement Kali sandbox and chain requests across endpoints and roles. Every finding is checked against your live app. Confirmed ones come with the request and response that prove them, and anything unconfirmed is clearly marked. Every level maps to all 97 OWASP WSTG v4.2 cases, and from Standard level up a security engineer reviews the report before release.

A run finishes within hours. From Standard up, the reviewed report follows within one working day, as PDF, XLSX and JSON with a WSTG coverage matrix. The retest after your fix is included and holds no credits. A pentest can also be saved and rerun on a schedule. The details are on the facts page.

Barrion tests web applications and APIs only. Internal network, Active Directory, TLPT under DORA, mobile, physical and social engineering testing are out of scope.

What should a SaaS team send to an enterprise security review?

The pentest report, with a note on what it covers. A reviewer at an enterprise customer wants a recent test against the release in production, with named findings, proof per finding, the methodology and the retest result. Attach the scan report only as supporting evidence of ongoing hygiene, and label it as a scan.

If the latest document you have is a scan, run a pentest before the review rather than after the reviewer asks. An AI pentest on the current release takes hours, not weeks, and costs a fraction of a stalled contract.