Pentest vs Vulnerability Scan: What's the Difference?

When a customer’s security questionnaire asks for “your latest penetration test”, teams sometimes send a vulnerability scan report. It looks similar: a PDF, a list of findings, colour-coded severities. Then the questionnaire comes back with a follow-up, or the auditor asks for something else.

The two are related, and both are useful. But they answer different questions, and mixing them up costs time when it matters most. This guide explains what each one is, where each fits, and why scan output so often falls short as evidence.

The short answer

A vulnerability scan is an automated tool checking your systems against a large library of known weaknesses. It asks: “Do any of the problems we already know about exist here?”

A penetration test is a person, or a small team, trying to break in within an agreed scope. It asks: “What could a capable attacker actually do to this system, and how far could they get?”

One is a checklist run by software. The other is an investigation run by people, who use software along the way.

What a vulnerability scan does well

Scanners are good tools, and every security programme should use them. They:

• Run quickly and often. A scan can run every night, on every deployment, or whenever a new advisory comes out.
• Cover a lot of ground. They can check thousands of hosts, ports and pages for known issues in one pass.
• Catch the basics consistently. Missing patches, outdated libraries, weak TLS settings, exposed admin panels and default configurations are exactly what scanners are built for.
• Track change over time. Repeated scans show whether your exposure is shrinking or growing.

For a lot of common weaknesses, a scanner is the right tool. Paying a human to check patch levels by hand would be a waste.

Where scanners struggle

Scanners work by matching patterns. Problems that don’t match a known pattern are hard for them to see. In particular, they struggle with:

• Authorization. A scanner usually can’t tell that user A shouldn’t see user B’s invoice. Both requests look perfectly normal. It doesn’t know your business rules.
• Business logic. Applying a discount twice, skipping a payment step, or approving your own request are flaws in how the product works, not in a library version.
• Chained attacks. An attacker might combine a low-severity information leak with a weak password reset to take over an account. A scanner reports each piece separately, if it sees them at all, and can’t judge the combined impact.
• Context. Scanners can’t tell whether a finding is reachable, exploitable or important in your environment. That leads to false positives, which waste engineering time, and false negatives, which give false comfort.

What a penetration test adds

In a penetration test, a tester works through your system with a goal: find the weaknesses that matter, prove them, and explain how to fix them. A good tester:

• Learns how the system is supposed to work by walking through its roles, workflows and trust boundaries.
• Tests the assumptions behind it. What if this ID belongs to another tenant? What if this step is skipped? What if this token is reused?
• Uses tools for coverage, including scanners, proxies and fuzzers, then verifies every result by hand.
• Chains findings together to show the realistic worst case, not just a list of separate issues.
• Proves impact with a safe proof of concept, so there’s no argument about whether an issue is real.
• Prioritises by business risk, so your team fixes what matters first.

The output is different too. A pentest report should explain the scope and method, describe each finding with evidence and reproduction steps, and give remediation advice written for your engineers. After you’ve fixed the findings, a retest confirms they’re closed. You can see how we structure this on our methodology page, or request a sample report to see a real example.

Side by side

	Vulnerability scan	Penetration test
Who does it	Automated tool	Experienced tester, supported by tools
Main question	Are known weaknesses present?	What can an attacker actually achieve?
Typical frequency	Continuous, weekly or per deployment	At least yearly, and after significant change
Finds	Missing patches, outdated components, misconfigurations, known CVEs	Authorization flaws, logic abuse, chained attacks, plus many of the scanner’s findings
False positives	Common, need triage	Removed: every finding is verified by hand
Business context	None	Central to the work
Output	Long list of findings, often generic	Prioritised findings with evidence, impact and fixes
Typical use as evidence	Supports vulnerability-management controls	What auditors and customers usually mean by “pentest”

Why scans are often rejected as evidence

This is where the difference matters most. When an auditor, an enterprise customer or an investor’s due-diligence team asks for a penetration test, they usually want proof of three things:

1. Someone independent tried to break your system with realistic attacker thinking, not just a pattern-matching tool.
2. The scope was meaningful. It covered the product and data they care about, with a stated methodology.
3. You acted on the results. There is evidence that findings were fixed and retested.

A raw scan report rarely shows any of these. It doesn’t show that anyone thought about your authorization model. It often contains unverified findings that nobody has triaged. And it says nothing about what an attacker could do once they chained issues together.

That’s why security questionnaires often ask specifically for a manual penetration test, a summary letter from the testing firm, or confirmation that critical findings were fixed.

Compliance frameworks draw the same line

Some frameworks make the distinction explicit. PCI DSS (currently v4.0.1) treats them as separate requirements:

• Requirement 11.3 covers vulnerability scanning: internal scans and external scans by an Approved Scanning Vendor (ASV), each at least once every three months.
• Requirement 11.4 covers penetration testing: a documented methodology, internal and external testing at least every 12 months and after significant changes, correction of exploitable findings, and segmentation testing where segmentation is used.

Passing one requirement doesn’t satisfy the other. Our PCI DSS page goes into detail.

Other frameworks, such as SOC 2 and ISO 27001, are less prescriptive. They describe outcomes rather than naming specific tests. In practice, though, auditors commonly look for a penetration test as evidence that you evaluate your controls and manage technical vulnerabilities. Scan results support that story but rarely complete it. If you’re unsure, ask your auditor early. It’s much easier to plan a test than to scramble for one a few weeks before the audit window.

When to use each

You don’t have to choose one. Most mature teams use both, for different jobs.

Use vulnerability scanning when you want to:

• Catch newly published vulnerabilities in your dependencies and infrastructure quickly
• Check every deployment or infrastructure change for obvious regressions
• Keep an ongoing view of your external attack surface
• Meet scanning requirements such as PCI DSS 11.3
• Track patching performance over time

Use a penetration test when you need to:

• Provide evidence for SOC 2, ISO 27001, PCI DSS 11.4, or a customer security review
• Check a new product, major feature or architecture change before or soon after launch
• Understand real-world risk in a multi-tenant SaaS platform, where one customer must never see another’s data
• Test authentication, SSO, payments or other high-value flows in depth
• Validate cloud permissions, Active Directory attack paths or network segmentation
• Get an independent view your engineers and leadership can act on

A sensible combined approach

For most software companies, a practical rhythm looks like this:

1. Scan continuously. Add dependency and container scanning to your build pipeline, and scan your external footprint regularly. Triage results and fix what’s real.
2. Pentest periodically. Run a manual penetration test at least once a year, timed so the report is ready before your audit or renewal cycle.
3. Pentest after significant change. A new product area, a rebuilt authentication system, a move to a new cloud environment or a major API version all warrant a fresh look.
4. Retest after fixing. Close the loop, so the report shows findings as fixed and not just found.
5. Feed the results back in. Use pentest findings to improve your scanning rules, code review checklists and developer training, so the same class of issue doesn’t come back.

Questions to ask a provider

If you’re commissioning a test, these questions help separate a real penetration test from a scan with a new cover page:

• How much of the testing is manual, and how much is automated?
• Will you test authorization between roles and between tenants?
• Do you verify every finding by hand before it goes in the report?
• What methodology do you follow, and will it be stated in the report?
• Is a retest included, and will the report show which findings are fixed?
• Can we see a sample report first?

If the answers are vague, or the sample report is mostly scanner output, you’re probably looking at a scan.

Summary

Vulnerability scans and penetration tests are complementary. Scans give you breadth, speed and continuous coverage of known issues. Penetration tests give you depth, context and proof of what an attacker could actually do. Auditors and customers usually want the second, but you should have both.

If you need a test for an audit, a customer review or a major release, see our web application, API and external network testing, or get in touch to scope it.