Fundamentals
Vulnerability assessment vs penetration test
Published Updated 5 min read
The short answer
A vulnerability assessment identifies and ranks weaknesses in your systems, while a penetration test goes further by actively exploiting them to prove what an attacker could achieve. In practice the security market uses both terms loosely, so the label on a proposal tells you less than the answer to one question: will a person prove each finding by hand?
What is the textbook difference?
NIST's glossary, drawing on the Committee on National Security Systems, defines a vulnerability assessment as a systematic examination of a system to determine the adequacy of security measures and identify security deficiencies. The emphasis is on finding and evaluating weaknesses.
NIST SP 800-115 defines penetration testing as testing in which evaluators mimic real-world attacks to circumvent security features, often using real attacks on real systems and looking for combinations of vulnerabilities. The emphasis is on exploitation and impact.
So in the classic model, an assessment asks "what is wrong?" and a penetration test asks "what can someone do with it?"
Why are the terms so confusing?
Because providers use them in at least three different ways, and none of them is wrong by dictionary standards:
| What the provider means | What actually happens | How close to a pentest |
|---|---|---|
| Scan-only assessment | Automated scanners run, results are lightly reviewed and packaged as a report | Not close: no exploitation |
| Scan plus manual validation | Scanners run, an analyst checks which findings are real and removes false positives | Partway: confirms existence, rarely proves impact |
| Focused, hand-proven assessment | Testers hunt for the highest-impact issues, exploit each by hand, and retest fixes | Close: it is penetration testing with a narrower, prioritized scope |
The word "penetration test" has the opposite problem. Some offerings sold under that name are mostly scanner output with a new cover page. Neither label guarantees what you are buying.
How do they differ in practice?
| Vulnerability assessment (classic) | Penetration test | |
|---|---|---|
| Goal | Inventory and rank weaknesses | Prove what an attacker can reach |
| Exploitation | None, or minimal confirmation | Yes, within agreed rules of engagement |
| Coverage style | Broad, aims to list everything | Deep, follows attack paths |
| Finds business logic flaws | Rarely | Yes, a core focus |
| False positives | Possible, depends on validation | Low, findings are demonstrated |
| Output | Prioritized list, often by CVSS | Narrative of attack paths, evidence and fixes |
| Best for | Baseline hygiene and patch planning | Assurance, compliance and high-value systems |
What does Brexa mean by "vulnerability assessment"?
We should be candid about our own naming. Brexa's one-time vulnerability assessment is the third row in the table above. It is a focused, time-boxed engagement aimed at the vulnerabilities you would patch first, such as exposed customer data or an authentication bypass. Each one is exploited and proven by hand, handed over ready to fix, and retested before the engagement closes.
How do you tell what you are actually buying?
Ignore the product name and ask these questions of any proposal:
- Will a person attempt to exploit each finding, or only confirm it probably exists?
- Will you test business logic and authorization between users and roles?
- Will you try to chain lower-severity issues into a larger attack path?
- What proportion of the time is manual testing versus automated scanning?
- Can I see a redacted sample report? Does it show evidence, or just scanner IDs?
- Is a retest of fixes included?
The answers tell you which row you are in. For a fuller checklist, see how to choose a penetration testing company.
What does the difference look like on a real finding?
Take a common case: an API endpoint returns an order when given an order number, and the number in the request can be changed. Here is how each approach typically reports it.
- Scan-only assessment: probably nothing. The request and response look normal, so no signature fires. If anything is flagged, it is a generic note such as "sequential identifiers in use".
- Scan plus manual validation: an analyst may notice the identifier pattern and record a possible IDOR, rated medium, with a recommendation to review authorization.
- Hand-proven assessment or penetration test: a tester logs in as two different customers, shows that customer A can read customer B's orders including names and addresses, estimates how many records are reachable, and rates it by real impact. The report includes the exact request pair as evidence and a specific fix: enforce an ownership check on the server for every object lookup.
The weakness is identical in all three. What changes is whether anyone proved it, and therefore whether your engineers treat it as a backlog item or fix it this week. This class of flaw, broken access control, is ranked first in the OWASP Top 10:2025 precisely because it is common and hard to detect automatically.
Where does each fit in a security program?
The NCSC frames it well: your organization's own vulnerability assessment and management process should be the primary way you find weaknesses, and a penetration test is how you check that the process works. In that model the two are layers rather than alternatives.
| Layer | Typical frequency | Purpose |
|---|---|---|
| Automated scanning | Continuous or weekly | Catch known, unpatched issues and configuration drift |
| Classic vulnerability assessment | Periodic, or after big infrastructure changes | Inventory and prioritize weaknesses for patch planning |
| Hand-proven assessment or penetration test | Yearly, per major release, or continuous | Prove real attack paths and verify that fixes hold |
Frequency guidance is in how often to penetration test.
Which one do you need?
- Mostly packaged software and infrastructure, no custom app: a scan-based assessment plus a patching routine is a sensible start.
- A custom application or API with sensitive data: you need exploitation by a human, whether it is called a focused assessment or a penetration test.
- A compliance requirement that names penetration testing, such as PCI DSS Requirement 11.4: buy something that meets the requirement's wording and scope, and confirm with your assessor.
- Systems that change weekly: consider continuous penetration testing instead of relying on a single point-in-time exercise.
Frequently asked questions
Is a vulnerability assessment cheaper than a penetration test?
A scan-based assessment usually is, because it needs less skilled human time. A hand-proven assessment can cost similar to a pentest of equivalent scope, since the work is similar.
Does a vulnerability assessment satisfy PCI DSS penetration testing requirements?
A scan-only assessment does not; PCI DSS treats scanning and penetration testing as separate requirements. Whether a hand-proven assessment qualifies depends on its scope and method, so confirm with your Qualified Security Assessor.
Should I do a vulnerability assessment before my first penetration test?
It often helps. Fixing the obvious, scanner-detectable issues first means penetration testers spend their time on deeper problems instead of rediscovering missing patches.
Sources
Written and reviewed by the Brexa team. Educational information, not legal or compliance advice. See our editorial policy.
Keep reading
Find out what an attacker could do with your systems.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.