What is vulnerability management?
A vulnerability scan produces a list of findings. Vulnerability management turns each finding into a decision: fix it, protect it another way or knowingly accept the risk, each with an owner and a date. A finding is done only when a fresh check shows the vulnerability is gone. A closed ticket only shows that someone acted.
A scanner checks only what it is configured to check. Reconcile the scan scope with the asset inventory before you report results; a system that is in the inventory but in no scan is a finding in its own right. In an ISMS, the process belongs to the operation of the technical controls.
How does the process work?
| Step | What happens |
|---|---|
| Scope | Define coverage: servers, clients, network devices, cloud services, containers, third-party libraries |
| Detect | Authenticated and unauthenticated scans, vendor and CERT advisories, test results, external reports |
| Assess | Judge technical severity and relevance in your own environment separately |
| Treat | Patch, configuration change, compensating control or time-limited risk acceptance |
| Verify | Scan or test again and file the result with its date |
| Report | Open findings, missed deadlines and long-standing findings to management |
Why is the CVSS score not the priority?
The Common Vulnerability Scoring System (CVSS) rates the technical severity of a vulnerability from its properties. How urgent it is in your environment also depends on whether the system is reachable from the internet, whether exploitation is known, how sensitive the information is and which controls already work.
Neither ISO/IEC 27002 nor the BSI Act sets fixed thresholds or deadlines. The organisation sets them and justifies them. For financial entities, Article 10(2) of Delegated Regulation (EU) 2024/1774 requires patch prioritisation to take account of the criticality of the vulnerability and the classification and risk profile of the affected ICT assets.
Fictional example: three findings, one order
The figures and deadlines in this example are invented for illustration; the deadlines come from an assumed internal policy.
| Finding | CVSS base score | System | Reachable from the internet | Exploitation known | Decision |
|---|---|---|---|---|---|
| A | 9.8 | Test server in an isolated network | no | no | Fix in the next maintenance window, within 30 days at the latest |
| B | 7.5 | Customer portal | yes | yes | Fix within 72 hours, switch off the affected function until then |
| C | 6.5 | Payroll with personal data | no | no | Fix within 14 days |
The rule behind it: reachability and known exploitation set the deadline, protection needs shorten it, and the CVSS score breaks ties. After each fix, scan the system again and file both scan results with their dates and the change ticket as evidence. If B cannot be fixed in time, the risk owner decides on a risk acceptance with an expiry date.
What do the BSI Act, the NIS2 implementing regulation and DORA require?
§ 30(2), second sentence, no. 5 BSIG requires security in the acquisition, development and maintenance of IT systems, including vulnerability management and disclosure; it names no scan frequency. As a rule, § 30 does not apply to the telecommunications and energy companies in § 28(5) BSIG, and it does not apply to financial entities under DORA (§ 28(6) no. 1 BSIG).
For cloud providers, data centres, managed service providers and the other entity types in § 30(3) BSIG, point 6.10 of the Annex to Implementing Regulation (EU) 2024/2690 is the operative text. They run vulnerability scans where appropriate and record the results at planned intervals. Vulnerabilities they classify as critical to their operations are fixed without undue delay. Where a vulnerability needs no remediation, they document and justify that (point 6.10.3).
Under Article 10(2) of Delegated Regulation (EU) 2024/1774, financial entities run automated scans of ICT assets supporting critical or important functions at least weekly. They set patch deadlines themselves and define escalation when deadlines are missed (Article 10(4)(d)). Under the simplified framework, Article 34(d) ties the frequency to the asset's classification and risk profile. In ISO/IEC 27002, control 8.8 covers the management of technical vulnerabilities.
How does it differ from patch management and penetration testing?
Vulnerability management decides what is treated and how urgently. Patch management is one route by which the fix reaches production. A penetration test checks at one point in time and within a defined scope whether detection and remediation hold up, and finds weaknesses an automated scan misses. If a vulnerability is already being exploited, it is a case for incident response.
Unremediated vulnerabilities as risks in Rizzqo
A vulnerability that is not fixed straight away can be recorded in Rizzqo as a risk assessment: likelihood as a percentage and impact in euros, rated through a configurable risk matrix. The fix runs as a task with a planned reduction and can be synced both ways with Jira, where IT keeps its tickets. While the task is planned, its reduction is reserved and lowers only the residual risk; on completion it is applied to the current risk. The vulnerability itself is recorded against the affected asset in Rizzqo.