Two services are often quoted under one name, and the confusion costs money in both directions: teams buy a penetration test when they needed a broad assessment, or a scan when they needed someone to actually break in. The distinction is not academic. It decides the price, the timeline, what the report can claim, and what an auditor will accept.
The one-sentence versions
A vulnerability assessment answers: what weaknesses exist across these systems, and how severe are they? It is broad, largely tool-driven, verified by a person, and produces a prioritised inventory.
A penetration test answers: can a motivated attacker achieve a specific goal against this target, and how? It is narrow, hypothesis-driven, performed by a person, and produces demonstrated impact — a chain, not a list.
How the work actually differs
| Vulnerability assessment | Penetration test | |
|---|---|---|
| Question | What is wrong, everywhere? | What can be achieved, here? |
| Breadth | Every host, service and version in scope | One application, network segment or goal |
| Method | Authenticated scanning, configuration review, manual verification of results | Manual exploitation, chaining, custom tooling, logic abuse |
| Exploitation | No — findings are confirmed, not exploited | Yes — within agreed rules of engagement |
| Standard | CIS benchmarks, vendor baselines, CVE severity | OWASP WSTG / ASVS, PTES, MITRE ATT&CK techniques |
| Output | Inventory of findings with severity and fix | Findings plus attack narrative and business impact |
| Typical duration | Days | One to three weeks |
| Repeatability | Designed to run monthly or continuously | Point in time, repeated annually or after major change |
| What it cannot tell you | Whether the weaknesses combine into a breach | Whether the other hundred systems are patched |
The row that matters most is exploitation. An assessment confirms that a weakness is present; a test proves what it leads to. A missing security header and a broken object-level authorisation both appear in an assessment as findings. Only a test shows that the second one exposes every customer's records, and that is the sentence the board needs.
What each is for
Order an assessment when you need coverage: a first look at an estate, a compliance requirement for periodic scanning, a check after a patch cycle, or a baseline before a larger programme. It is the right tool for "we don't know what we have" and for "prove we are patched".
Order a penetration test when you need assurance about something specific: a new customer-facing application before launch, a payment or identity flow, an internal network after a merger, a system that handles regulated data, or a claim you are about to make to a customer or regulator. It is the right tool for "could someone get in through this" and for "what would they get".
Order both, sequenced, when an estate has never been looked at. Assess first to fix the obvious and reduce noise; test second so the tester's time goes to logic and chains rather than to unpatched services a scanner would have listed for a fraction of the cost.
Three mistakes we see in procurement
- Buying a test and receiving a scan. If the proposal has no named tester, no rules of engagement, no exploitation clause and a fixed price per host, it is an assessment. That may be fine — but pay assessment prices for it.
- Buying a scan and calling it a test. Compliance frameworks that require a "penetration test" mean manual exploitation. A scanner report with a new cover will not survive a competent audit.
- Testing before assessing. A penetration tester who spends the first week on missing patches is doing an assessment at test rates.
How to read the price
An assessment is priced by breadth: hosts, IPs, applications. A penetration test is priced by time: days of a named person against a defined target. If a quote for a "penetration test" is priced per host, or a quote for an "assessment" is priced per day with a goal, the vendor is describing the other service. Ask them to rename it, then compare like with like.
A rule for this quarter
If you cannot yet list your internet-facing systems with their versions, buy the assessment. If you can, and one of them is about to carry money, identities or regulated data, buy the test for that one. Almost nobody needs a penetration test of everything; almost everybody needs an assessment of everything and a penetration test of the two or three things that matter.