Every vulnerability management team hits the same wall. The scanner produces 4,000 findings, 600 of them are rated Critical or High, and the patch window fits maybe 80. So which 80?

For years the answer was to sort by CVSS base score and work down the list. The problem is that CVSS measures how severe a flaw is in theory. It says nothing about whether anyone is exploiting it, whether your vulnerable box is even reachable, or whether that box runs payroll or a forgotten test VM. A CVSS 9.8 on an isolated lab server and a CVSS 7.5 on your internet-facing VPN gateway that ransomware crews are scanning right now are not the same problem, but a CVSS-sorted list treats the first as more urgent.

CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) fixes this by replacing a single number with a short decision tree. You answer five questions about the vulnerability and your own environment, and the tree returns one of four actions. In this post we’ll walk through the model as published in CISA’s November 2022 guide and score six realistic scenarios end to end.

Why “stakeholder-specific” matters

The key word is stakeholder. SSVC does not give a vulnerability one global priority. The same CVE can be an emergency for one organization and a routine patch for another, because the answer depends on how the affected component is used in your environment.

CISA built its version of the tree for US government bodies, state and local governments, and critical infrastructure, but the guide states plainly that any organization can use it to improve its own vulnerability management. For EU organizations working toward NIS2, that’s a useful gift: a documented, defensible prioritization method you can show an auditor.

The four outcomes

These are organizational actions, not just patch deadlines. Act means leadership is in the room. That is a much clearer signal to a CIO than “CVSS 9.1”.

The guide also stresses scope: before scoring, decide where the boundaries of the affected system lie, and whether a flaw present across several related systems is analyzed as one vulnerability or several. Getting scope wrong skews every answer that follows.

The decision points

CISA’s tree uses five decision points, plus one tracked value that doesn’t change the outcome. One design choice stands out: there is no “unknown” option. If you don’t know a value, you pick the most reasonable assumption based on past events and revise it later. That forces analysts to commit instead of parking tickets in limbo.

1. Exploitation: what is happening right now?

This is about the current state of exploitation, not a prediction of the future or a measure of how easy an exploit would be to write. Because it changes over time, CISA recommends timestamping your answer.

Practical sources: the vendor advisory, NVD and the links therein, sector ISAC bulletins, credible threat reports that name the CVE, and above all the CISA Known Exploited Vulnerabilities (KEV) catalog. If a CVE is in KEV, Exploitation is Active.

2. Automatable: can an attacker scale this?

The question is whether an attacker can reliably automate the first four steps of the kill chain: reconnaissance, weaponization, delivery and exploitation. Put differently: is it wormable?

The trick is to look for barriers, and one effective barrier is enough for a No. Common barriers include a component that isn’t searchable or enumerable on the network, weaponization that needs human direction per target, delivery channels that standard security configurations block, required authentication, and exploit mitigations such as ASLR enabled by default.

Barriers can be defeated by vulnerability chaining. If a second, easy vulnerability in the same product hands the attacker a guest account or code injection, the authentication barrier on the first one no longer counts. We’ll see a real example of this below.

The guide suggests Shodan to check whether a component is commonly internet-facing across other operators, not just in your own network:

# Install and initialise the Shodan CLI
pip install shodan
shodan init <YOUR_API_KEY>

# Count exposed instances (adjust the fingerprint to your product)
shodan count 'http.title:"Citrix Gateway"'
shodan stats --facets country 'http.title:"Citrix Gateway"'

Thousands of exposed instances means reconnaissance is trivially automatable. And remember what a No really means: not that automation is impossible in every scenario, but that with the information available today you can’t sketch a plausible path through all four steps.

3. Technical Impact: how much control does the attacker get?

This is the closest SSVC gets to CVSS severity, scoped to the vulnerable component.

4. Mission Prevalence: how central is this component to what you do?

A Mission Essential Function (MEF) is something the organization must keep doing even during a disruption. If you have a business continuity plan, you already have a list of these.

This is about criticality, not device count. Two devices that directly provide an essential service outweigh 500 kiosks, although sheer ubiquity can itself make a component essential. And you do not factor in compensating controls here; Technical Impact and Automatable already cover that.

5. Public Well-Being Impact: what happens to people?

This looks past the IT system to the humans affected, using the CDC’s broad definition of well-being: physical, social, emotional and psychological health.

Combining Mission and Well-Being

These two are merged into a single value before entering the tree:

Anything Essential is automatically High, and anything with Irreversible well-being impact is automatically High.

6. Mitigation Status: tracked, but it doesn’t change the decision

CISA records three factors: whether a mitigation is available, whether it’s a fix (official patch) or a workaround (reconfiguration that prevents exploitation without patching), and the system change difficulty. Difficulty is High if the system has no integrated update process, needs exceptional downtime, loses functionality below acceptable levels after mitigation, or sits in a regulatory environment that may block the change.

In CISA’s tree this does not change the priority. It changes how you execute. An Act on a system with high change difficulty means you’ll likely lead with a workaround while you plan the real fix.

The full decision table

Here’s the complete CISA tree flattened into one colour-coded grid. Rows are Exploitation / Automatable / Technical Impact; columns are the combined Mission & Well-Being value.

Spend a minute with this grid, because it contains the most important lessons of SSVC:

Worked examples

Let’s score six scenarios. Several use real, well-documented CVEs; the others are realistic hypotheticals drawn from environments I work in.

Example 1: Citrix Bleed at an SMB whose only remote access runs through NetScaler

CVE-2023-4966 is a buffer over-read in Citrix NetScaler ADC and Gateway that leaks memory, including valid session tokens.

The mitigation note matters here: patching alone wasn’t enough, because stolen sessions stay valid. The vendor guidance was to patch and kill all active and persistent sessions. This is exactly why SSVC tracks mitigation separately from priority.

Example 2: Same CVE, different stakeholder

Now a NetScaler appliance sits in a pre-production test environment. No real users, no production traffic, not tied to any essential function.

Still not ignorable, because actively exploited and wormable never goes below Attend, but it doesn’t need leadership in a war room. This is the whole point of stakeholder-specific scoring: same CVE, different priority.

Example 3: The Ivanti Connect Secure chain

In January 2024, attackers chained two Ivanti Connect Secure flaws. CVE-2024-21887 is a command injection that on its own requires an authenticated administrator. CVE-2023-46805 is an authentication bypass. Together they give unauthenticated remote code execution.

Scored in isolation, you’d be tempted to call CVE-2024-21887 not automatable because authentication is a barrier. The SSVC guide explicitly tells you to consider chaining: if another common unpatched flaw in the same product removes the barrier, the barrier isn’t effective.

An analyst who scored the command injection alone as “authenticated, therefore not automatable” would have landed on Attend and lost valuable days.

Example 4: Drinking water utility HMI with a public PoC

Hypothetical: a public PoC appears for an authentication bypass in the HMI software of a regional water utility, a NIS2 essential entity. The HMI sits in a segmented OT network with no internet exposure, and Shodan shows almost no publicly reachable instances at other operators either.

Supervisors get involved now, notifications go out, remediation happens faster than normal. And the moment credible exploitation reports appear, this jumps to Act (active / no / total / high). That’s why the timestamp on your Exploitation value matters.

Mitigation status here is almost certainly high change difficulty: OT systems rarely have integrated update processes and patching may require exceptional downtime. Plan the workaround now (tighter segmentation, jump-host restrictions, monitoring on the HMI), not when it becomes Act.

Example 5: An essential telecom asset that is still just Track

Hypothetical from the ISP world: a stored XSS in the web GUI of an access-network management platform. It requires an authenticated operator account, there’s no public PoC, and it only lets the attacker alter what’s rendered in another operator’s session.

Even on an essential platform, a flaw with no exploitation, no automation path and only partial impact is routine patching. Many teams would escalate this in a panic because “it’s the core platform”. SSVC keeps you honest.

Example 6: A Track* on the Windows fleet

Hypothetical: a local privilege escalation in a Windows driver on standard employee laptops. A PoC was published on GitHub yesterday. It needs local code execution first, so it can’t be automated end to end. Successful exploitation gives SYSTEM.

Normal patch cycle, but flag it. LPEs with public PoCs are a favourite follow-on step after phishing, and ransomware crews adopt them quickly. For the detection side of AD², this is a good moment to write a hunt for the PoC’s behaviour while the patch rolls out.

Turning decisions into SLAs

CISA’s guidance uses relative language (“sooner than standard”, “as soon as possible”), which you need to translate into concrete targets. Here’s an example mapping many organizations start from. It is not part of the CISA guide; tune it to your risk appetite and document it in your vulnerability management policy.

The re-check on Track* is the part most teams skip. Exploitation status is the fastest-changing input in the tree, so compare your open findings against KEV on a schedule and let a status change re-open the ticket.

Why this matters for NIS2

For Belgian and other EU organizations in scope of NIS2, Article 21(2)(e) explicitly lists vulnerability handling and disclosure among the required cybersecurity risk-management measures. Auditors and supervisory authorities will want to see not just that you patch, but how you decide what to patch first, and that the method is consistent and repeatable.

SSVC gives you that on a plate: a published, externally recognized methodology; a documented reason for every prioritization decision in the form of five decision-point values; an explicit link between vulnerability management and your business continuity plan, since Mission Prevalence is built on your mission essential functions; and a natural hook into notification thinking, because Act and Attend both include internal and external communication.

Common pitfalls

• Scoring Automatable in isolation. Always ask whether another common, unpatched flaw in the same product removes the barrier. The Ivanti chain is the textbook case.
• Treating “information disclosure” as Partial by reflex. If what leaks is credentials or session tokens that give full control, it’s Total.
• Letting compensating controls creep into Mission Prevalence. Mission is about how important the component is, not how well it’s protected. Protection belongs in Automatable.
• Never updating Exploitation. A PoC-level Attend becomes Act the day exploitation reports appear. Timestamp your answers and re-check them regularly.
• Letting mitigation difficulty lower the priority. In CISA’s tree it doesn’t. A hard-to-patch system with an Act decision needs a faster workaround, not a lower priority.
• Using CISA’s well-being thresholds without adapting them. The tree was built for government and critical infrastructure. An SMB will rarely hit Material or Irreversible; a hospital, water utility or telecom operator will. That’s expected, not a flaw.

Wrapping up

SSVC doesn’t replace CVSS; it puts it in context. CVSS tells you how bad a flaw could be. SSVC asks whether attackers are using it, whether they can scale it, how much it gives them, and how much you depend on the thing that’s vulnerable. The result is a short list of Act and Attend items your team can actually finish, with a defensible reason behind every one.

Start small: check this month’s criticals against KEV, tag your top 20 assets with Mission Prevalence, and score the results against the grid above. I’d bet the Act list is shorter than you think, and the Track list is longer than your current “Critical” backlog would suggest.

Source: CISA, Stakeholder-Specific Vulnerability Categorization Guide (PDF), November 2022.