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.
One weakness, two reports
Take that broken object-level authorisation, this time in an online shop's API, and look at how each service reports it.
An assessment, after its tool flagged the endpoint and a person confirmed it:
[High] Object-level authorisation not enforced (verified manually)
Endpoint: GET /api/v1/orders/{id} host: api.shop.example
Evidence: order 10453 belongs to customer B; customer A's session got 200
Fix: check on the server that the order belongs to the caller
A penetration test, with the goal agreed in advance ("read another customer's data without their account") and a sample size the rules of engagement allow:
Goal read another customer's personal data without their account
Step 1 signed in as test customer A; order ids are sequential
Step 2 GET /api/v1/orders/10453 with A's session -> 200, customer B's order
Step 3 each order carries the customer's name, address and phone number
Step 4 50 consecutive ids in the agreed sample -> 50 different customers
Impact any signed-in customer can read every customer's contact details
Cause the API checks that a session exists, not who owns the order
Both are correct. The first tells the developer what to fix. The second tells the board what was at risk and for how many people, and that is the line that moves a fix to the top of the queue.
Note: a flaw in business logic like this one is often invisible to a scanner. An assessment lists it only when the person verifying the results looks for it, which is one more reason a penetration test starts from a goal rather than from a tool's output.
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.
