These two get quoted against each other as if they were competing versions of the same service. They are not. One is a tool run on a schedule; the other is a skilled person actively trying to break into your systems. They cost different amounts, take different lengths of time, and answer different questions.

Buyers are routinely sold the cheaper one under the more expensive name. Here is how to tell them apart and work out which you actually need.

What each one actually is

Vulnerability scanning

Automated software checks your systems against a database of known issues: unpatched software, default credentials, weak TLS configuration, exposed services, missing headers. It runs in minutes to hours, can run on a schedule, and produces a list of findings with severity ratings.

It is broad and shallow. It will check thousands of known conditions across your whole estate, and it will not find anything that is not already in its database.

Penetration testing

A person with security expertise attempts to compromise your systems the way an attacker would. They chain small issues into bigger ones, reason about your specific business logic, and pursue the paths a scanner cannot see.

It is narrow and deep. It takes days to weeks, cannot run on a schedule, and produces findings that describe a route to impact rather than a list of conditions.

The difference that matters

A scanner finds known vulnerabilities. A tester finds ways into your business.

Consider a system where any logged-in user can change the account number in a URL and view another customer’s invoices. No software is out of date. No configuration is wrong. Every scanner on the market will report the application as clean, because nothing in its database describes your authorisation model.

That class of flaw — broken access control, business-logic abuse, privilege escalation through a legitimate feature — is consistently among the most damaging in real breaches, and it is almost entirely invisible to automated scanning. It requires someone who understands what your application is supposed to do, and then deliberately does something else.

Conversely, a penetration test is a poor way to discover that one server missed a patch three weeks ago. A scanner does that continuously, for a fraction of the cost.

How to tell what you are being sold

Some suppliers run a scanner, reformat the output, and deliver it as a penetration test. The report is the giveaway.

Signs you received a scan:

• Findings are phrased as conditions (“TLS 1.0 enabled”, “X-Frame-Options missing”) rather than as routes to impact.
• Severity ratings are raw CVSS scores with no reference to your business context.
• Every finding has generic remediation text that could apply to any organisation.
• There are no reproduction steps a developer could follow.
• The whole engagement took less than a day.
• Nothing in the report demonstrates the tester understood what your application does.

Signs you received a real test:

• At least some findings describe a chain: this misconfiguration plus that weak check allows an ordinary user to reach administrative data.
• Reproduction steps are specific enough for your developers to follow and confirm.
• Severity is argued in terms of business impact, not just a score.
• The report contains findings a scanner could not produce — logic flaws, authorisation gaps, chained issues.
• There is a section on what was tested and, importantly, what was not.

That last item is the strongest quality signal. An honest report states its own limits: the scope, the time available, and the areas that were not reached. A report claiming complete coverage is a report to be suspicious of.

Which one do you need?

The question is not either/or. Mature security programmes run both, at different frequencies, for different reasons.

You need scanning if

You have more than a handful of servers or endpoints, you deploy regularly, or you have any obligation to demonstrate ongoing diligence. Scanning is your continuous hygiene check — it should run automatically and repeatedly, ideally in your deployment pipeline as well as against production.

This is not optional for most organisations. It is cheap and it catches the large volume of dull, known problems that accumulate through ordinary operation.

You need penetration testing if

Any of the following apply: you handle money, personal data or health information; a compromise would be materially damaging; you have custom application logic where authorisation decisions are made; a customer or regulator requires it; or you have just built or substantially changed something important.

The trigger worth internalising is custom logic. Off-the-shelf software is tested by its vendor and by everyone else who runs it. The code you had written for your own business has been examined by nobody except the people who wrote it.

Sensible cadence

For most mid-sized organisations: scanning continuously and automatically; penetration testing annually, plus after any significant architectural change or major feature affecting authentication, authorisation or payments.

Testing more often than that has diminishing returns unless you are shipping large changes constantly. Testing less often means a year of unexamined change.

Getting value from a test

Four things separate an engagement that improves your security from one that produces a PDF for a compliance folder.

Scope honestly. Excluding your most sensitive system because a test feels risky guarantees the one thing an attacker will target is the one thing nobody checked. If a system cannot be tested in production, test a faithful copy.

Give the testers information. There is a persistent belief that a black-box test is more realistic. In practice, a real attacker has unlimited time and you are buying days. Give the testers credentials, documentation and architecture diagrams, and they will spend those days finding flaws rather than rediscovering your URL structure. You will get substantially more per pound spent.

Budget for the fix, not just the finding. The most common failure is an organisation spending its entire security budget on the test, leaving nothing to remediate what it found. A report of unfixed findings is worse than no report, because you now have documented knowledge of a problem you did not address.

Agree a retest. The engagement should include verification that the fixes actually worked. Remediation that was never confirmed is remediation you are guessing about.

A note on compliance-driven testing

If you are testing because a customer or standard requires it, resist the temptation to buy the cheapest thing that produces a certificate. You are paying either way; the difference between a box-ticking scan and a genuine test is largely whether you learn anything.

The organisations that get value are those that treat the requirement as a prompt to actually find out where they stand.

How we approach it

Our cyber security engagements state up front which of these you are buying, scope what will and will not be covered, and deliver findings with reproduction steps your developers can follow. Where the root cause sits in application code, our software engineering team can carry out the remediation, and where the underlying issue is governance rather than a single bug, our information security practice addresses it properly.

Talk to us about what you need tested, and we will tell you honestly whether a scan would serve you better.