The Patch Deadline Nobody Legislated

Introduction

#

Critical vulnerabilities in 72 hours. High severity within a week. Everything else inside 30 days.

That ladder turns up constantly in NIS2 material, in compliance checklists, in procurement questionnaires, and in the security questionnaires your customers send you. It does not turn up in NIS2.

An obligation, not a clock

#

NIS2 does impose a vulnerability duty. Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”.¹ That is a real obligation and it is enforceable. What it is not is a deadline: the directive contains no patching timeframe of any kind.

The directive does contain deadlines, which is where the trouble starts. Article 23 requires an early warning within 24 hours and an incident notification within 72 hours. Those are deadlines for telling someone, not for fixing anything. The gap between those two ideas is, as far as I can tell, the entire origin of the 72-hour patching rule that does not exist.

The last place it could hide

#

The obvious rejoinder is that the detail lives in the implementing act rather than the directive. It does not.

Commission Implementing Regulation (EU) 2024/2690 lays down the binding technical requirements for the entity types it covers, and it is remarkably deliberate about this. Point 6.6.1(a) requires that “security patches are applied within a reasonable time after they become available”.² Point 6.10.2(c) requires entities to “address, without undue delay, vulnerabilities identified by the relevant entities as critical to their operations”. Point 6.6.2 goes further and permits not patching, where “the disadvantages of applying the security patches outweigh the cybersecurity benefits”, provided the decision is documented.

Search that regulation for a patching timeframe and you will not find one. It is not shy of numbers elsewhere — it defines significant incidents in minutes, hours, user counts and euros — but on how fast a patch must land there is no 24 hours, no 48, no 72, no seven days, no 30 days. The Commission looked directly at the question of how fast is fast enough, and declined to answer it.

Austria did not fill the gap either

#

The Austrian transposition offers no more comfort. The Netz- und Informationssystemsicherheitsgesetz 2026 fills some thirty-five pages of the Federal Law Gazette and uses the word Schwachstelle — vulnerability — twenty-eight times.³ It uses the word Patch zero times. Sicherheitsupdate likewise: zero. The 24- and 72-hour figures appear there too, and there too they are deadlines for reporting and responding, not for patching.

Credit where it is due: the Austrian ecosystem has this right. Every Austrian source I checked — WKO, cert.at, Austrian Standards, the large consultancies — describes the reporting clocks accurately, several citing the paragraph numbers. I went looking for an Austrian source that pins a patching deadline on the NISG and could not find one.

Where the number goes

#

The pattern repeats in financial services. DORA obliges entities to “have appropriate and comprehensive documented policies for patches and updates” under Article 9(4)(f).⁴ A policy, note, not a period.

But Article 30 requires that contracts with ICT third parties be in writing and that “the full contract shall include the service level agreements”. So the same body of law that refuses to set a remediation deadline requires that service levels be written into supplier contracts. That isn’t an inconsistency. It is where the number goes.

The Cyber Resilience Act gets pulled in too, and doubly wrongly: its Article 14 deadlines are reporting deadlines, and they bind manufacturers placing products on the EU market — very unlikely to be you, unless you substantially modify a product and put it on the market, or sell one under your own name.⁵

It comes from your customer

#

If the law does not set the number, something else does, and it is not hard to find. Vendor SLA matrices set it, and they do not agree with one another: depending on whose page you read, “critical” means 24 hours, 48 hours, 72 hours or seven days. Those matrices flow into procurement questionnaires, the questionnaires flow into contracts, and at that point the deadline becomes genuinely binding — just not by statute.

Most publishers are honest about this. The prevailing pattern in NIS2 content is to print a suggested ladder and label it explicitly as a recommendation, which is fine. The failure is one of proximity rather than dishonesty: the ladder gets set next to a quotation from Article 21, and readers fuse the two.

A minority skip the fusion and simply assert it, and the clearest example is also the most instructive. A regulatory brief warns of “failure to address these within the 72-hour remediation window (for essential entities) or 1 month (for important entities)”.⁶ Article 23’s reporting windows have been relabelled as remediation windows, which is precisely the confusion the two-clock problem predicts. The same brief quotes Article 21(2)(d) as requiring “measures to prevent and minimise the impact of incidents”. No such sentence exists in NIS2 — the nearest is the general duty in Article 21(1), which is not subparagraph (d). Subparagraph (d) is about supply chain security.

What to do with this

#

Three practical consequences.

Know which of your deadlines are statutory and which are contractual, because they fail differently. Missing a reporting deadline is a regulatory matter. Missing a patching SLA is a commercial one, and it is negotiable in a way the reporting clock is not.

When a questionnaire asserts a legal patching deadline, ask which provision it comes from. There isn’t one, and the question is more useful than the argument.

And write down what your reasonable time is, per asset class, with the reasoning. That is the most direct way to meet 6.6.1(a), and — unlike a borrowed 72-hour rule — it is a position you can defend to an auditor. The borrowed numbers are worth distrusting on their own merits: almost none of them were ever derived.

The number nobody legislated is the one everyone quotes. The regulator declined to pick it because the right answer depends on the asset, the exposure and the blast radius — which is exactly the judgement the law is asking you to make, and to write down.