Penetration test vs. vulnerability scan: what’s the difference?

Short answer: a vulnerability scan is an automated tool checking for known weaknesses; a penetration test is a human attacker, with permission, proving what can actually be exploited — including logic flaws and chained attacks no scanner can see. You need scans continuously and pen tests periodically (at least annually and after major changes).

Side by side

	Vulnerability scan	Penetration test
Performed by	Software	A human tester, assisted by tools
Finds	Known CVEs, missing patches, misconfigurations	Exploitable paths, business-logic flaws, chained weaknesses
Validates findings	No — false positives are common	Yes — every finding is reproduced
Shows impact	Severity score	Demonstrated impact: what data, what access
Authorization & logic bugs	Rarely	Core focus
Frequency	Weekly to continuous	Annually, and after significant change
Typical duration	Minutes to hours	One to three weeks of testing
Output	Long list sorted by CVSS	Prioritized narrative with evidence and fixes

What a scanner cannot find

Scanners work by pattern matching. They are blind to anything that requires understanding what the application is for:

• Broken object-level authorization (BOLA/IDOR) — changing /api/invoices/1001 to /1002 and getting another customer’s invoice. The response is a perfectly valid HTTP 200.
• Business-logic abuse — applying a discount twice, skipping a payment step, approving your own request.
• Chained attacks — an information leak plus an SSRF plus an over-privileged cloud role equals full account takeover, even though each piece alone scored “medium”.
• Multi-tenant isolation failures, race conditions and workflow bypasses.

These are exactly the classes behind most serious breaches of modern web applications and APIs.

Compliance: which do you need?

• PCI DSS 4.0 requires both: quarterly internal and external vulnerability scans (external by an Approved Scanning Vendor) under Requirement 11.3, and penetration testing at least annually and after significant changes under Requirement 11.4, including segmentation testing.
• SOC 2 does not name penetration testing explicitly, but auditors routinely expect an annual third-party pen test as evidence for monitoring and risk-assessment controls.
• HIPAA requires a risk analysis and periodic technical evaluation; a penetration test is the most common way to evidence it.
• Cyber insurance questionnaires increasingly ask for the date of your last external pen test.

Black, grey or white box?

• Black box — no information or credentials. Realistic for perimeter testing, but spends the budget on discovery.
• Grey box — test accounts for each user role plus API documentation. The best value for web applications and APIs, because authorization flaws are only visible when logged in.
• White box — source code and architecture access. Finds the most per hour; combine with secure code review for critical systems.

For SaaS products, a grey-box test with at least two accounts per role in two separate tenants is the minimum to properly test isolation.

What a good pen test report contains

1. An executive summary a non-engineer can act on.
2. Scope, methodology and dates (OWASP WSTG, PTES, NIST SP 800-115).
3. Each finding with severity (CVSS), affected assets, step-by-step reproduction, evidence and a specific fix.
4. Attack narratives showing how findings chain together.
5. A retest section confirming what was fixed.

If a report reads like reformatted scanner output, you bought a scan.

How to choose a tester

Ask: Who exactly will test, and what have they built or broken? Is the test manual? Do you test authorization with multiple roles and tenants? Is a retest included? Can you help us fix what you find?

geearr penetration testing is manual, grey-box by default, includes retesting, and is run by an engineer who can also write the fix.