Pentest vs. vulnerability scan: what your auditor actually wants

They get used interchangeably, they cost wildly different amounts, and picking the wrong one can fail an audit. Here's the real difference, and which one your compliance framework expects.

If you've ever received a $200 "penetration test" quote and a $20,000 one for what sounds like the same thing, this is why: one of them is almost certainly a vulnerability scan wearing a pentest's name. The two are genuinely different activities, and the difference matters, especially when an auditor is reviewing your evidence.

What a vulnerability scan actually is

A vulnerability scan is automated. A tool checks your systems against a database of known vulnerabilities (missing patches, outdated software, common misconfigurations) and produces a list. It's fast, cheap, and you can (and should) run it regularly, even continuously.

What it's good at: broad coverage, catching known issues, tracking your patch hygiene over time. What it can't do: it doesn't think. It won't chain two low-severity issues into a critical one, it won't find a business-logic flaw in your checkout, and it won't exploit an authorization gap to prove real impact. It also produces false positives: findings that look scary but aren't exploitable in your context.

What a penetration test actually is

A penetration test is human-led. A skilled tester uses tools to assist, but the core work is manual: understanding your application, thinking like an attacker, chaining weaknesses, and actually exploiting vulnerabilities to prove they're real and demonstrate the impact.

This is where the findings that fill real breach reports come from: broken access control, business-logic abuse, chained exploits, authentication bypasses. A scanner might flag "an endpoint exists"; a pentester changes one ID and walks out with every customer's data, then shows you exactly how and how to stop it. The deliverable is a report with verified findings, business impact, and specific remediation, plus, ideally, a retest.

Side by side

What your auditor actually wants

Here's the part that trips people up: most compliance frameworks expect a penetration test, not just a scan, but they use both.

• SOC 2 doesn't literally mandate a pentest, but auditors routinely expect one as evidence for the security criteria, alongside continuous scanning.
• PCI DSS explicitly requires both: regular vulnerability scans (including quarterly ASV scans) and an annual penetration test.
• ISO 27001 expects technical vulnerability management and testing as part of risk treatment; a pentest is the standard evidence.
• HIPAA requires a risk assessment; a pentest is how mature organizations evidence technical risk.

The pattern: scan continuously, pentest periodically. Scans keep you honest between tests; the pentest is the deep, human validation that satisfies auditors and actually reflects what an attacker could do.

How to tell which one you're being sold

If a "penetration test" quote is suspiciously cheap and fast, ask: Will a human manually test business logic and authorization? Will findings be exploited and verified, or just flagged? Is there a written report with reproduction steps, business impact, and remediation? Is a retest included? If the answers are vague, you're buying a scan with a markup, and your auditor may notice.

Key takeaways

• A scan is automated breadth; a pentest is human depth that proves real, exploitable risk.
• Do both: scan continuously, pentest periodically and on major changes.
• PCI explicitly requires both; SOC 2 and ISO effectively expect a pentest as evidence.
• If a "pentest" has no manual testing, no verified findings, and no report, it's a scan.

See the difference for yourself: download our free sample pentest report and compare it to any scanner output you've received.