Two words, two very different activities

"We got pen tested" and "we ran a scan" are spoken as if they mean the same thing, and the confusion costs real money — teams pay for an expensive penetration test when a scanner would do, or check the "we scan" box and assume they're covered against a determined human. They sit at opposite ends of a spectrum: breadth and frequency on one side, depth and creativity on the other.

Vulnerability scanning: wide, automated, continuous

A vulnerability scanner is software that checks your systems against a database of known issues — missing patches, default credentials, outdated TLS, exposed services. Its strengths are exactly what automation is good at:

  • Broad coverage. It checks thousands of conditions across every host without tiring.
  • Cheap to repeat. Run it nightly or on every deploy; the marginal cost is near zero.
  • Consistent. It finds the same class of issue the same way every time, which makes trend tracking honest.

Its limit is that it only knows what it's been told to look for. A scanner finds known vulnerabilities; it won't chain three minor issues into a breach, and it won't reason about your business logic. The output is raw findings that still need triage — exactly the vulnerability management discipline that turns a CVE feed into a shrinking backlog.

Penetration testing: deep, human, point-in-time

A penetration test is a skilled human (or team) actively trying to compromise you, the way a real attacker would. They don't just enumerate known CVEs — they probe business logic, chain low-severity findings into a real exploit, and test the things a scanner can't reason about: "can I escalate from this read-only account to admin? Can I see another tenant's data?"

  • Finds what scanners can't. Logic flaws, broken access control, multi-step attack chains.
  • Produces a narrative. A good report tells you how an attacker would get in, not just that a port is open.
  • Expensive and periodic. It's human time, so it's a point-in-time engagement — typically annual, or before a major launch.

The catch is the inverse of the scanner's: a pen test is deep but it's a snapshot. The day after it ends, a new deploy can introduce a hole the test never saw.

How to combine them

They're complementary, not competing. A sensible program for a lean team:

  1. Scan continuously. Make automated scanning part of the deploy pipeline so regressions surface in hours, not at the next audit.
  2. Pen test periodically. Once a year, and before anything high-stakes ships, bring in a human to find what the scanner structurally can't.
  3. Feed both into one queue. A finding is a finding regardless of source — route scanner output and pen-test findings through the same discovery-to-closure workflow so nothing gets a special pass for being "from the pen test."

One honest note on compliance: SOC 2 and ISO 27001 generally expect both — evidence of ongoing scanning and a periodic independent test. Picking one to save money tends to surface as an audit gap, the kind that's far cheaper to close before the audit evidence gets sampled.

Scanning tells you what's broken that everyone already knows about. A pen test tells you what's broken that nobody has noticed yet. You need both answers.