Vulnerability assessment vs penetration testing: which one do you actually need?

Two security products. Two PDFs. Two invoices. Apparent overlap. Very different uses. Most teams we speak to are not clear on the difference, and they end up either paying for the wrong one or paying for both when they only needed one. Here is a clean working distinction.

The short version

A vulnerability assessment is broad and shallow. It uses scanning tools (Nessus, Qualys, OpenVAS, cloud-native scanners, dependency scanners) to enumerate known weaknesses across an estate. The output is a long list of findings with CVE numbers, severity ratings, and remediation guidance. It is largely automated, repeatable, and cheap relative to its coverage.

A penetration test is narrow and deep. A human tester attempts to actually exploit weaknesses to demonstrate impact. The output is a smaller number of findings, each with proof-of-concept exploit code or screenshots, and a narrative of how an attacker would chain them. It is largely manual, point-in-time, and expensive per finding.

You need a vulnerability assessment to know your inventory and patch hygiene. You need a penetration test to know what an attacker actually achieves against you. They answer different questions.

What each one catches (and misses)

Vulnerability assessment

Catches: known software vulnerabilities (unpatched libraries, outdated CMS plugins, vulnerable container images, missing security headers, expired certificates), misconfigurations (open S3 buckets, weak TLS, default credentials), and compliance-shaped issues (unencrypted volumes, public databases).

Misses: business-logic flaws, authentication bypasses that need a sequence of steps, IDOR (insecure direct object reference), broken multi-tenancy, race conditions, anything that requires actually thinking like an attacker. Scanners cannot reason about your application's intended behaviour, only about whether known patterns appear.

Penetration test

Catches: everything in the vulnerability assessment plus the business-logic class. A pentester will discover that the URL pattern /api/orders/[id] doesn't check ownership, that the JWT validation accepts none as an algorithm, that the password reset flow can be triggered for any account and the reset email goes to a user-controlled field, that the admin panel is reachable from the customer subdomain through a forgotten redirect.

Misses: things outside the agreed scope. Things behind a control the tester decided not to bypass (a WAF the client said not to circumvent, for instance). Things that only appear under production load. Things that require physical access or insider context the engagement doesn't include.

What it costs and what it takes

A vulnerability assessment for a typical SME estate (a website, an API, a small cloud footprint, internal devices) runs in days. It is mostly tool-driven with a security engineer triaging false positives and authoring the report. The right cadence is continuous (or at least monthly) on a retainer; running it once a year is hygiene theatre.

A penetration test for the same estate runs in weeks. Scoping conversation, reconnaissance, exploitation attempts, write-up, debrief, retest after remediation. Most fintech-grade engagements take one to three weeks of tester time depending on scope, plus a retest pass.

What auditors, regulators, and insurers actually want

This is where teams get tripped up. The answer is different per audience.

Cyber insurance broker. Increasingly asks for both. Vulnerability assessment evidence shows patch hygiene; pentest evidence shows you understand your residual risk. Some carriers will reduce premiums if you can demonstrate an active vuln-management programme plus an annual pentest.

Enterprise customer doing vendor diligence. Asks for a recent pentest report (or a redacted summary), plus evidence of ongoing vulnerability management. The redacted summary is more credible than a one-page scanner certificate.

FSCA / Prudential Authority (for licensed financial institutions). The Joint Standard 1 of 2023 (IT governance) and Joint Standard 2 of 2024 (cybersecurity and cyber resilience) require the board to satisfy itself that cyber risks are identified, assessed, and managed. Independent technical testing is how you demonstrate that. The standards do not prescribe vuln assessment or pentest specifically, but you need evidence of both.

SARB (for NPS participants). SARB Directive 1 of 2024 on cybersecurity and cyber resilience in the National Payment System sets explicit expectations around independent assessment and testing for payment system operators, clearing houses, and settlement participants.

Information Regulator (POPIA). Section 19 requires "appropriate, reasonable technical and organisational measures." After an incident, the Regulator will ask for the evidence of those measures. A current vuln-management programme plus a recent pentest is the credible answer. The Regulator has issued enforcement notices and administrative fines (capped at R10 million per infringement notice under section 109).

How to choose, or how to combine

If you have no existing programme: start with a vulnerability assessment to understand your inventory and patch backlog. You cannot defend what you don't know exists.

If you have basic patch hygiene but no application-layer testing: run a pentest on the customer-facing application. You will likely find business-logic issues that scanners can't see.

If you are a licensed fintech, regulated SaaS, or any business going through enterprise vendor diligence: run both. Continuous (or monthly) vuln management plus an annual pentest is the standard expectation. Twice-yearly pentest if you ship a lot of code or hold a banking licence.

If you are about to acquire or be acquired: pentest the target. Diligence pentests catch the surprises that materially affect the deal valuation.

What the report should actually contain

Whichever you commission, the report has to be something you can hand to a board, an auditor, or an enterprise prospect. The minimum:

Executive summary. One page, plain language, risk rating, top three findings, residual-risk statement.

Findings register. Each finding has a CVSS or equivalent severity, evidence (screenshot or output), reproduction steps, and a specific remediation. For pentest findings, a proof-of-concept demonstrates exploitability.

Methodology. What was in scope, what was out of scope, what tools and techniques were used, what was attempted and didn't work. This is how you defend the report's completeness later.

Retest commitment. Particularly for pentests. The first report is a problem statement; the retest is the sign-off.

A "vulnerability scan completed" one-pager is not a report. It is a marketing artefact. Stop accepting them.

If a vendor tries to sell you a "pentest" that takes them three days and consists of running a scanner and writing it up, they're selling you a vulnerability assessment with a more expensive sticker. Ask what tools they use, ask how many testing-hours are in scope, ask whether the report includes proof-of-concept exploits. The questions answer themselves.