Vulnerability Scan or Penetration Test: Which One You Actually Need

A scan and a test are frequently quoted against the same requirement, at wildly different prices, and a buyer with no way to tell them apart reasonably chooses the cheaper one. Here is the difference in terms of what each actually produces.

What a scanner does

A vulnerability scanner sends known probes and compares responses against a database of known conditions. It is very good at breadth: it will check thousands of things across hundreds of hosts faster than any person, and it will find the unpatched service, the expired certificate, the header that is missing, the default credential that was never changed.

Those are real findings and they matter. A scanner is also tireless and repeatable, which makes it the right tool for the question "has anything drifted since last month".

What a scanner cannot do

It cannot reason about YOUR application. A scanner does not know that a user in one organisation should not be able to read another organisation’s invoices, because that is a rule from your business rather than a published vulnerability. Nothing in a signature database describes it.

• Authorisation flaws. The most commonly exploited class in modern applications, and the one a scanner is structurally unable to find, because it requires knowing who ought to be allowed to do what.
• Business logic. Ordering a negative quantity, applying a discount twice, skipping a step in a workflow.
• Chained weaknesses. Three medium findings that individually mean little and together mean an account takeover. A scanner reports items; it does not compose them.
• Anything behind a login it cannot get through. An unauthenticated scan of an authenticated application checks the login page.

What a test costs you that a scan does not

Time and money, obviously, but also involvement. A useful penetration test needs accounts for each role, a working environment, somebody available to answer questions, and a scope conversation that takes an hour. A scan needs a target and a credential set, and can run overnight without anybody present.

That difference in effort is why the two get confused. It is easy to buy a scan and difficult to buy a test badly, so a quote that requires nothing from you is worth a second look at what it is quoting for.

How to tell which one you were sold

Read the report rather than the invoice.

• Findings with plugin identifiers, CVE references and no narrative are scanner output.
• Every finding at exactly the severity the tool assigned, with no adjustment for your context, means nobody reviewed them.
• No findings about your own roles or workflows means nobody exercised them.
• A reproduction section that says "run the scanner" is not a reproduction section.
• Conversely, a report describing an attack path across several findings, in the language of your own application, is somebody’s work.

None of this makes scanner output worthless in a report. Most real engagements begin with a scan, because ruling out the known and unpatched quickly is exactly what the tool is for. The question is whether anything happened afterwards.

The middle option nobody names

Between the two sits an arrangement most firms will sell and few advertise: a scan reviewed by a person. Somebody runs the tool, discards the noise, verifies what is left is real, adjusts the severities to your context and writes the ten that matter into proper findings. It is a fraction of the cost of a full test and worth considerably more than raw output.

It is also the honest description of what a lot of cheap "penetration tests" actually are. That is not a scandal if it is what you were told you were buying. It becomes one when it is sold as something else, and the way to tell is to ask directly: how many days of manual testing are in this, and what will be done in them?

What the words mean in a contract

If a customer contract, a framework or an insurer requires penetration testing, a scan report will usually not satisfy it, and finding that out at renewal is expensive. Some frameworks say so explicitly; others say it in effect by requiring evidence of manual testing or a named tester.

Read the requirement before buying, and if it is ambiguous, ask the party who wrote it. A short email confirming that scanning satisfies their requirement is cheaper than a test, and a short email confirming it does not is cheaper than a failed audit.

The answer for most organisations is both, at different frequencies

Scan often, because drift is continuous and cheap to catch. Test at a cadence that matches how fast your application changes, because logic and authorisation are what people actually exploit and neither shows up in a scan.

Where budget is genuinely limited, the harder question is which single thing to buy, and the answer depends on the system. For a fleet of servers and network devices, a scan finds most of what is realistically going to be used against you. For a multi-tenant application holding other people’s data, a scan will not find the thing that ends up in the press, and one properly scoped test is worth more than a year of scanning.