Penetration test vs vulnerability scan: which do you actually need?

“Penetration test” and “vulnerability scan” get used interchangeably in sales decks, and they shouldn't be. They cost different amounts, take different amounts of time, and find different classes of problem. Buying the wrong one wastes money — or worse, gives you false confidence.

The one-line difference

A vulnerability scan is automated: a tool checks your systems against a database of known issues and outdated software and produces a list. A penetration test is manual: a person tries to break in — chaining small weaknesses into a real compromise the way an attacker would — and writes up what they found and how.

What a scan is good at

• Finding known vulnerabilities — unpatched software, outdated libraries, missing security headers, default credentials, exposed services.
• Running often and cheaply — weekly, or on every deploy.
• Breadth — checking hundreds of hosts in minutes.

Scans are genuinely useful and every team should run one continuously. They're just not a substitute for a person.

What a scan misses

• Business logic flaws — “I can change the price in the request”, “I can view another user's invoice by changing the ID”, “the coupon applies a hundred times”. No scanner understands your app's rules.
• Chained attacks — a low-severity info leak, plus a weak password reset, plus a missing rate limit, equals account takeover. Scanners rate each finding alone; attackers combine them.
• Access-control gaps — whether user A can reach user B's data, or a normal user can hit an admin endpoint.
• Anything requiring context — knowing what's sensitive, what a realistic attacker wants, and what would actually hurt.

What a penetration test gives you

• A tester working by hand against your app, API, mobile app, network or cloud, using a methodology (OWASP Top 10, ASVS, MASVS) plus experience.
• Risk-rated findings with severity, real-world impact and step-by-step reproduction — written so developers can fix them, not just log them.
• An executive summary you can hand to a customer, an auditor or your board.
• Usually a retest after you've fixed things, and an attestation letter.

Which one does your situation call for?

• A customer or prospect is asking for a pen test report → penetration test. A scan report won't satisfy their security team.
• SOC 2, ISO 27001, PCI-DSS, HIPAA → penetration test, scoped to the control you're assessed against. Some frameworks also expect regular scanning between tests.
• You're shipping a major release → a targeted penetration test of the new surface area.
• You want continuous coverage between tests → automated scanning in your pipeline, plus a periodic manual test.
• You've never had an independent test → penetration test first, to establish a baseline.

How to tell a “pentest” quote is really a scan

• It's priced like a subscription, or costs less than a few thousand for a whole application.
• The deliverable is “a report from our platform”, with no named tester or methodology.
• There's no scoping call — a real test needs to understand your app before it can be quoted.
• No retest, no reproduction steps, no mention of manually testing business logic.

Cost and cadence, roughly

A vulnerability scanning tool is tens to low hundreds of dollars a month. A manual penetration test of a typical web app or API is a four-figure to low-five-figure engagement depending on scope, with a few days of testing plus reporting. Most teams test once or twice a year and after any significant change, and scan continuously in between.