NIS2 and remediation priority: where exploitability fits

On Monday a team receives details of two vulnerabilities. The first carries a higher scanner score but sits in an internal administrative system. The second scores lower, affects a public order-intake service, and the vendor reports that it has been used in attacks. Updating the public service, meanwhile, requires additional testing.

Which one gets fixed first? NIS2 gives no ready answer, and it sets no formula under which evidence of exploitation automatically raises priority. The directive asks for something else: appropriate and proportionate cyber risk-management measures, vulnerability handling among them. So the organization has to be able to connect a remediation decision to the risk to its own systems and services.

What NIS2 actually requires

Article 21(1) of Directive (EU) 2022/2555 requires the essential and important entities in its scope to take appropriate and proportionate technical, operational and organizational measures to manage the risks posed to the security of network and information systems. Proportionality is assessed with regard to, among other things, the entity's degree of exposure to risks, its size, the likelihood and severity of incidents, and their potential societal and economic impact.

Article 21(2)(e) covers security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. That ties vulnerability work to the overall risk-management system, but it does not define a separate priority scale.

Regulation (EU) 2024/2690 sets out more specific requirements for the categories of entities it covers. On patch management, its annex calls for procedures aligned with change, vulnerability and risk management. In particular:

• patches are applied within a reasonable time after they become available;
• patches are tested before they are installed in the production environment;
• patches come from trusted sources and their integrity is verified;
• installed patches are documented.

The regulation also addresses the case where a patch is unavailable or is not applied within the intended time: additional measures are then required, and the residual risk that remains is documented. The link to NIS2 therefore runs not through a mandatory sort by exploitability, but through a managed and documented choice of measures that takes risk into account.

What a concrete decision looks like

Back to the two vulnerabilities.

System A — internal administrative server

The vulnerability score is higher. The server supports an auxiliary function and access to it is limited to the corporate environment. An update is ready and can be installed in the standard maintenance window.

System B — public order-intake service

The vulnerability score is lower. The vendor's notice states that the vulnerability has been used in attacks. Installing the update without testing could break the integration with the payment module.

The team decides to take System B first. This is not an automatic conclusion drawn from NIS2, and it is not a universal rule for any external system. In this example the decision rests on recorded circumstances: the service is publicly reachable, the vendor has reported exploitation, the system has a specific purpose, and an interruption to order intake would carry its own impact.

The decision does not necessarily mean installing an untested update immediately. The team can first restrict the affected function, run accelerated testing, and schedule the installation. System A keeps a separate remediation deadline in the next maintenance window.

A record of such a decision might capture:

• which systems and services are affected;
• which information was used in the assessment;
• how exposure, likelihood and potential impact were assessed;
• which fix or additional measure was chosen;
• what residual risk remains;
• who approved the decision and when it is to be reviewed.

This list is not a matrix set by NIS2. It shows how an organization can record, in a working document, the circumstances its choice was based on. If the team puts System A first, it should likewise be able to explain that decision — by that system's particular privileges, for example, or by the impact its compromise could have.

Where exploitability sits in the process

Evidence of exploitation should not be presented as a separate NIS2 requirement. Its place is determined by how the organization assesses risk. An internal procedure might specify, for instance, that a vendor report of attacks goes to the system owner and to the specialist responsible for risk assessment. They then check which of the affected components the organization actually uses and which services depend on them.

Such a procedure matters not because the directive prescribes a particular outcome, but because it connects new information to an assessment that already exists. The team is not simply adding a flag to a vulnerability record; it is deciding whether the new information changes the likelihood of an incident, the degree of exposure and the potential impact in its own environment.

An internal policy can use exploitability as an escalation criterion. A vendor report might trigger an unscheduled review, for example, without necessarily requiring an immediate patch. The review can end in an update, a temporary additional measure, an unchanged deadline, or a documented residual risk. NIS2 sets a risk-based frame, not one mandatory answer.

What to check in your remediation procedure

The procedure should distinguish intake of information, assessment, and execution of the decision. Otherwise one team may consider the task finished once the vulnerability is logged, while another is waiting for the update to be installed.

When information arrives, establish whether it affects systems in use. Then assess the circumstances relevant to the risk to a specific service. Then choose a measure and assign an owner and a deadline. If the update is deferred, the decision does not end with a note saying later: for entities covered by Regulation 2024/2690, additional measures have to be defined and the residual risk documented.

It is worth checking separately whether the procedure reflects the requirements on patch management itself. Urgency does not remove the need to test an update before production installation, to verify its source and integrity, and to document the change that was made. These steps tie the team's day-to-day work directly to the requirements of the regulation, rather than to a universal vulnerability-scoring formula.

What becomes verifiable, in the end, is not the statement we always put exploited vulnerabilities first, but the sequence behind a specific decision: which facts were known, how they were related to the risk to the service, which measure was chosen and which risk remained. That is what separates an internal prioritization criterion from a rule that NIS2 does not contain.