Two Models, One Auditor

Introduction

#

CISA’s triage tree outputs Track, Track*, Attend and Act, and keys them to whatever update cadence you already run.¹ Cyber Essentials outputs fourteen days for anything scoring 7 or above.² Your customers’ questionnaires want the second. The regulation, read carefully, asks for your reasoning, not a band.

Both are current. Neither is wrong.

That isn’t an embarrassment to be resolved — it is the actual shape of the problem, and once you accept that you will run both, the process design gets much easier.

What happens, not how many days

#

The most useful published decision trees do not produce a deadline. They produce a destination.

Tenable published one recently for triaging findings from an AI code-security harness — the volume problem, now reaching defenders’ own code.³ It asks, in order: is it confirmed with a proof of concept, is it reachable from an untrusted exposed entry point, is exploitation automatable, what control does the exploit grant, and is a crown-jewel asset or trust boundary involved. The outputs are a validation queue, a backlog ticket, a fix in the next planned release, a patch before the next release, or an emergency out-of-band patch.

Not one of those is a number of days. Every one of them is a place in an existing delivery process.

Chromium’s security release management does the same thing with a different pair of inputs — severity, and whether the vulnerable code has already shipped to stable — and lands on an emergency out-of-band release, the next scheduled stable point release, or the next milestone release.⁴ The release train is the clock.

This matters practically, because a destination survives contact with the engineering team that has to do the work. “Fix in the next planned release” is a sentence a delivery manager can act on. “Fourteen days” is a sentence they will negotiate with you.

None of this means numbers are forbidden; it means a number needs a stated purpose and a stated exception. Where Chromium does use day-counts, in its severity guidelines, each is attached to an objective rather than asserted, and issues marked as having no security impact are exempt from the usual fix timelines on the stated grounds that deadlines for them do not improve security outcomes.⁵

The questions converge

#

Tenable built its tree for findings produced by an AI harness. CISA built its model for federal civilian agencies. They are asking almost identical questions.

Exploitation, exposure, automatability, technical impact, mission impact: those are SSVC’s decision points, and Tenable’s tree asks them. Whether its authors borrowed them or rediscovered them, the result is the same: the questions travel across problems that have nothing else in common, and the day-counts do not — an argument I have made in more detail elsewhere.

CISA’s own binding directive, BOD 26-04, turns the same decision points into three days, fourteen days, sixty days, or the next scheduled system upgrade.⁶ Even inside that directive the numbers are not the interesting structure. Only two of its sixteen rows resolve to “fix on system upgrade” — the rows where the vulnerability is not exposed, not known-exploited and not automatable — but on the one estate CISA has published an initial analysis for, those two rows absorbed over 60 percent of real vulnerability instances.⁷

Where agreement collapses

#

Here is the finding that should temper anyone’s enthusiasm for decision trees, and it comes from the framework’s own authors.

In SEI’s published evaluation of the draft SSVC trees, six analysts — five of them the paper’s authors — scored the same vulnerabilities from an identical information sheet.⁸ Agreement on Exploitation was strong, with a Fleiss’ kappa of 0.807. Agreement on the final deployer outcome was 0.295. On Mission Impact it was 0.146.

Publishing that is an unusually honest act. It also localises the problem precisely: analysts agree about the vulnerability and disagree about the environment.

The practical response is the one SEI itself now recommends. Exploitation and Automatable can be supplied from CISA’s Vulnrichment data rather than judged locally, which leaves the deployer needing only System Exposure and Human Impact — and those, as SEI puts it, are “static from one vulnerability to the next”.⁹

So score your estate once, not every vulnerability. Decide now which systems are exposed and which failures would hurt, record it, and triage becomes a lookup against a table you already own. That doesn’t make the judgement better. It makes it made once, by someone with a name on it, instead of afresh by whoever is on triage that day — which is about as much as a kappa of 0.146 will let you claim.

The ladder question

#

Now the part the prioritisation literature consistently omits: adopting a risk model does not retire the severity ladder. You will run both.

The Department for Work and Pensions publishes this openly, which is rare.¹⁰ Its patching standard defines a contextual risk method — validation as impact multiplied by viability, across environment, value, resilience and exposure — and then, separately, a severity-band ladder that it labels the mandatory minimum compliance level for legacy estates and external suppliers. Two regimes, one standard, both in force.

The pressure to keep the ladder is real and it is documented. Cyber Essentials, updated in April 2026, still keys its fourteen-day requirement to a CVSS v3 base score of 7 or above, and it is a condition of many UK central-government contracts¹¹ and a great many customer questionnaires.² SSVC’s own limitations page anticipates this: it calls converting outcomes to numbers “ungainly” but sound “if existing processes require it”, offers the midpoints of the CVSS severity ranges as labels — and warns that such labels “may be misused as numbers”.¹²

The financial regulator is not the source of this. DORA itself asks for a policy, not a period, and its technical standard contains no CVSS reference, no severity bands and no remediation day-counts.¹³ It adds a weekly scan of assets supporting critical or important functions, a duty to prioritise, document and verify — and, in Article 10(4)(d), a duty to set the deadlines yourself.

So the regulation asks you to derive and record your reasoning. The certification scheme, the supplier standard and the customer questionnaire ask you for a band. Those are different demands, and conflating them is why so many programmes think the law made them do it.

The exception register that is not decorative

#

Most exception processes fail the same way: an exception is granted, nothing expires it, and the register becomes a graveyard.

Two published mechanisms fix that. The DWP standard requires accepted risks to be time-bound and reviewed on a fixed cycle, and adds the condition almost nobody writes down — an accepted risk is immediately void on evidence of active exploitation. The acceptance was conditional on the threat picture, so a change in the threat picture ends it automatically, without anyone needing to argue for revoking it.

GitLab’s handbook supplies the other half: a negative list, under which an exception is not available where the deadline was missed for reasons within GitLab’s control — explicitly including other work having a higher priority.¹⁴ Without that clause, “exception” becomes a synonym for “we were busy”.

The shape of the thing

#

Two models isn’t a failure state, and pretending otherwise produces programmes that quietly maintain a spreadsheet nobody admits to.

Decide the questions once — is it real, is it reachable, is it automatable, what does it grant, does it touch something that matters. Score your estate once for exposure and impact, and revisit it on a schedule rather than per finding. Route the answer to a destination in your delivery process rather than a date. Keep the ladder as an output format for the people who ask for one.

A number with a reason and a documented exemption is a policy. The same number inherited from a slide deck is a superstition — and the auditor can tell them apart, because only one of them says when it stops applying.