Penetration test vs. vulnerability scan: which do you need?

We are asked for a penetration test at least once a week by someone who actually needs a vulnerability scan, and occasionally the reverse. The words get used interchangeably in procurement documents, which is unfortunate, because the two produce very different things and cost an order of magnitude apart.

What a vulnerability scan is

A vulnerability scan is automated. A tool connects to your systems, identifies the software and versions in use, and compares what it sees against a database of known issues. It reports missing patches, outdated libraries, weak TLS configuration, exposed services and default credentials.

It is fast, cheap and repeatable. A scan of a modest external estate finishes in hours and can be run weekly or nightly. That repeatability is its real value: it catches the server someone spun up last Tuesday and forgot, and it tells you when a newly published CVE affects something you run.

Its limitation is that it only knows what it has been told to look for. It cannot reason about your application's logic, it cannot chain two harmless-looking issues into a serious one, and it produces false positives that a human has to triage.

What a penetration test is

A penetration test is a person — usually a small team — working against your systems with a defined goal, within an agreed scope, for an agreed period. They use automated tools as a starting point, then do the part that tools cannot: understand what the application is for, work out what an attacker would actually want, and try to get it.

The findings look different. Instead of "TLS 1.0 enabled on port 443", you get "a member-level user can retrieve any other customer's export by changing one identifier, and here is the request that does it". Instead of a CVE list, you get a chain: this low-severity information leak reveals internal hostnames, which exposes an admin interface, which accepts a default credential.

It costs more and takes longer — typically one to three weeks depending on scope — and it is a point-in-time snapshot rather than a continuous control.

Choosing between them

The honest short answer is that these are not alternatives. Scanning is a hygiene control you run continuously; testing is a periodic deep assessment. Most organisations of any size need both, in that order — there is little point paying a tester to find the missing patches a scanner would have told you about for a fraction of the cost.

If you have to start with one, the deciding question is what you are trying to learn:

• Start with scanning if you do not currently have a reliable inventory of what you expose to the internet, or if patching is inconsistent. You have basic hygiene to establish first.
• Go straight to a penetration test if the risk that keeps you awake is in custom software — your own application, your own API, your own permission model. A scanner will tell you almost nothing about code you wrote yourself.
• Go straight to a penetration test if an enterprise customer, a partner or a regulator is asking for evidence of independent testing. A scan report will not satisfy that request, and sending one usually costs you a round trip.

What about the things in between

Two other terms show up in quotes and are worth separating. A vulnerability assessment is a scan plus human triage: someone removes the false positives and ranks what is left by real business impact. It is a reasonable middle option when you have a large estate and need prioritisation rather than depth. A red team exercise goes the other way — broader scope, longer duration, and it tests your detection and response as much as your defences. It is the wrong purchase for an organisation that has not yet had a straightforward penetration test, because it will tell you that you were breached without telling you how to fix the twenty ordinary things that let it happen.

Questions worth asking a provider

• How much of this engagement is manual, and who specifically performs it?
• Will you test with multiple user roles, and is authenticated testing included?
• What does the deliverable contain besides a tool export — is there a technical report and a summary a non-specialist can act on?
• Is retesting of fixed findings included, and for how long?
• How is scope agreed and authorised, and what happens if something outside it is discovered?

A provider that answers the first question with a percentage and the last one with a process is doing this properly. One that cannot distinguish its own service from a scan is selling you the cheaper thing at the more expensive price.

Rule of thumb: scanning answers "am I missing patches?" Testing answers "can someone actually get in, and what would they reach?" If you need the second answer, the first tool cannot give it to you.