SSVC: Stakeholder-Specific Vulnerability Categorization, explained

SSVC (Stakeholder-Specific Vulnerability Categorization) is a vulnerability-prioritization methodology built around decision trees rather than a single numeric score. CISA's own description states its purpose is to give organizations "a vulnerability analysis methodology that accounts for a vulnerability's exploitation status, impacts to safety, and prevalence of the affected product." It was created in 2019 by Carnegie Mellon University's Software Engineering Institute (SEI); CISA's page confirms SEI "in collaboration with CISA, created" the methodology that year, and CISA built its own customized decision tree in 2020 for use across the US government, state/local/tribal/territorial (SLTT) governments, and critical infrastructure. The point of SSVC is not to replace a severity score outright, but to answer a different question: given this vulnerability, in this context, what should this organization actually do next?

Why a decision tree instead of a score

SEI's own December 2019 announcement of the methodology states it presents "a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some of the problems with the Common Vulnerability Scoring System (CVSS)." CVSS — see our CVSS v4 vs v3.1 guide — produces one portable severity number regardless of who reads it. SSVC instead starts from the observation that a vendor deciding whether to rush a patch, an organization deciding whether to deploy one, and a coordinator triaging an incoming report are answering three different questions, so SSVC gives each of them its own decision tree with its own inputs and its own categorical outcome, rather than asking all three to interpret the same number differently.

CISA's five decision points

CISA's own SSVC resource page lists the five values that feed its government/critical-infrastructure decision tree:

Decision point	What it captures
Exploitation	Whether active exploitation or public proof-of-concept exploitation is known
Technical Impact	The degree of control or damage the vulnerability enables
Automatable	Whether exploitation can be scripted and scaled without per-target effort
Mission Prevalence	How widespread the affected product is in mission-critical use
Public Well-being Impact	Whether exploitation could cause physical, environmental or financial harm to the public

The broader CERT/CC reference documentation — the methodology's academic and engineering home — documents a wider set of decision points used across its full family of trees, including Safety Impact, System Exposure, Value Density, Mission Impact, and several points specific to suppliers (e.g., Supplier Involvement) and coordinators (e.g., Report Credibility, Public Value Added). Which decision points apply depends on which stakeholder tree — supplier, deployer, or CISA's own adapted tree — is in use.

From decision points to an outcome

SSVC decisions take the shape of simple conditional logic. CERT/CC's own how-to documentation gives this illustrative form:

"IF (Exploitation IS Public PoC) AND (System Exposure IS controlled) AND (Automatable IS no) AND (Human Impact IS medium) THEN priority is scheduled."

CISA's adapted tree for government and critical-infrastructure use resolves to one of four named outcomes, as stated on CISA's SSVC page:

Outcome	CISA's description	Remediation timeline
Track	"The vulnerability does not require action at this time"	Standard
Track*	Warrants "closer monitoring for changes"	Standard
Attend	Requires "attention from the organization's internal, supervisory-level individuals"	Expedited
Act	Requires "attention from the organization's internal, supervisory-level and leadership-level individuals"	As soon as possible

It is worth being precise here: this four-outcome scale (Track / Track* / Attend / Act) is CISA's own 2020 adaptation, not the original SEI methodology's output. The CERT/CC documentation for the general-purpose SEI trees describes a different outcome scale for deployers — immediate, scheduled, out-of-cycle, and defer. An organization adopting "SSVC" should confirm which published tree, and which outcome labels, it is actually implementing before building tooling or SLAs around them.

Where this sits next to CVSS and KEV/EPSS

Device makers and PSIRTs already juggling multiple prioritization signals can treat these as complementary rather than competing: CVSS (our guide) measures intrinsic technical severity; CISA's KEV catalog and FIRST's EPSS (our guide) measure real-world exploitation and the probability of future exploitation; SSVC is the layer that turns any of those signals, plus context like exposure and mission impact, into a concrete action for a specific organization. A mature vulnerability-handling process (see CVD process: ISO/IEC 29147 and 30111) can use CVSS or EPSS as one input into an SSVC-style decision rather than treating any single score as the whole answer.

A workable starting point

1. Pick one tree and stick to its own outcome labels. Decide explicitly whether you are implementing CISA's Track/Track*/Attend/Act tree or a general SEI/CERT-CC deployer tree, and do not blend outcome names from both.
2. Start with the decision points you can already answer reliably — most organizations can assess Technical Impact and Exploitation status from existing advisory data before they can reliably assess Mission Prevalence or Public Well-being Impact across their full install base.
3. Treat SSVC as a layer on top of CVSS/EPSS, not a replacement for them — those scores remain useful inputs into the Technical Impact and Exploitation decision points.
4. Revisit Exploitation status on a cadence, since it is the decision point most likely to change after initial triage as proof-of-concept code or active exploitation emerges.

SoftWSP's PSIRT support can help build an SSVC-style triage workflow on top of real CVE, KEV and EPSS data rather than a single severity number: see PSIRT services.

This guide summarises public CISA and Carnegie Mellon SEI publications; it does not constitute legal or compliance advice.