VAPT essentials: vulnerability assessment versus penetration testing
The two are routinely sold as one service and confused in procurement. They answer different questions, and buying the wrong one is expensive.
"VAPT" bundles two genuinely different activities into one acronym, and the bundling causes real problems in procurement. Organisations regularly pay for a penetration test and receive a scan, or commission a scan when what the board actually asked for was a test.
Two different questions
A vulnerability assessment asks: *what known weaknesses exist across our estate?* It is broad, largely automated, repeatable, and it produces a list. The value is coverage — you can assess thousands of hosts.
A penetration test asks: *what can an attacker actually achieve?* It is narrow, human-led, and it produces a narrative. The value is depth — a tester chains three individually low-severity issues into full account takeover, which no scanner will ever report.
Neither is superior. They answer different questions, and mature programmes run both at different cadences.
What a vulnerability assessment finds
Scanners are excellent at what they do: missing patches, outdated components with published CVEs, weak TLS configuration, default credentials, absent security headers, exposed administrative interfaces, and known misconfigurations in cloud services.
These matter enormously. A substantial share of real-world compromise involves an internet-facing service missing a patch that was published months earlier. Scanning finds exactly that, cheaply and continuously.
What a vulnerability assessment misses
Anything requiring understanding of what your application is *for*.
- Can a user in one organisation read another organisation's records by changing an identifier?
- Can a discount code be applied repeatedly?
- Can the password reset flow be manipulated to take over an account?
- Can a low-privilege user reach an administrative function by calling the API directly?
- Can three minor information leaks be combined into something serious?
These are business logic flaws. There is no signature for them, because the vulnerable behaviour is indistinguishable from correct behaviour without knowing the intent. In our experience these account for the majority of high-severity findings in a well-maintained application — precisely because the patch-level issues have already been caught by scanning.
What a penetration test looks like
A tester starts by understanding the application: the roles, the workflows, where the money or the sensitive data sits. They map the attack surface, then work through it deliberately — attempting to access another user's data, to escalate privilege, to bypass a control, to reach something that should be unreachable.
When they find something, they prove it. The report contains the actual request, the actual response, and the steps to reproduce. This is what separates a finding from a hypothesis.
Choosing between them
Run vulnerability assessment when you need broad coverage, you have a large estate, you want continuous monitoring, or you need to demonstrate a patching cadence to an auditor. Run it continuously, not annually.
Run a penetration test when you are launching something new, you have significant business logic, a customer or regulator requires one, you handle sensitive data, or your architecture has materially changed.
Run both when you can. Scanning handles breadth and keeps the known-issue baseline clean. Testing handles depth and finds what scanning structurally cannot.
Questions worth asking a supplier
Before you commission anything:
- 1How much of this is manual? If the answer is vague, you are buying a scan.
- 2Are findings manually verified? Unverified scanner output wastes your engineers' time disproving it.
- 3Can I see a redacted sample report? This tells you more than any proposal.
- 4Who performs the work, and what are their credentials? Ask whether the person scoping is the person testing.
- 5Is retesting included? Fixes need verification, and paying separately for it discourages the verification.
- 6How is business logic covered? A supplier who cannot answer this specifically is not doing it.
A reasonable baseline
For most organisations: continuous automated scanning of the external estate, an annual manual penetration test of the primary application, and an additional test whenever something significant changes. Add continuous attack surface monitoring if your infrastructure changes frequently, which for most teams shipping regularly, it does.
The failure mode to avoid is annual scanning presented internally as a penetration test. It satisfies a checkbox and leaves the questions that actually matter unanswered.