Vulnerability Assessment vs Penetration Testing: What Each One Proves
Your auditor asks for the latest penetration test report. You open the shared folder and find a long PDF from the scanner, dated last month, findings sorted by severity. It looks like what they want. Is it?
It may not be, and it’s much better to find out now than in the audit meeting. The two documents look alike, but they answer different questions. One tells you what might be wrong. The other tells you what an attacker can actually do with it. Once you know which question you’re being asked, the buying decision gets easy.
The short version
A vulnerability assessment asks what is wrong with the things you run. It’s usually scan-led: a tool compares your systems against known weaknesses and misconfigurations, and someone ranks what it finds. It doesn’t try to show that an attacker could use any of them.
Penetration testing asks what can be broken. Testers take the weaknesses that look real, try them, chain them the way an attacker would, and record the proof at each step. VAPT sits in between: a scan for breadth, then a person confirms what the scan turned up. A red team is a further step again, testing the whole organization over a longer period, and it’s a different purchase from any of these.
The two tests side by side
| Vulnerability assessment | VAPT | Penetration test | |
|---|---|---|---|
| The question it answers | What known weaknesses do we have? | Which of the weaknesses a scan finds are real? | What can an attacker break, and how far can they get? |
| How the work is done | Mostly scanning, then ranking | A scan, then testers confirm findings by hand | Testers attack by hand, following paths that make sense for your system |
| What you receive | A ranked list of weaknesses | The list, with the confirmed items marked | Proven findings, each with the evidence behind it |
| Does it prove an attacker can use the weakness? | No | In part | Yes |
| What it can’t tell you | Whether a weakness leads anywhere, or what the scanner has no pattern for | What sits outside the scan and the confirmation | Everything outside the agreed scope, and anything that changes after the test |
| When it earns its place | Regular upkeep, between bigger tests | A broad check before a change | A launch, an audit, the annual cycle |
These are our plain-language descriptions of the three, not definitions from a standard. The “can’t tell you” row matters as much as the others. A penetration test is a picture of the scope you agreed, on the days it ran. A scan is thinner, but it keeps coming back. That’s why this isn’t a contest.
What a scanner isn’t built to notice
Here is a case from our files. A bank asked us to test its open-banking API, 27 endpoints in all. We found a fund-diversion flaw, and we found that signed requests could be replayed. Put together, they were the critical finding, and the bank had it fixed in 4 days.
We aren’t claiming a scan would have missed either one. What we can say is what each tool is built to look at. A scanner compares a system against known weaknesses: an out-of-date component, a missing security header, a weak encryption setting. A flaw that lets money go to the wrong place, or a signed request that is accepted again, is a question about how the API behaves when someone uses it in a way its designers didn’t intend, and that is the kind of question a tester sits down and asks. In our experience that’s where testers earn their keep, and it’s why we’d never hand you a scan and call it a penetration test.
The reverse is just as true. Nobody should run a manual penetration test every week to catch an outdated library.
How the people who review your file read them
What an auditor reads for is which question the document answers and whether you acted on it.
ISO/IEC 27001:2022 doesn’t name a test type or a schedule. Your own risk assessment does. Two Annex A controls are relevant: 8.8, management of technical vulnerabilities, and 8.29, security testing in development and acceptance. In our reading, the first is where regular assessments sit and the second is where a test before go-live fits, though your own risk assessment has the final say.
SOC 2 files them in different places. Vulnerability scanning shows up under CC7.1, while CC4.1, which is about separate evaluations, lists penetration testing among its examples. Those examples are illustrative, so your auditor decides how much weight each one carries.
PCI DSS v4.0.1 has a penetration testing requirement of its own. Requirement 11.4 asks for penetration testing at least every 12 months and after significant change, by a qualified tester who is organizationally independent. A scan export is a different activity and won’t stand in for it. The details are in our piece on PCI DSS 11.4 penetration testing requirements.
Which one, in which situation
Start with a vulnerability assessment if what you want is a steady view of what’s exposed, and run it on a regular rhythm. It’s the lightest way to keep the list current, and it’s the continuing record that supports technical vulnerability management.
A new application or API about to go live calls for a penetration test. Launches are when someone senior has to sign, and a signature on “we scanned it” is thin. Tell the testers whether it’s a web application or an API so the scope fits the system: user journeys and roles in one, endpoints, tokens and partners in the other.
Heading into an audit or an annual cycle? Buy the penetration test with a retest, so the file shows that exploitable findings were fixed and checked, and keep the assessments running alongside it. Together they show you keep looking and you close what matters.
What to ask a provider
Ask how a finding gets proven. If the answer is “the tool rated it high”, you’re buying an assessment, whatever the proposal calls it. At Snipeyes every finding is confirmed and the proof recorded, and if we can’t show it’s real it isn’t in the report.
Then look at the report itself. You want a short summary your leadership can read, enough detail for engineers to reproduce and fix each item, and control mapping your assessor can follow. And find out what happens at retest, since that’s where “found” becomes “fixed” in your records. For what an assessor looks for in the file, see penetration testing for compliance.
Accreditation is the third check, and it applies to the company. Snipeyes is a CREST Member (CREST is the accreditation body for penetration testing providers) and is certified to ISO/IEC 27001:2022, and we share the certificate and scope during procurement.
Questions readers ask
Is VAPT the same as a penetration test? Not quite. VAPT pairs a scan, which gives breadth, with manual confirmation of what the scan found. A penetration test goes further: testers try the weaknesses, chain them, and record the proof of what an attacker could reach.
Can a vulnerability scan replace a penetration test? No, because they answer different questions. A scan keeps your list of known weaknesses current. A penetration test shows which of them can be used, and finds flaws a scan has no pattern for. They work on different schedules: the scan often, the test at launch, at audit time or after a major change.
Can the report be used for our audit? Findings in a Snipeyes report are mapped to ISO/IEC 27001:2022, SOC 2, PCI DSS 4.0 and your regulator’s rules. Your auditor decides what evidence is enough, so check the report’s structure with them before you buy.
Before you write the next purchase order
Three things to settle. Which question are you being asked right now: what’s exposed, or what can be broken? Who will read the result, an engineer, your board or an assessor? And when is the retest, because the date for that is easier to agree before testing starts than after.
If you already know the answer, request a scoped proposal. If you’re not sure which test your next audit or launch calls for, book a free 90-minute scoping session and we’ll tell you plainly, even if the answer is a vulnerability assessment and not a penetration test. Retest is included in our penetration testing.