How do you govern vulnerabilities as a CISO?

Vulnerability management is the continuous process by which your organisation discovers, assesses, remediates and accounts for weaknesses in its systems. As a CISO you are not the one who fixes the vulnerabilities themselves, but the one who ensures the process works, that the right things are tackled first and that the residual risk sits with the right person. This article explains how to govern vulnerability management rather than perform it, which policy and which steering metrics belong to it, and how you make it demonstrable.

In short

• Vulnerability management is a continuous process, not a one-off scan or a single clean-up.
• As a CISO you steer and account for the process, while IT operations carries it out.
• You prioritise on a risk basis, so not every vulnerability gets the same attention.
• You set remediation deadlines by severity and deliberately manage the exceptions to them.
• You make the management demonstrable with a register, with steering metrics and with accountability to the board.
• It coincides with the four phases of the Kantyra model: detect, assess, resolve and demonstrate.

What vulnerability management involves

Vulnerability management is about controlling the weaknesses through which an attacker can get in. Those weaknesses come from various sources. Think of automated scans, of penetration tests, of supplier notifications, of threat intelligence and of reports from outside.

The process consists of a few fixed steps. You identify vulnerabilities, you assess how severe they are in your context, you assign the remediation to an owner, you fix them within a deadline, and you check whether the remediation actually worked. That sounds simple, but in practice so many vulnerabilities flow in that the art lies in controlling the whole, not in solving one individual report.

Steering or executing: the role of the CISO

IT operations does the work. They run the scans, keep track themselves of which vulnerabilities become known, and install the corresponding patches as soon as they are available. That responsibility rightly sits there, because IT operations knows the systems and manages them daily. It is simply not your role.

As a CISO you govern the process. You set the policy, you determine how quickly which severity must be remediated, you make sure every vulnerability has an owner, and you monitor that the whole works. Where IT operations looks at individual systems, you look at the process as a whole, at the trend and at the residual risk.

You also want to be aware of the important vulnerabilities in good time, before they grow into an incident or an escalation. Not to fix them yourself, but to be able to steer, to inform the board and to intervene if a critical vulnerability is left unaddressed.

IT operations is therefore responsible for remediating, and you are responsible for the assurance that remediation actually happens and on time. You keep those roles separate, because otherwise it becomes a butcher inspecting his own meat.

Why vulnerability management is a board responsibility

Vulnerabilities arise continuously, and a system that is safe today can be vulnerable tomorrow through a newly discovered weakness. Vulnerability management is therefore not a project with an end date, but a continuous responsibility.

That responsibility is also demonstrably assigned. The ISO 27001 standard explicitly requires you to manage technical vulnerabilities, and the duty of care in the Cyber Security Act requires appropriate measures that you must be able to substantiate. A regulator or a customer does not want to hear that you scan, but wants to see that you remediate critical vulnerabilities within an agreed deadline and that you deliberately manage the residual risk. Making that demonstrable is precisely your task.

The policy for vulnerability management

A vulnerability management policy turns loose actions into a governable process. It records the rules the whole organisation abides by. A sound policy describes at least the following points:

• the scope, in other words which systems and sources fall under the process;
• the roles and responsibilities, with a clear separation between steering and executing;
• the way you determine the severity of a vulnerability;
• the remediation deadlines by severity, so it is fixed how quickly something must be resolved;
• the procedure for exceptions and the deliberate acceptance of residual risk;
• the way you measure and report to the board.

Without this policy, vulnerability management becomes a matter of good intentions, in which the most urgent vulnerabilities disappear into the issues of the day.

Risk-based prioritisation instead of everything at once

The biggest pitfall is that your organisation drowns in vulnerabilities. An average environment produces so many that you cannot possibly remediate everything at once. The solution is not to work harder, but to prioritise more sharply.

As a CISO you ensure that the prioritisation is risk-based. A technical severity score, for instance based on CVSS, is only a starting point here. What really counts is the combination of that score with the importance of the affected system and with whether the vulnerability is actually being exploited in practice. A medium vulnerability on a critical system exposed to the internet deserves more attention than a severe vulnerability on a shielded system without impact.

Your role is not to weigh every individual vulnerability, but to establish the assessment framework with which the organisation does so consistently. This way you prevent the volume from becoming the deciding factor instead of the risk.

Remediation deadlines and managing exceptions

A workable process has clear remediation deadlines by severity. You record, for instance, that a critical vulnerability is remediated within days and a low one within a wider period. Those deadlines give IT operations direction and give you a yardstick to steer by.

At least as important is what you do when remediation cannot be done in time. Sometimes a vulnerability cannot be fixed straight away, for instance because a supplier does not yet have a solution. Then there must be a deliberate, temporary risk acceptance, recorded and approved by the right owner, with a date on which you reassess it. As a CISO you guard precisely this point, because without that management, exceptions become silent, permanent risks that no one sees any more.

Measuring and accounting

You can only steer on what you measure. As a CISO you use a limited set of steering metrics to monitor the process and to report on it to the board. Useful steering metrics include:

• the number of open vulnerabilities, broken down by severity;
• the average remediation time, and how it develops over time;
• the percentage of vulnerabilities remediated within the agreed deadline;
• the number of overdue critical vulnerabilities;
• the coverage, in other words which part of your systems is actually in view.

You translate these figures into a board-level story. The board does not need to see a list of vulnerabilities, but wants to know whether the organisation has control, whether the trend is heading the right way and whether there are risks that need attention. This way you turn a technical topic into a board conversation.

From loose reports to coherent management

You cannot govern vulnerabilities if they are scattered across scan reports, emails and loose files. The basis is therefore a vulnerability register: a current and central overview of every vulnerability, with its severity, the affected system, the owner, the remediation deadline, the status and any risk acceptance.

In Kantyra that register is the findings register. You register a vulnerability as a finding with the source "vulnerability scan" or "CVE", above the threshold you choose yourself, so that you steer on what matters and the register does not become scanner output. Per finding you record the severity, the affected asset, the owner, the remediation deadline and the retest date, and at the top of the register the exposure summary shows how many vulnerabilities are open, how many high or critical, and how many have been exploited by an incident.

From that register the lines run to the rest of your system of control. An overdue critical vulnerability is a risk that belongs in your risk register; if you link the finding to a risk, Kantyra automatically creates a reassessment task. If an incident exploits the vulnerability, you link the incident to the finding and its remediation automatically gets priority. If a vulnerability cannot be remediated in time, you record the residual risk as an exception with four-eyes approval and an end date. A register of your systems is the prerequisite, because without a current overview of your assets you miss the vulnerabilities that sit on them. This way vulnerability management connects directly to your information security and risk management (ISMS) in line with ISO 27001, so it becomes a fixed part of your security rather than a loose activity.

Where does vulnerability management sit in the Kantyra model?

Like penetration testing, vulnerability management cannot be captured in a single phase of the Kantyra model: it is the cycle of the model, applied to the weaknesses in your systems. But as a CISO your centre of gravity is not at the bottom.

You largely leave the detect to IT operations: the scans and pentests bring the weaknesses into view, and above your threshold you register them. A large part of your work sits in assess: you weigh on a risk basis, with the technical severity as a starting point and the importance of the system and the actual exploitation as the deciding factor, and you escalate the most severe to the risk register. In resolve you set the policy and the remediation deadlines, monitor the remediation and manage the deliberate risk acceptances. And in demonstrate lies the culmination of your role: the management report bundles the steering metrics, from open by severity and the overdue and exploited vulnerabilities to the average remediation time, the percentage within the deadline and the month-to-month trend, as accountability to the board.

Where IT operations mainly lives in detect and resolve, you steer the whole loop and account for it. That is the difference between fixing vulnerabilities and controlling them.

Do you work with loose documents or with a GRC platform?

You can keep your policy, your steering metrics and your vulnerabilities in loose files, and as a start that is defensible. But as a CISO you soon run into the limits. Loose files give no current overview, no reliable trend and no evidence towards the board or the regulator.

In a GRC platform, you manage the policy, the vulnerability register and the follow-up as connected overviews within a single environment. Every vulnerability has an owner, a status and a deadline, the overdue ones are immediately visible, and the steering metrics calculate themselves, so you steer on severity and remediation time rather than on gut feeling.

With Kantyra you govern vulnerability management in the same environment as your ISMS. You record the policy as a policy document, you keep the exposure summary by severity and remediation deadline, and you manage the exceptions as deliberate risk acceptances. The management report translates that into the steering metrics for the board, with the average remediation time, the percentage within the deadline and the trend, in line with ISO 27001. This way you shift from loose reports to demonstrable steering.

Setting up vulnerability management in five steps

1. Establish the policy. Record the scope, the roles, the remediation deadlines and the accountability.
2. Separate steering from executing. Assign execution to IT operations and steering and accountability to the CISO function.
3. Set up risk-based prioritisation. Combine the technical severity with the importance of the system and the actual exploitation.
4. Measure and report. Choose a limited set of steering metrics and boil them down to a board-level story.
5. Manage everything in coherence. Connect the vulnerability register to your risk register, your improvement actions and your ISMS.

Frequently asked questions about vulnerability management

What is the difference between vulnerability management and patching? Patching is one way to remediate a vulnerability. Vulnerability management is the whole process around it, from discovering and prioritising to remediating, verifying and accounting. Patching is execution, management is steering.

Is vulnerability management a task for IT or for the CISO? For both, but in a different role. IT operations carries out the remediation, while the CISO steers the process, sets the prioritisation and accounts for it. That separation prevents the same party from judging its own work.

Do you have to fix every vulnerability? No. You prioritise on a risk basis. Some vulnerabilities you fix immediately, others you deliberately and temporarily accept as residual risk, provided it is recorded and approved by the right owner.

How quickly must you remediate a critical vulnerability? You record that in your policy. For critical vulnerabilities a short deadline is common, certainly if the system is exposed to the internet or is actually being exploited. The point is that the deadlines by severity are fixed and that you steer by them.

How do you demonstrate that you manage vulnerabilities? With an established policy, a current vulnerability register, a set of steering metrics and periodic reporting to the board. Together these show that you have control and that the residual risk is deliberately assigned.

Getting started with vulnerability management in Kantyra

Do you want to govern vulnerability management rather than chase reports? With Kantyra you keep your policy, your vulnerability register and your follow-up connected, in line with ISO 27001. This way you steer on severity and remediation deadline, the management report shows the steering metrics and the trend for the board, and you manage the exceptions deliberately. Request a demo and discover how to build vulnerability management on top of your existing ISMS.

Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management and compliance demonstrably, in line with standards such as ISO 27001 and ISO 22301 and with legislation such as the GDPR, the Dutch Cyber Security Act and the AI Act.