What is a vulnerability scan? A practical guide for European IT managers

TL;DR: A vulnerability scan is an automated check of servers, web applications, APIs, DNS configurations, and code repositories for known security weaknesses. This guide covers what a scan tests, how often to run one under NIS2 Article 21, and what the post-scan remediation lifecycle needs to look like to count as compliance evidence.

Your cyber insurance renewal is in six weeks. The underwriter's questionnaire asks whether you run regular vulnerability scans and track remediation to closure. You know you run scans. You are not sure you can prove it.

That gap between scanning and proving you scan is where most IT managers at growing European companies find themselves. The term "vulnerability scan" is familiar. What it actually tests, how often to run it, and what you are supposed to do with the results under NIS2 are less clear.

By the end of this guide, you will have a complete picture of how vulnerability scanning works, which attack surfaces it covers, how to set a defensible scanning frequency under NIS2 Article 21, and what the post-scan lifecycle needs to look like for scan results to count as compliance evidence.

What is a vulnerability scan?

A vulnerability scan (also called an automated vulnerability assessment) is a security check of your IT environment for known weaknesses. It probes servers, web applications, APIs, DNS configurations, and code repositories against a database of known vulnerabilities and misconfigurations. The output is a prioritised findings list, each weakness assigned a severity score so your team knows what to fix first.

A vulnerability scan is not a one-time event. It is a repeating process: discover assets, scan, score findings, report, remediate, then rescan to confirm each fix is real. Each cycle closes the loop on findings from the previous one. Scanning without tracking remediation gives you a report, not a programme.

What does a vulnerability scan look for?

A scan checks for weaknesses an attacker could exploit without needing special access. This includes open ports exposing admin interfaces, SSL certificates using deprecated protocols, web application flaws such as XSS and SQL injection, DNS misconfigurations enabling domain spoofing, and credentials or vulnerable libraries committed to code repositories.

Each finding is matched against the National Vulnerability Database, where a CVE identifier is assigned when one exists. The scanner then enriches each finding with a CVSS score, an EPSS probability score (a model estimate of exploit likelihood within 30 days), and a KEV flag if the vulnerability appears on the CISA Known Exploited Vulnerabilities catalog.

Understanding how that five-step process runs end-to-end shows what a scan actually delivers.

How does vulnerability scanning work?

Vulnerability scanning follows five steps in sequence: asset discovery, scanning and CVE matching, severity scoring, reporting, and remediation tracking. Most tools stop at reporting. The step they skip is the one that produces compliance evidence.

Step 1: Asset discovery

Before scanning anything, the platform maps every host, subdomain, and endpoint associated with a target. This includes subdomains the team stopped managing, IP ranges with exposed services, and external-facing APIs that were never formally registered as assets.

A continuous attack surface monitor runs this step daily, not only when a manual scan is triggered. New assets surface in the dashboard without anyone having to remember to look.

Step 2: Scanning and CVE matching

The scanner probes each discovered asset for known weaknesses. It checks open ports, reads certificate data, sends test payloads into web forms, inspects API endpoints, and queries DNS records. Each finding is matched against the NVD and any scanner-specific databases relevant to the engine running the check.

Authenticated scans use credentials you supply to test internal application logic, not only the external surface. Unauthenticated scans run faster but cover less.

Step 3: CVSS severity scoring

Every finding receives a CVSS score between 0 and 10. Critical scores sit at 9.0 and above; High runs from 7.0 to 8.9; Medium covers 4.0 to 6.9; Low covers anything below 4.0. The score reflects both how easy the vulnerability is to exploit and what the impact of exploitation would be.

CVSS is a starting point, not a final answer. A Critical-rated CVE with a 0.3% EPSS score is generally less urgent in practice than a High-rated CVE with a 68% EPSS score. EPSS enrichment alongside CVSS helps you prioritise based on real-world exploitation probability, not theoretical severity alone.

Step 4: Reporting

Scan output is a findings report sorted by severity. A useful report shows the finding, the affected asset, the CVE reference, CVSS and EPSS scores, the compliance controls the finding maps to, and the recommended remediation action.

For teams reporting to leadership, a raw findings list is not the right format for a board slide. A dual-audience report that produces both a technical findings list and an executive summary from the same scan removes the manual reformatting most IT managers currently handle themselves.

Step 5: Remediation tracking and SLA enforcement

This is where most automated vulnerability scanning programmes break down. A finding is assigned to a team member with a deadline. The scanner reruns on the same target. If the finding is gone, it auto-closes with a confirmed-resolved status and a timestamp. If the deadline passes with the finding still open, an escalation fires automatically.

That timestamp is the compliance evidence. It shows an auditor that the finding was detected, assigned, remediated, and confirmed resolved, with dates attached to each stage. A scan report without this lifecycle trail is a point-in-time snapshot. With it, it is a documented programme.

Across the audits we have supported, the question is never "did you scan." It is "can you show this finding moved from open to resolved, and on what date." Scans without that lifecycle leave the question unanswered.

Which attack surfaces appear in that findings list depends on the scanner engines behind the platform.

What types of vulnerabilities does a scan cover?

The attack surfaces a vulnerability scan covers depend entirely on how many scanner engines are running. A tool built around a single open-source engine covers one surface. A platform with 13 dedicated engines covers all of them simultaneously, with findings merged into a single deduplicated dashboard.

Network and infrastructure

A port scanner maps every open TCP and UDP port across your hosts. It flags exposed admin interfaces, unnecessary services, and firewall gaps that should not be publicly reachable. An SSL/TLS scanner checks every certificate for expiry dates, weak cipher suites, and deprecated protocols including SSLv3, TLS 1.0, and TLS 1.1.

DNS scanning verifies SPF, DKIM, and DMARC records so your domain cannot be used to send spoofed email on your behalf. Subdomain enumeration surfaces assets your team may have forgotten. Subdomain takeover detection checks whether any of those subdomains point at de-provisioned services, a common source of credential theft attacks.

What does a website vulnerability scan test?

A web vulnerability scan sends test payloads into your application to detect common flaws: cross-site scripting, SQL injection, CSRF, insecure response headers, exposed directory listings, and information disclosure. A scanner running 167 distinct path probes and checking 12 JavaScript library CVE patterns covers considerably more of the OWASP Top 10 than a basic crawler.

What it does not cover: authenticated internal logic requiring a valid user session, unless you supply auth headers or credentials. A scan without authentication is external-only. For applications where the real risk sits behind the login wall, you need a credentialed scan.

An API security scanner runs in parallel, checking for CORS misconfigurations, authentication bypass, verbose error messages, and auto-discovered API documentation endpoints (Swagger, OpenAPI, ReDoc) that were never meant to be public.

Code repository vulnerability scanning: SAST, secrets, and dependencies

Code repository scanning covers three separate risks: static analysis of application code (SAST), secret scanning for exposed credentials, and dependency scanning for known-vulnerable packages. Each requires a different engine.

SAST uses a rules engine (Semgrep is standard) to analyse a cloned copy of your repository without executing the code. Secret scanning (Gitleaks) detects API keys, tokens, and passwords committed to the working tree. Dependency scanning (Trivy) checks your package manifest against known-vulnerable library versions and produces a software bill of materials as a secondary output.

For Azure DevOps and GitHub connections, the scanner connects via personal access token, clones the repository temporarily, runs all three passes, and deletes the source code after the scan completes. Findings enter the same deduplication and compliance-mapping pipeline as all other scan results.

One limitation to be clear about: working-tree secret scanning detects credentials present in the current branch. It does not scan Git history for secrets that were committed and later deleted. Historical secret detection requires a separate, dedicated tool.

Open source tools cover some of these surfaces. Understanding where they stop explains why most IT teams eventually move to a managed platform.

Open source vulnerability scanners: what they cover and where they stop

Open source vulnerability scanning tools, OpenVAS, Nmap, and OWASP ZAP, are where most IT teams begin before outgrowing the manual approach. Each tool is capable within its scope. The problem is that each covers one surface, produces its own output format, and requires someone to install, maintain, update, and run it on a schedule they manage manually.

OpenVAS covers network and host vulnerabilities. Nmap maps open ports. ZAP tests web applications. Running all three means managing three separate tools, reconciling three different output formats, and manually deduplicating findings that overlap across engines. The operational burden grows with every new target you add.

The ENISA Threat Landscape 2024 identifies misconfiguration and unpatched software as leading causes of successful attacks on European organisations. Those are precisely the findings open source scanners surface, but only when someone runs them consistently, on a schedule, across all assets.

Consistency is the gap. A managed vulnerability scanning service runs on the schedule you set once. It covers all attack surfaces from a single interface. Findings are deduplicated automatically, and the remediation lifecycle is built in. The difference is not between bad security and good security. It is between a process that depends on someone remembering and a process that runs whether anyone remembers or not.

Open source tools remain useful for one-off assessments or environments where a managed SaaS tool is not viable. For an IT manager who needs a documented, repeatable programme that satisfies an auditor, the operational overhead of the manual stack is the bottleneck. And a clean report from one of these tools may not mean your environment is clean, it may mean the scanner could not reach the assets it was supposed to test.

The comparison with a penetration test is the question most IT managers raise before committing to a scanning approach.

Vulnerability scan vs penetration test: when each is the right tool

A vulnerability scan and a penetration test answer different questions. A vulnerability scan asks: which known weaknesses exist across my environment right now? A penetration test asks: can a skilled attacker chain those weaknesses into a meaningful compromise?

Penetration tests do not replace vulnerability scanning. A pentest reflects your security posture on the day it runs. New vulnerabilities are disclosed every week. Between annual tests, your environment changes: new services go live, dependencies update, subdomains appear. A continuous vulnerability scan catches what a pentest cannot see between engagements.

The practical answer for NIS2 compliance is both. A documented scanning programme satisfies the "regular scanning" requirement under Article 21. An annual penetration test provides independent validation that cyber insurers and ISO 27001 auditors increasingly expect alongside scan evidence.

Frequency is the practical question that follows once tools are selected.

How often should you run vulnerability scans for NIS2 compliance?

NIS2 Directive Article 21 requires organisations in scope to implement "regular" vulnerability scanning as part of their technical risk-management measures. The Directive does not specify a scanning interval. Cadence is left to the organisation based on its risk profile.

In practice, security frameworks and regulatory guidance converge on a clear baseline: quarterly is the minimum, and monthly is standard for organisations with active compliance obligations. ISO 27001:2022 expects continuous or regular scanning as part of a vulnerability management process. Cyber insurers increasingly ask for evidence of monthly scanning, particularly for organisations with internet-facing assets.

For IT managers at European SMBs running hybrid infrastructure, the practical cadence is:

• Monthly for all internet-facing assets (web applications, APIs, public subdomains)
• Quarterly at minimum for internal network and infrastructure targets
• On change after every major deployment, firewall rule change, or new asset added to the environment

Continuous subdomain monitoring runs daily regardless of your scheduled scan frequency, so new attack surface is detected without a manual trigger.

Frequency matters less than documentation. NIS2 enforcement bodies and ISO auditors want to see that scans ran, when they ran, what they found, and what happened to each finding. A quarterly scan with complete remediation evidence is more defensible than a monthly scan with no tracking.

Tool selection follows once the cadence is set.

What is the best vulnerability scanning tool?

Selecting vulnerability scanning software comes down to three criteria: coverage across your full attack surface, a built-in remediation lifecycle after the scan, and where your scan data is hosted. For IT and security teams at European organisations, EU hosting is not a preference. Most CTOs enforce it as a procurement requirement before any tool reaches formal evaluation.

The three criteria in the table above are the ones IT managers most often name as rejection reasons during tool evaluation. A tool missing any of them is typically removed from the shortlist before a formal trial begins.

Vornin's 15 built-in scanner engines cover the full attack surface without wrapping third-party tools. Every finding is auto-mapped to 9 compliance frameworks including DORA and NIS2 at ingestion, with no manual tagging required. SLA enforcement with auto-escalation is absent from both HostedScan and Intruder, making Vornin the only option in this tier with a complete remediation close loop.

Is there a free vulnerability scanner?

OpenVAS, Nmap, and OWASP ZAP are free and widely used. Each is capable within its scope. The cost is not a license fee. It is operational time.

Configuring OpenVAS for a production environment takes hours. Keeping the vulnerability feed current, managing scan credentials, and interpreting raw output require ongoing attention. Nmap returns port data that needs manual analysis. ZAP requires configuration to avoid flooding application logs with false-positive test traffic.

The total operational cost of the free stack, measured in engineering hours, typically exceeds the cost of a managed subscription for any team running more than a handful of targets. The comparison is not free versus paid. It is the cost of your time versus the cost of a subscription.

For teams that want a starting point without a subscription commitment, running Nmap for port mapping and cross-referencing findings against the CISA KEV catalog is a defensible baseline. It is not a compliance programme. It is a first step, and it covers one surface.

Conclusion

A vulnerability scan tells you what is broken. The process after the scan, tracking every finding, enforcing remediation deadlines, and confirming each fix with a rescan and a timestamp, is what turns a scan into a documented security programme.

For IT managers running infrastructure under NIS2, the scan is the beginning of the evidence chain, not the end of it. What your auditor, your insurer, and your board need to see is the lifecycle: detected, assigned, resolved, confirmed.

Frequently Asked Questions