Vulnerability scanning is a regular, automated check of servers, network devices, web applications and IoT devices for known vulnerabilities (CVE entries), missing patches and misconfigurations. Penetration testing is a periodic, manual exercise in which a specialist tries to exploit weaknesses to prove real impact. Scanning keeps the list short; testing shows how deep the holes go.
Key takeaways
- Vulnerability scanning finds known flaws and missing patches automatically, across every asset, on a regular schedule.
- Penetration testing is a less frequent, deeper exercise in which a specialist manually exploits flaws to prove real impact.
- According to Verizon's 2026 DBIR, vulnerability exploitation became the most common initial access vector in breaches, at 31%.
- Rank findings by CISA KEV status, internet exposure and system criticality as well as CVSS score, not CVSS alone.
- A finding is closed when it disappears from a rescan, not when someone says it has been patched.
Vulnerability scanning vs penetration testing: what is the difference?
Vulnerability scanning and penetration testing are often bought as if they were interchangeable, usually because a supplier questionnaire asks for "evidence of security testing". It helps to think of them as answers to different questions. A vulnerability scan asks: which known weaknesses exist across everything we own, right now? A penetration test asks: if a capable attacker went after us, what could they actually reach? The first is about breadth and frequency; the second is about depth and proof.
| Vulnerability scanning | Penetration testing | |
|---|---|---|
| Question it answers | What known weaknesses exist today? | What could an attacker actually achieve? |
| How it works | Automated tools, configured and reviewed by people | A specialist working manually, chaining findings |
| Coverage | Broad: every asset in scope | Deep: a defined target within a time box |
| Frequency | Continuous, weekly or monthly | Annually and after major changes |
| Typical output | Prioritised list of CVEs and misconfigurations | Proven attack paths with evidence and business impact |
| What it misses | Business-logic flaws, chained attacks | Anything outside scope or newer than the test |
| Best trigger | A schedule, plus every new system | A launch, an audit or a customer requirement |
Neither replaces the other. A pen test on an estate that has never been scanned mostly rediscovers missing patches; a scanning programme without an occasional pen test never learns about the access-control flaw no tool can see.
Vulnerability scanning is also a pulse check rather than a photograph. New vulnerabilities are published every month, servers change, a port opened temporarily for a supplier is forgotten, and a camera joins the network with factory settings. A one-off scan shows the state of things on the day of the report and is out of date a week later.
This guide covers scan types, how to rank findings and how a small team can run a sustainable scanning programme. For the testing side in detail, see our penetration testing guide.
What does leaving known vulnerabilities open cost?
As of 2026, exploiting known vulnerabilities is the attacker's most common way in. Phishing and stolen passwords remain serious threats, but exploitation of known flaws has moved ahead of them.
According to Verizon's 2026 report, exploitation of vulnerabilities became the most common initial access vector in breaches at 31%, while credential abuse, the previous leader, fell to 13%. (Verizon 2026 Data Breach Investigations Report)
The real problem in vulnerability management is not finding vulnerabilities but closing them. The same Verizon 2026 DBIR found that only 26% of critical vulnerabilities in CISA's Known Exploited Vulnerabilities (KEV) catalog were fully remediated in 2025 (down from 38%), and the median time to full remediation grew from 32 to 43 days. Attackers work faster than that: the ENISA Threat Landscape 2025 reports that vulnerability exploitation accounted for 21.3% of initial access in the incidents it analysed, with flaws weaponised in widespread campaigns within days of disclosure.
As of 24 September 2026, the US cyber security agency CISA's KEV catalog lists 1,723 vulnerabilities, and it grows almost every week. If one of them sits unnoticed on an internet-facing server and the result is ransomware, recovery depends on the state of your backups, which is why we treat ransomware-proof backups as part of the same conversation.
What types of vulnerability scan are there, and what does each one see?
There is no single "vulnerability scan". What a scanner finds depends on where it looks from and how much access it has:
| Scan type | Where it looks from | What it catches well | What it misses |
|---|---|---|---|
| External scan | The internet, as an attacker would | Open ports, exposed admin panels, outdated public-facing versions | Internal devices, missing patches inside servers |
| Internal scan | Inside the office or factory network | Forgotten servers, cameras, printers, network devices | Risks visible only from outside |
| Authenticated scan | Logged in with an authorised account | Missing operating system and software patches, weak configurations | Business-logic flaws |
| Web application scan | Crawling the application like a browser | Injection, cross-site scripting (XSS), missing security headers | Logic flaws such as one customer seeing another's orders |
| Cloud configuration check | The cloud account's management interface | Publicly exposed storage, overly broad permissions | Software flaws inside virtual servers |
In practice, the biggest quality gain comes from authenticated scanning. An unauthenticated scan looks at what a server reveals and often guesses; a scan with a read-only account reads installed packages and patch levels directly. That means fewer false positives and fewer missed patches.
Vulnerability scanning on factory networks needs extra care. PLCs (programmable logic controllers), HMIs (operator panels) and SCADA systems can react badly to aggressive network scanning, so on those segments we use passive discovery or low-intensity scans in a maintenance window. Our article on OT security for SCADA networks explains the approach.
How should vulnerability scan findings be prioritised?
The most common mistake with a scan report is sorting it purely by CVSS score. The Common Vulnerability Scoring System measures technical severity, but it does not tell you whether a flaw is being exploited today or whether the affected system is reachable from the internet. Teams end up patching an unreachable internal server while a known exploit on the VPN appliance waits.
The US Cybersecurity and Infrastructure Security Agency (CISA) has shifted in the same direction: its BOD 26-04 directive, issued on 10 June 2026, replaced fixed remediation deadlines with prioritisation based on an asset's exposure and exploitation risk. For a smaller organisation the logic is the same. Ask four questions of every finding:
| Question | If yes | Where the answer comes from |
|---|---|---|
| Is the flaw in the KEV catalog, i.e. actively exploited? | Top priority | CISA KEV catalog |
| Is the affected system reachable from the internet? | Raise priority one level | External scan, firewall rules |
| Does the system hold personal data, financial data or run production? | Raise priority one level | Asset inventory |
| Is the CVSS score high or critical? | Schedule into the planned patch cycle | Scanning tool |
Applying the four-question prioritisation table requires an up-to-date asset inventory; you cannot rate a server's importance without knowing what it does. That is why the inventory sits near the top of our SME cyber security checklist.
How do you build a vulnerability scanning programme? 8 steps
- Build the asset inventory. Public IP addresses, domains, servers, network devices, cameras and cloud accounts go on one list, each with a named owner.
- Agree scope and permission in writing. Record which ranges are scanned, when, and what is excluded, including your hosting provider's rules.
- Set up authenticated scanning. Create a dedicated read-only account for the scanner and protect its credentials like any other admin account.
- Treat the first scan as a baseline. The first report will be long. The goal is to record where you stand, not to fix everything in a week.
- Weed out false positives. Mark findings based on version guesses or covered by a compensating control, and note why.
- Prioritise, then assign an owner and a date. Every finding, ranked by KEV status, internet exposure, system criticality and CVSS score, gets a person and a closing date. Where a patch cannot be applied, write down the interim measure, such as restricting access or disabling the service. Testing and rolling out patches is its own discipline, covered in our patch management process guide.
- Verify fixes by rescanning. "Patched" is a claim; a finding is closed when it disappears from the next scan.
- Fix the cadence and the triggers. Scan external assets frequently and internal networks regularly, plus whenever a new server, release or major change goes live. Report open findings and average time to close to management.
Vulnerability scan results show where the doors are open; combined with SIEM and log management, they also tell you whether anyone has walked through one. Weak or reused passwords rarely show up in a scan, so treat business password security as a separate control.
Why does vulnerability scanning matter for KVKK, ISO 27001 and NIS2?
In Türkiye, the Personal Data Protection Law (KVKK, Law No. 6698) is the local counterpart to the GDPR, and it requires data controllers to take technical measures that ensure an appropriate level of security. Regular scan reports and closure records are among the concrete evidence that those measures exist; we define that evidence together in our data protection compliance work. Organisations preparing for ISO 27001 certification will also find technical vulnerability management among the controls auditors ask to see evidence for.
For companies selling into Europe, the EU's NIS2 Directive requires in-scope organisations to handle vulnerabilities and manage supply chain security, and they pass that question on to suppliers (see NIS2 requirements for suppliers). A scanning schedule with closure records answers it with evidence rather than assurances.
How does Digital Bridge run vulnerability scanning?
Within its cyber security consultancy, Digital Bridge treats vulnerability scanning as a process that runs until findings are closed, not as a report delivered once:
- Discovery and scope. We map your internet-facing assets and internal segments, then agree scope and scan windows in writing; on factory networks, together with the production team.
- Pilot scan. We start with a handful of critical systems, set up authenticated scanning and clean the first report of false positives. Findings are ranked by CVSS, KEV status and exposure, each with a practical remediation step.
- Remediation and integration. We plan patches and configuration changes with your team and confirm closure by rescanning. If systems are moving to the cloud, configuration checks become part of our cloud migration and infrastructure work.
- Your own software. If you run a customer portal or other custom web software, we add a web application scan to the pre-release checklist. For software bought from contractors, our guide to supervising software contractors covers which security outputs to ask for.
- Going deeper where it matters. Where scans point to a risky area, we confirm with a penetration test whether the weakness can really be exploited.
Networked cameras and access control devices are a frequent blind spot in vulnerability scanning scope; our article on central IP camera management explains how to keep them inventoried and updated.
Next step
The first step towards a vulnerability scanning programme is one you can take this week: list your public IP addresses and domains and name an owner for each. Then get in touch with us; we will agree the scope together and deliver your first prioritised report from a pilot scan. For more guides on security and compliance, visit our Cyber Security & Compliance hub.