Vulnerability assessment vs penetration testing.

A vulnerability assessment asks: what on these systems matches a known pattern of weakness? It compares software versions, configurations and responses against a database of known issues and reports what it finds, at scale, without attempting to cause harm.

A penetration test asks: what could a skilled attacker actually achieve here? A human tester chains weaknesses, abuses intended functionality, works round partial defences and demonstrates real impact — that this API returns other customers' records, or that this upload path leads to code execution.

The first is measurement. The second is adversarial reasoning. Selling either as the other is the most common misrepresentation in the security market, and it works because both deliver a document full of severity ratings.

Cost, cadence, depth and evidence value all diverge, which is why mature programmes buy both rather than choosing.

A scanner recognises patterns. It can tell that a web server advertises a version with a published vulnerability, that TLS is misconfigured, that a database port is reachable, that a known-vulnerable library is loaded. This is genuinely valuable and covers a large share of real-world compromise.

What it cannot do is understand what your application is supposed to allow. If changing an account identifier in a request returns another customer's invoice, every individual request is technically valid and returns a normal response code. No signature matches, because nothing is broken in the software — the authorisation logic is wrong, and only something that understands intent can notice.

The same limitation applies to multi-step abuse: a password reset that leaks whether an address is registered, a discount flow that can be replayed, a permission that is correctly enforced in the interface and not in the API behind it. These are the findings that produce breach headlines, and they are exactly what automation is worst at.

Scanner output requires human validation before it is actionable, and teams consistently underestimate this. Findings arrive flagged on version strings that a backported patch already fixed, on services that are unreachable in practice, or with generic severity scores that ignore your architecture entirely.

That last point matters most. A tool's severity rating describes the vulnerability in the abstract; it knows nothing about whether the affected host holds customer data or sits behind three layers of network control. Prioritising strictly by scanner severity reliably produces effort spent on the wrong things.

The practical answer is to treat scanner output as a queue of hypotheses, not a to-do list — and to accept that someone with context has to triage it. Platforms that pre-validate findings are selling exactly that labour.

Read the requirement rather than the summary. Frameworks differ, and their wording is deliberate: some require regular vulnerability scanning at a stated interval, some require penetration testing after significant change, and several require both in different clauses.

The pattern that satisfies most regimes is unglamorous: continuous or scheduled scanning across the estate, an annual scoped penetration test of the systems that matter, documented risk decisions for anything not fixed, and evidence that remediation was verified rather than asserted.

Where organisations fail audits, it is rarely for lack of a scanner. It is for the missing middle: no record of who assessed each finding, no rationale for accepted risk, no proof that closed tickets closed the underlying weakness.

Run assessment continuously — it is cheap, broad and catches the newly published vulnerability on your exposed service before someone else does. Treat its output as a maintenance stream with an owner and a service-level expectation for high-severity items.

Buy penetration testing where consequence concentrates: authentication, payment, anything handling personal data, anything bespoke. Once a year is a reasonable default, plus after any significant architectural change.

Then close the loop that most programmes leave open. Verify fixes explicitly, record risk acceptances with review dates, and keep both trails in one place. That evidence is what turns two technical activities into something a customer, insurer or auditor will accept.