Many companies associate vulnerability scanning with the annual security audit: once a year the auditors arrive, run a scanner and hand over a report full of red cells, and the IT department spends a couple of weeks fixing things. After that, calm until next year.
The problem is that twelve months pass between two audits. In that time vendors publish thousands of new vulnerabilities, and attackers start using them within days, not months. An annual report shows the past, not the current state.
In this article we explain what a vulnerability and a CVE actually are, how scanning differs from a penetration test, how to set priorities so the IT team does not drown in the list, and why a monthly cycle is, for a NIS2 or DORA audit, not a luxury but the minimum.
What a vulnerability is and what CVE means
A vulnerability is a flaw in software or configuration that can be used to do something unwanted: get in without a password, run someone else’s code, read someone else’s data. It can be in an operating system, a browser, a server application, a network device or even a printer.
CVE (Common Vulnerabilities and Exposures) is a public registry of known vulnerabilities. Each one gets an identifier, for example CVE-2026-12345, a description and a severity score on the CVSS scale from 0 to 10. The score shows how much damage can be done and how easy it is to do.
The practical problem: a CVSS score knows nothing about your company. A ten on an isolated system that cannot be reached from the internet may be less urgent than a seven on a publicly reachable VPN appliance.
Another common mistake is to assume that vulnerabilities live only on servers. In our experience most critical findings are on network devices whose firmware has not been updated since they were bought, and on workstations with old versions of browsers or PDF readers.
Scanning and penetration testing are different tools
These two services are often confused, but they answer different questions.
Vulnerability scanning is automatic. The scanner checks every device on the network, compares the software versions and configurations it finds with the CVE registry, and produces a list: what, where, what severity. It is fast (hours), repeatable and relatively inexpensive, so it suits regular use.
A penetration test is manual work. A specialist behaves like an attacker: tries to chain several vulnerabilities into a real attack, move from one system to another and reach a specific goal. It takes days or weeks and answers the question “can someone break in”, not “which weaknesses exist”.
| Question | Scanning | Penetration test |
|---|---|---|
| Who does it | Software | A person |
| Frequency | Monthly or more often | Once a year or after major changes |
| Result | List of vulnerabilities with scores | Attack scenario and consequences |
| Answers the question | What needs to be updated | Whether the defences work as a whole |
One does not replace the other. A penetration test without regular scanning finds gaps the scanner would have shown six months earlier. Scanning without a test does not show whether several small gaps add up to a large one.
Why every month
Three reasons matter most in our experience.
First, the update cycle. Microsoft, browser vendors and most others release patches every month. A scan after each cycle shows what was installed and what was not. Without it you find out about a missing update only after an incident.
Second, the environment changes. Every month a new computer, a new server or a new application appears, and someone opens a port “temporarily”. An annual scan does not see these changes for eleven months.
Third, the time between disclosure and exploitation. When a critical vulnerability is published in a popular VPN or mail system, mass attempts to exploit it begin within days. If you learn about it from an annual report, it is already too late.
In some situations a month is too long: we scan publicly reachable servers and network devices weekly, and immediately after critical CVEs.
How to set priorities so the team does not drown
The first report for a typical company with 50 workstations has several hundred lines. Fixing everything at once is impossible and unnecessary. The priority logic:
- Reachability from the internet. Anything with a public IP address or an open port comes first, regardless of score.
- Known active exploitation. CVEs already used in real attacks come second, even if the CVSS score is medium.
- System importance. The domain controller, the accounting server and email before a test server.
- CVSS score is only the fourth criterion, when the first three are equal.
- Old vulnerabilities that repeat every month are a separate category: usually this is a system nobody updates anymore, and the solution is not a patch but replacement or isolation.
The result is a list of ten or twenty items that can be completed within a month, not three hundred that are frightening and therefore postponed.
The update window and what happens after the scan
Scanning without updates is only a report. For clients we set a fixed update window: for example, workstations on Tuesday night after Microsoft releases its patches, servers on Thursday night after testing. Employees know when their computer will restart, and accounting knows when the server will be unavailable for 20 minutes.
The cycle looks like this: scan, priority list, updates in the window, a repeat scan that confirms the gaps are closed. What cannot be fixed immediately stays in the report with a reason and a deadline.
If an update cannot be installed (for example, the vendor no longer supports the system or the patch broke during testing), we apply a compensating control: restrict access with a firewall, enable an additional EDR rule or move the system to an isolated network segment. This is recorded in the report as a decision, not as unfinished work.
Reports for NIS2 and DORA audits
Both regulations require a vulnerability management process, not a one-off check. The auditor will not ask “did you scan” but “how often, who reviews the results, how quickly do you remediate critical findings and where is this documented”.
A monthly cycle gives exactly that: twelve reports a year, each showing what was found, what was fixed and what remains with a justification. For financial-sector companies under DORA it is also important to show that critical systems are scanned more often and that third-party systems (for example, a cloud provider’s) are covered as well. We write separately about the NIS2 requirements and how to prepare for them.
How this is included in managed IT services
In our managed IT services, vulnerability scanning is not an extra line item. Every month we scan all managed workstations, servers and network devices, we build the priority list, we install updates in the agreed window, and the client’s management receives a one-page summary and a full report that can be attached to compliance documentation. Penetration testing and a broader assessment are done separately as an IT security audit.
Where to start
- Find the latest vulnerability report. If it is more than three months old, or there is none, that is already your answer.
- List everything reachable from the internet: VPN, email, website, remote desktop. Scanning starts there.
- Agree an update window with the business units so patches are not postponed “until it is convenient”.
- Decide who is responsible for reviewing the results every month, by name.
- If you do not have the internal resources, get in touch. We will include the monthly cycle in managed IT services with no extra charge and start with an initial scan.
