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, and what the post-scan remediation lifecycle needs to look like to count as compliance evidence under frameworks like NIS2.

A cyber insurance renewal is six weeks out. Your insurer's security questionnaire asks whether you run regular vulnerability scans and track remediation to closure. Running scans is easy. Proving it is harder.

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 tests, how often to run it, and what you are supposed to do with the results under NIS2 are less clear.

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 one stage of a continuous vulnerability management lifecycle: 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. Without remediation tracking, scanning produces only a report.

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.

The scanner matches each finding against the National Vulnerability Database and attaches its CVE (Common Vulnerabilities and Exposures) identifier when one exists. It then enriches each finding with a CVSS (Common Vulnerability Scoring System) score, an EPSS (Exploit Prediction Scoring System) probability score estimating exploit likelihood within 30 days, and a KEV flag if the vulnerability appears on the CISA Known Exploited Vulnerabilities catalog.

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 every day, on top of any manual scans. New assets surface in the dashboard without anyone having to remember to look. Discovery itself combines both interaction models; see active vs passive vulnerability scanning for how each contributes.

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. It matches each finding against the NVD and any databases specific to that scanner.

Authenticated scans use credentials you supply to test application logic behind the login as well as 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.

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 by how likely exploitation is.

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 saves reformatting by hand.

Step 5: Remediation tracking and SLA enforcement

Most scanning programmes stop before this step. The platform assigns each finding 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. Without this trail, a scan report shows one point in time.

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.

Vulnerability lifecycle management · Tamper-evident audit evidence · EU data residency

What types of vulnerabilities does a scan cover?

What a scan covers depends on which scanners run. A tool built on one open-source scanner covers one surface. A multi-scanner platform covers network, web, API, code, container and cloud, with findings deduplicated in one 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 such as cross-site scripting, SQL injection, CSRF, insecure response headers, exposed directory listings, and information disclosure. A scanner running a rules-driven check set against the OWASP Top 10 covers considerably more than a basic crawler that only maps pages.

It does not test logic behind a login unless you supply auth headers or credentials. A scan without authentication sees only the external surface. For applications where most of the risk is behind the login, 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, such as Semgrep or CodeQL, to analyse a cloned copy of your repository without executing the code. Secret scanning tools, such as Gitleaks or GitGuardian, detect API keys, tokens and passwords committed to the working tree. Dependency scanning tools, such as Trivy or Grype, check your package manifest against known-vulnerable library versions and produce a software bill of materials as a secondary output.

For development teams using 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.

Working-tree secret scanning detects credentials in the current branch only. It does not scan Git history for secrets that were committed and later deleted. Historical secret detection requires a separate, dedicated tool.

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. 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 the findings open source scanners surface, but only when someone runs them consistently, on a schedule, across all assets.

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 scans run whether or not anyone remembers them.

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. The scanner may not have reached the assets it was supposed to test.

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 your environment right now. A penetration test asks whether a skilled attacker can 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.

For NIS2, run both. A documented scanning programme is the evidence Article 21's vulnerability-handling measure expects. An annual penetration test provides independent validation that cyber insurers and ISO 27001 auditors increasingly expect alongside scan evidence.

How often should you run vulnerability scans?

Quarterly at minimum, monthly for internet-facing assets, and after every major change. That baseline is market practice. Most frameworks set no fixed interval. NIS2 Directive Article 21 makes vulnerability handling a required measure but leaves scanning cadence to your risk assessment, and ISO 27001 takes the same risk-based line. DORA is the exception. Article 10(2) of its regulatory technical standard (RTS) 2024/1774 requires automated scanning at least weekly for assets supporting critical or important functions. The DORA compliance guide covers the full set of DORA testing duties.

The practice baseline comes from the people who check your evidence. ISO 27001:2022 auditors expect continuous or regular scanning as part of a vulnerability management process, and cyber insurers increasingly ask for proof of monthly scanning on internet-facing assets. What NIS2 specifically asks for, and the evidence an assessor expects behind the cadence you choose, is covered in the NIS2 compliance guide.

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.

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, Many buyers require EU hosting before any tool reaches formal evaluation.

EU-native vulnerability management tools do exist, Holm Security among them, but they sell through enterprise sales and custom quotes. For an SMB IT manager who needs to scan, track, and prove without sitting through a discovery call, the self-serve options above are the practical field.

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.

Scanning, tracking, and proving sit in one place. Vornin's scan coverage spans network, web, API, code, and cloud posture, every finding is auto-mapped to 9 compliance frameworks including DORA and NIS2 at ingestion with no manual tagging, and the data stays in the EU. SLA deadlines apply on every plan, with auto-escalation on Business and Scale.

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 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.

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 covers one surface and is a first step.

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 under NIS2, the scan starts the evidence chain. Auditors, insurers and boards want to see each finding detected, assigned, resolved and confirmed.

Read-only access · Working scan data deleted after each scan · EU data residency

Frequently asked questions