3 September 2026LANTEK Computers
These two get used interchangeably, including by people selling them, and the price difference between them is large enough that the confusion is expensive in both directions. Businesses buy a scan when they needed a test, and are surprised the report found nothing conclusive. Or they buy a test when a scan would have done, and pay for skilled human time to confirm what an automated tool would have listed.
The distinction is not really about depth. It is about which question you are asking.
A vulnerability scan answers: what is exposed?
A scan is automated. It looks at your systems, works out what software and versions are running, and compares that against known weaknesses. Then it produces a list, usually ranked by severity.
What it is good at is coverage and repetition. It can look at everything you own, it does not get bored, and running it again next month costs almost nothing. That repeatability is the point: the value of scanning is the trend, not the snapshot. A list of findings that is shorter than last month’s is evidence that something is working.
What it cannot do is judgement. A scanner reports that a service is running a version with a known flaw. It does not know that the service is only reachable from inside your building, or that the flaw needs a precondition your configuration does not meet. So scan output contains findings that are technically true and practically irrelevant, alongside findings that matter urgently, ranked by a severity score that knows nothing about your business.
Which is why an unread scan report is such a common object. Somebody receives four hundred findings, cannot tell which of them matters, and files it.
A penetration test answers: what could somebody actually do?
A test is a person. Somebody with permission attempts to achieve something specific against your systems, the way an attacker would, and then documents how far they got and how.
The difference is chaining. Real compromise is rarely one flaw. It is a low severity thing plus a misconfiguration plus a password that was reused, combined in an order no scanner would try. A tester finds that a service nobody documented is reachable, that its credentials are the default, that the account it runs under has more rights than it needs, and that from there the file server is available. Individually those might each be scored as moderate. Together they are the whole building.
The output is different too. Not a ranked list, but an account of what was achieved, in what order, with evidence, and what would have stopped it. That narrative is what makes findings actionable, and it is what makes the report usable with people who are not technical, because it describes consequences rather than versions.
What a test is not good at is coverage and repetition. It is a point in time, it is scoped to what you agreed, and it costs skilled human days. Running it monthly makes no sense.
Which one you need
You need scanning, continuously, if you have systems. That is not a hedge. New weaknesses are published constantly against software you already run, so the exposure list changes without you doing anything. Scanning is how you find out. It should be a routine, not an event, and it belongs with patching rather than beside it. That is the case made on Vulnerability Scanning.
You need a test when the question is what would happen. Typically that is one of these situations:
- A client, insurer or tender requires one, which is increasingly common and is a perfectly good reason
- Something significant changed: a new application exposed to the internet, an office move, a migration
- You hold information where a breach would be serious, and you want to know rather than assume
- The board has asked how exposed the business is, and a list of versions will not answer them
- You have been remediating scan findings for a while and want to know whether it actually helped
You need both, in an order. Scan first, fix what it finds, then test. A test whose main finding is that you have not patched anything is an expensive way to learn what a scan would have told you cheaply. Sequencing them this way means the human time goes on the things automation cannot see.
Questions worth asking whoever you buy from
For scanning: how often, does it cover internal systems as well as internet facing ones, and crucially, who triages the output? Unfiltered scanner output delivered monthly is not a service. Somebody deciding which findings matter for your business is.
For a test: what exactly is in scope and what is excluded, who is doing it and what are their credentials, will you receive the narrative and the evidence rather than tool output, and is a retest after remediation included? That last one matters more than people expect, because a finding is only closed when somebody has confirmed the fix works.
Also ask what happens if they find something critical mid engagement. The answer should be that they stop and telephone you, not that it appears in the report a fortnight later.
Two things that are neither of these
An automated tool with a report that says penetration test on the cover. This is sold, and it is a scan. The tell is that no human hours are quoted and the turnaround is same day. Nothing wrong with the scan; a lot wrong with the label.
A vulnerability assessment. Sits legitimately between the two: a scan plus a person interpreting it for your environment, without the attempt to exploit. Genuinely useful and often the right first purchase. Just establish which of the three you are being quoted for, because the word assessment is doing a lot of work.
What the reports are actually for
A useful test report has two halves. One that a director can read, saying what could happen and what it would cost. One that whoever fixes things can work from, with enough detail to reproduce each finding.
If you get only the technical half, nobody senior will act on it. If you get only the summary, nobody can fix it. Ask to see a redacted example before you commit, which any competent provider will have ready.
Where to start
If you have never done either, start with scanning, because it is cheap, repeatable and will occupy you productively for a while. Book a test once the obvious findings are closed and you want to know what is left.
The two services are on Vulnerability Scanning and Penetration Testing, with the wider picture on Security Testing. If you are not sure which your situation calls for, describe it to us and we will tell you which one we would sell you, including when the answer is neither yet.