In short: A vulnerability scan checks systems automatically for known weaknesses: fast, inexpensive and a point-in-time snapshot. What it does not prove is whether a finding is actually exploitable. That takes a penetration test, and lasting coverage takes continuous exposure management.
→ Talk to us about vulnerability scanning and exposure management: free 30-minute scoping call.
“Vulnerability scan,” “vulnerability assessment,” “penetration test,” “vulnerability management”: these four terms get thrown around interchangeably. Sometimes out of ignorance, but often on purpose: some vendors sell a simple scan as an assessment, or a shallow analysis as a pentest. Knowing the differences protects you from exactly that mislabelling.
What a vulnerability scan is
A vulnerability scan uses specialised software to examine networks and systems for known weaknesses, comparing findings against vulnerability databases. We distinguish:
- External scans: IP addresses and open ports from the outside
- Internal scans: configuration errors and weak passwords from the inside
The scan is automated, fast and cheap and delivers a snapshot.
How a scanner actually works
Understanding the mechanism explains the limits at the same time. A scan runs in three phases:
1. Discovery. Which systems respond at all? The scanner determines reachable hosts and open ports.
2. Fingerprinting. What runs there? From response patterns, banners and protocol behaviour, the scanner infers product and version: for example “web server X, version 1.2.3”.
3. Matching. Known vulnerabilities for that version are looked up and reported as findings.
The decisive point sits in step three: in many cases the scanner infers vulnerability from version without actually triggering the flaw. That’s deliberate, a scan shouldn’t break anything. But it means a finding is a well-founded assumption, not proof.
Authenticated or not: the biggest difference in outcome
This is the most consequential setting of a scan, and it’s rarely discussed.
An unauthenticated scan sees a system the way a stranger sees it: from outside, without credentials. It finds exposed services and obvious weaknesses and no more.
An authenticated scan signs in with credentials and reads the actual state: installed software levels, missing patches, configuration settings, local policies. The result is typically several times larger and considerably more accurate, because it no longer rests on inference.
The practical consequence: if your provider only scans unauthenticated, you get a picture of the outside view, not of the state of your systems. Ask explicitly which mode is used.
What scanners systematically miss
No scanner in the world finds the following, because they lie outside what signature matching can do:
- Business logic flaws. If manipulating an order number surfaces someone else’s invoices, that’s a serious vulnerability and to the scanner a perfectly normal HTTP response.
- Chained vulnerabilities. Three individually harmless findings combine into a path to domain administrator. The scanner rates every finding in isolation.
- Custom software. No signatures exist for your own developments.
- Access control flaws. Whether a user can see data they shouldn’t is something a scanner cannot judge. It doesn’t know your permission model.
- Anything without a signature yet. A scan checks against the known. What was published yesterday becomes checkable tomorrow.
Also out of reach: misconfigurations in cloud services. An over-shared storage bucket or an unhardened Kubernetes cluster is technically flawless, just set up wrong. See S3 Bucket Security and Security in Azure Kubernetes Service.
On top of that come the two error types every operation has to live with: false positives, which cost time and eventually lead to reports going unread, and false negatives: gaps that were never reported and whose absence nobody notices.
Scan vs. assessment
A vulnerability assessment goes further: here security analysts review the scan results manually, place them in business context and judge their actual relevance. The scan provides the raw data, the assessment the interpretation.
In practice that means false positives get filtered out, findings get consolidated, and they are then judged by what they mean for your organisation, not by the severity the database happens to carry.
Scan vs. penetration test
The decisive difference: a penetration test includes an exploit phase. The tester actively attempts intrusion and proves whether a vulnerability is genuinely exploitable, not just whether it exists in theory. A scan says “there might be a problem here”; a pentest says “there is a problem here, and this is how far it gets me.”
What such a test costs and what drives the price is set out in How Much Does a Penetration Test Cost?.
That difference isn’t academic. It decides whether a conversation with the business starts with “the scanner is reporting something” or with “here is the record we extracted through it”. The second conversation goes differently.
Scan vs. vulnerability management
Vulnerability management, finally, is not a single event but a continuous loop: discover, assess, remediate, re-check. Only this makes trends visible and long-term improvement measurable.
The value lies in the repetition: a single scan says what today looks like. A series of scans says whether you are improving and whether findings actually disappear or merely get carried from report to report.
Prioritization: severity is not risk
A typical first report contains hundreds or thousands of findings. Working through them by CVSS score from the top down is working in the wrong order.
CVSS describes technical severity under laboratory conditions. For the question of what comes first, you need three more signals:
- Is it being exploited? The KEV catalog maintained by the US agency CISA lists vulnerabilities with evidence of active exploitation.
- Is it likely to be exploited? EPSS estimates the probability of exploitation within the next 30 days.
- How reachable is the system? The same flaw means something different at the perimeter than on an internal test system.
A thousand findings usually reduce to a few dozen that are genuinely urgent. That is exactly the move from a vulnerability list to a risk decision.
What fits which requirement
| Approach | Effort | Proves exploitability | Typical use |
|---|---|---|---|
| Single scan | low | no | quick snapshot |
| Cyclical assessment | medium | no | recurring evidentiary obligations |
| Vulnerability management | ongoing | no | lasting coverage, measurable progress |
| Penetration test | high | yes | before go-live, after major changes, for defensible statements |
- Single scan: a quick, cheap snapshot
- Cyclical assessment: satisfies compliance requirements like PCI DSS and ISO 27001
- Managed vulnerability management: comprehensive, continuous coverage
- Penetration test: periodic, especially around changes to networks or applications
What regulation actually requires
The relevant frameworks consistently require a process, rarely a specific tool:
- PCI DSS requires regular internal and external vulnerability scans, with external scans performed by an approved provider.
- ISO/IEC 27001:2022 addresses management of technical vulnerabilities in Annex A, the process, not the product.
- NIS2 requires, under Article 21(2)(e), security in acquisition, development and maintenance including vulnerability handling and disclosure, and under (f) procedures for assessing the effectiveness of the measures.
A scan report in a drawer satisfies none of these. What gets evidenced is a loop: discover, prioritise, remediate, demonstrate. Which NIS2 and DORA requirements map to which service is set out on our NIS2 & DORA page.
How often should you scan?
As a workable starting rule:
- Externally reachable systems: continuously or weekly. This is where the window between disclosure and attack is shortest.
- Internal systems: monthly, authenticated.
- After every significant change: new systems, changed exposure, migrations.
More important than frequency, though, is completeness of the estate: a weekly scan across 80 percent of your systems is worse than a monthly one across all of them. How quickly patching should follow findings is covered in Cloud Patch Management.
How Cloud Cape helps
We call things by their proper names and don’t sell a scan as a pentest. Above all, we treat vulnerabilities not as a list but as exposure: discover continuously, prioritise by real risk and validate with real attack techniques. That’s exactly what our Continuous Threat Exposure Management does and where proof of exploitability matters, our Pentesting & Red Teaming complements it.
Talk to us about Exposure Management. We turn scan results into prioritised risk decisions.