Vulnerability Scan or Penetration Test: Which One You Actually Need

A vulnerability scan uses automated tools to check for known weaknesses such as missing patches, expired certificates and default credentials; a penetration test has a person work out what is wrong about your system specifically, such as one customer being able to reach another customer's data. The two are frequently quoted against the same requirement at very different prices, and a buyer with no way to tell them apart reasonably chooses the cheaper one.

What a vulnerability scan does

A vulnerability scan sends known probes and compares the responses against a database of known conditions. The automated tools behind it are very good at breadth: they will check thousands of things across hundreds of hosts faster than any person, and they 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. Automated tools are also tireless and repeatable, which makes a vulnerability scan the right answer to the question "has anything drifted since last month".

What automated tools cannot do

They cannot reason about your application. A tool does not know that a user in one organisation should not be able to read another organisation’s purchase orders, 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 automated tools are structurally unable to find, because it requires knowing who ought to be allowed to do what. Testing authorisation properly shows what the human version involves.
• 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 tool reports items; it does not compose them.
• Anything behind a login it cannot get through. An unauthenticated vulnerability scan of an authenticated application checks the login page.

What a test costs you that a vulnerability 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 vulnerability 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 vulnerability 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. What a penetration test costs explains what a realistic quote contains.

How to tell which one you were sold

Read the report rather than the bill, and compare it with what a penetration test report should contain.

• Findings with plugin identifiers, CVE references and no narrative are tool 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 "rerun the tool" 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 tool output worthless in a report. Most real engagements begin with automated tools, because ruling out the known and unpatched quickly is exactly what they are 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 vulnerability scan reviewed by a person. Somebody runs the tools, discards the noise, verifies that 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 vulnerability 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 a vulnerability scan satisfies their requirement is cheaper than a test, and a short email confirming it does not is cheaper than a failed audit. For cloud estates there is a third option again, covered in configuration review or penetration test.

The answer for most organisations is both, at different frequencies

Run vulnerability scans 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 vulnerability 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 vulnerability scan finds most of what is realistically going to be used against you. For a multi-tenant application holding other people’s data, automated tools will not find the thing that ends up in the press, and one properly scoped test is worth more than a year of vulnerability scans.