Thirty Days Since 1999

Introduction

#

Almost every vulnerability management programme runs on a severity ladder. Critical in fifteen days, or thirty, or seven. High in thirty, or sixty. The numbers vary, the shape never does, and nobody I have asked can say where their particular numbers came from.

I went looking for the origin of the oldest one.

The oldest number was never justified

#

The oldest thirty-day window I could find is older than many of the people applying it. The US Department of Defense ran an Information Assurance Vulnerability Alert process from 1998, and a Deputy Secretary of Defense memorandum of 30 December 1999 attached a corrective-action window to it. Thirty days.

What makes the document interesting is not the number but what happened next. By December 2000 the DoD Inspector General had audited compliance and found it uneven — not the remediation, but the reporting of it, which is a lower bar.¹ In August progress was inconsistent; by November most components were reporting as required, but the Army was still reporting percentages and the Air Force simply stated that it was compliant. The number was a year old, and two of the four Services still could not show, in the form the policy asked for, whether it was being met.

I could not find any document establishing why thirty days was the right answer. Not a study, not a model, not an argument. That doesn’t make it wrong — thirty days is a perfectly reasonable guess — but a guess that has been in continuous service for twenty-seven years has usually acquired some evidence, and this one has not.

A factor of ten

#

Modern practice is supposed to have moved past fixed windows to exploitability-based prioritisation, which is a genuine improvement. It hasn’t made the numbers any better founded.

Shimizu and Hashimoto propose a chained rule: escalate if a vulnerability is on CISA’s KEV catalogue or scores at or above 0.088 on EPSS, then filter on CVSS 7.0.² They take 0.088 from earlier EPSS research as the point that balances efficiency and coverage. Albert-Jan Talsma publishes a decision tree of almost identical shape — KEV first, then EPSS, then CVSS, then reachability — and escalates above 0.88.³

The same metric, the same position in the same decision, and a factor of ten between them.

To his credit, Talsma labels his thresholds “indicative” in the accompanying text, which is more candour than the genre usually manages. The academic paper is less fortunate: its own evaluation table shows that simply using the KEV catalogue on its own beats the proposed rule on both coverage and efficiency. The authors’ ground truth is ninety vendor-documented exploitations, a set small enough and public enough that KEV was always likely to cover most of it — which explains the result without excusing it. The rule is undercut by the data presented to justify it.

The regulator declined

#

European law is the one place you might expect a number to be settled by fiat, and it conspicuously is not. The implementing regulation under NIS2 — which binds digital-infrastructure and digital-service providers — requires only that security patches are applied “within a reasonable time”, and permits documented non-patching where the disadvantages outweigh the benefits.⁴ There is no patching figure anywhere in it. What NIS2 and the Austrian NISG actually require is its own story, because the gap between what the law says and what the market believes it says is wide enough to deserve one — and it gets its own post.

One government published its working

#

CISA is the exception, and it is worth studying precisely because it shows what picking numbers honestly costs.

Binding Operational Directive 26-04 replaced two directives — the KEV deadline, fourteen days for anything recent, and BOD 19-02’s severity ladder for internet-facing systems, fifteen days for critical and thirty for high — with a sixteen-row matrix.⁵ Four inputs — internet exposure, KEV membership, whether exploitation is automatable, and technical impact — produce four remediation windows: three days, fourteen days, sixty days, or fix at the next scheduled system upgrade.

Two things about it get misreported. It did not simply narrow the obligation: eight of the sixteen rows apply to vulnerabilities that are not on KEV, including internal systems that neither old directive reached. And it tightened the top of the scale rather than relaxing it, from fourteen days to three. The Table 1 timelines bind only from December 2026, 180 days after issuance, so for now the matrix is a published intention rather than a live obligation.

Then CISA published what the model produced in practice. In an initial analysis at one large civilian agency, “only 1% of vulnerability instances fall into the three-day category, with over 60% of the vulnerability instances deferred to the next system upgrade”.⁶ One agency, and CISA’s own word is “initial” — but the direction is striking. Apply a defensible risk model to a real estate and most of its vulnerability backlog turns out to be able to wait for the next scheduled upgrade.

It is still the closest thing to a measurement the ladders have ever been given.

Numbers you can defend

#

None of this argues for having no thresholds. It argues that the threshold is a judgement you own rather than a fact you inherit, and the practical consequences are small and specific.

Say who is allowed to accept the risk, before you need to. The NCSC puts it plainly: the organisation must own the risk of not updating, and an exception is only real if it records its rationale.⁷ The BSI’s IT-Grundschutz goes further and makes named responsibility testable — OPS.1.1.3.A2 requires named owners per organisational area, which is the sort of requirement an auditor can actually check.⁸

And be honest about which of your practices are evidenced. Deployment rings are a sensible borrowing from release engineering, but I could find no measurement showing they reduce patch-induced outages — they are asserted, like the ladders. If you want a pipeline with actual working behind it — not the threshold, which Talsma himself calls indicative, but the reachability analysis around it — his is a decent model: he publishes the code, and the prerequisites are concrete enough to check yourself against — asset and vulnerability data through an API, firewall ACLs through an API, trust levels per zone, and a count of live assets per subnet. That list is also the honest answer to why so many programmes never get past severity sorting.

The thirty-day window has survived twenty-seven years, one contemporaneous audit that found much of the department unable to report against it, and the arrival of far better data, without ever acquiring a justification. It will probably outlive this post too.