Patch and vulnerability management under NIS2: who is accountable and with what evidence

Patch management under NIS2 is the least glamorous control there is, and the first one an auditor asks about. Not because patching is hard, but because it reveals in thirty seconds whether an organisation has real control over its platform or only good intentions.

I have been on both sides of that conversation: running remediation in environments where stopping a service costs real money, and explaining afterwards why some things were patched in days and others are still waiting. What follows is what works.

What NIS2 changes in this conversation

NIS2 places vulnerability handling among the minimum required measures, alongside risk analysis, continuity and supply chain security. And it does something more uncomfortable: it makes management bodies expressly accountable, required to approve the measures and to train in order to understand them.

The practical effect is a change of counterpart. A pending patch used to be a matter between the systems administrator and the application owner. Now it is a risk accepted by somebody named on the board. That forces the exception to be written, dated and signed, rather than negotiated over email on a Friday afternoon.

In Spain the transposition is still in progress, with partial obligations already in force. Waiting for the law to build the process is the expensive mistake: when it lands, the deadline will be the law’s, not your calendar’s. I cover this in the regulatory overlap between DORA, NIS2, ENS and the AI Act.

The real problem is not patching

Applying a patch has been a solved procedure for twenty years. What is not solved is deciding what stays unpatched, for how long, and in exchange for what.

The window the business will not give you

Every organisation has a handful of services that cannot be stopped at any reasonable hour, or whose vendor certifies new versions six months late. There the patch is not late through negligence: it is late because the system is designed to make it late.

The mature answer is not to promise faster patching. It is to acknowledge the constraint, measure how much it exposes and compensate for it with controls: segmentation, restricted access, reinforced monitoring on that specific asset.

Exceptions with a date and an owner

A useful exception has four fields and none is optional: which asset, which risk is accepted, which compensating control applies meanwhile, and when it gets reviewed. With no review date it is not an exception, it is neglect with paperwork.

And one rule that saves arguments: the exception is signed by whoever carries the business risk, not by whoever administers the server. If the administrator is the only signature, the risk has not been accepted, it has been delegated downwards.

From inventory to remediation deadline

The whole process rests on three pieces, and the first is always the missing one.

• An inventory with owners. Not a list of machines: assets with an identified business owner. What has no owner never gets patched, because nobody authorises the outage.
• Business criticality, not just a technical score. A high-severity flaw on an isolated server holding no data matters less than a medium one on the system that carries the operation. The score sorts; the context decides.
• Deadlines you can defend. Few tiers, written down, approved by management and met. A twenty-four-hour commitment that is systematically missed is worse than a seven-day one that is kept: the first destroys the credibility of the whole process.

On what actually gets exploited: most incidents do not arrive through the newest vulnerability, but through an old, well-known one with a patch available for months. Prioritising by «what is being exploited out there» pays better than prioritising on theoretical score alone.

The tiers that work

Four tiers are enough. More than four and nobody remembers them, so they end up decorative.

• Emergency. A vulnerability with confirmed active exploitation on an exposed asset. Called outside the calendar, impact accepted, documented afterwards. It should happen two or three times a year; if it happens weekly, patching is not your problem.
• Critical. High severity on exposed assets or assets handling sensitive data. A window in the coming calendar week, negotiated in advance and already reserved in the business calendar.
• Routine. The bulk of the estate, in the monthly maintenance cycle. What matters here is not speed but that the cycle is never skipped.
• Deferred with an exception. What cannot be touched yet, with a compensating control and a review date. It must be a short, visible list; if it keeps growing, the exception has become the policy.

The detail that makes the difference is not the length of each tier, but that the windows are reserved before the vulnerability appears. Negotiating an outage once an advisory is already published is negotiating from the worst possible position.

How to measure a patching process

The indicator almost everyone shows — percentage of systems up to date — is the least useful of all, because ninety-eight per cent is very reassuring and says nothing about which assets make up the remaining two.

Three measures give better information:

• Time from publication to remediation, measured per tier. Not from when your scanner found it: from when it existed in the world. The gap between those two dates measures the quality of your detection, which is usually the weak link.
• Age of what is outstanding. How long the oldest unresolved item has been open. It is the measure a supervisor understands immediately and the one that stings most internally.
• Inventory coverage. What share of the real estate is actually being assessed. If the scanner never reaches a segment, that segment looks perfect on every dashboard.

The third is the one that produces surprises. Almost every review turns up a slice of the estate nobody was looking at: pre-production environments holding real data, labs left switched on, vendor appliances nobody put in scope.

What you do not control

A growing share of your surface is not patched from your console: cloud services, components managed by a provider, devices whose firmware depends on the manufacturer. NIS2 does not excuse you from that; on the contrary, it expressly includes supply chain security among the required measures.

What changes is the nature of the control. On your own estate the control is technical: you apply the patch. On somebody else’s it is contractual and observational: what deadlines are committed, how you get notified, what evidence you receive and what happens if they miss.

That is the least technical and most profitable work in the whole process, and it is almost always undone because it falls between the procurement desk and the security desk. I cover it in the piece on NIS2 penalties and how to avoid them.

The evidence an auditor asks for

Not screenshots of a console. The ability to reconstruct a story: this vulnerability was published on this date, detected in our estate on that date, classified this way, remediated then or accepted with this compensation, and signed by this person.

If that chain can be reconstructed for three cases picked at random, the audit goes well even if the estate is not perfect. If it cannot, no dashboard will save it however green it looks.

What I learned in regulated environments

The bottleneck is the window, not the patch. You plan in weeks of other people’s calendars, not in engineer-hours. Whoever does not negotiate windows in advance accumulates debt faster than any team can absorb it.

Assets with no owner are the hole. Every review turns up a share of machines nobody claims. That set concentrates the oldest vulnerabilities in the estate, and the fix is usually to switch them off rather than patch them.

A mediocre process that is followed beats an excellent one that is not. It is the same lesson as in migrations: credibility is earned in the first windows, and once earned the business stops fighting every outage. You can see how it applies across the nine programmes I have run in banking and in the piece on Windows Server 2016 end of support, where the problem is exactly the same at a different scale.

If you also manufacture or sell software or connected devices, vulnerability management no longer ends at your own estate: since 11 September 2026 the Cyber Resilience Act requires actively exploited vulnerabilities to be reported within 24 hours. I explain how in Cyber Resilience Act: how to report vulnerabilities within 24 hours.

Conclusion: what is actually supervised

NIS2 will not ask you for an estate with no vulnerabilities. That does not exist. It will ask you to know which ones you have, to have decided what you are doing about each, and for somebody accountable to have signed it.

Put another way: your hygiene is not what gets supervised. Your judgement is.

Frequently asked questions about patch management and NIS2