What is SSVC (Stakeholder-Specific Vulnerability Categorization)?
SSVC is a CISA/Carnegie Mellon decision-tree framework that tells organizations what to actually do about a vulnerability, Track, Track*, Attend, or Act, rather than just scoring how severe or likely-to-be-exploited it is. Because it factors in mission relevance and technical impact, the same vulnerability can produce different decisions at different organizations, and it's meant to be used alongside CVSS and EPSS, not instead of them.
Stakeholder-Specific Vulnerability Categorization (SSVC) is a decision-tree framework, developed by Carnegie Mellon's Software Engineering Institute in collaboration with CISA, that tells an organization what to actually do about a vulnerability, rather than just how severe or how likely to be exploited it is. Instead of producing a numeric score like CVSS or a probability like EPSS, SSVC walks through a handful of decision points and lands on one of four concrete actions: Track, Track*, Attend, or Act.
That's a genuinely different approach from most vulnerability scoring systems, and it exists to solve a specific problem. CVSS tells you how bad a vulnerability could be. EPSS tells you how likely it is to be exploited. Neither one actually tells you what to do next, and for a security team staring at a queue of thousands of open findings, "critical severity, 40% exploitation probability" still leaves the actual decision unmade. SSVC closes that gap by turning the inputs into an explicit action.
How does the SSVC decision tree actually work?
CISA's version of SSVC evaluates a vulnerability against five decision points:
1. Exploitation status is there no evidence of exploitation, a public proof of concept, or active, confirmed exploitation happening right now
2. Automatable: can an attacker reliably exploit this at scale without manual effort, the kind of vulnerability that's suitable for scripting or worm-like spread
3. Technical impact does successful exploitation grant partial access, like a crash or limited data exposure, or total control of the system
4. Mission prevalence how essential is the affected system to the organization's core mission or operations
5. Public well-being impact could exploitation cause harm extending beyond the organization itself, safety, financial, or otherwise
An analyst works through these points in sequence, and the combination of answers routes to one of four outcomes. It's deliberately built as a repeatable process, two analysts evaluating the same vulnerability against the same facts should land on the same decision, which is a meaningfully different design goal than a severity score meant to describe the vulnerability in the abstract.
What do the four SSVC decisions actually mean?
• Track: no action needed right now. The vulnerability gets remediated on your organization's standard patch timeline, and you continue monitoring in case new information changes the picture.
• Track*: similar to Track, but the vulnerability has specific characteristics worth watching more closely, since something about it could escalate.
• Attend: this needs to be remediated sooner than your normal patch cycle. It's not a five-alarm fire, but it shouldn't sit in the standard queue either.
• Act: the highest priority category, reserved for vulnerabilities combining active exploitation, high technical impact, and genuine relevance to your organization's mission. This typically warrants immediate remediation and often a direct conversation with leadership.
The key difference from a severity score is that these are actions, not descriptions. A "critical" CVSS score tells a team the vulnerability is dangerous. An "Act" decision tells them to actually do something about it right now, on this specific system, in this specific context.
Why does the same vulnerability get different SSVC outcomes on different systems?
This is the part that genuinely distinguishes SSVC from CVSS. The same CVE, with the identical CVSS score, can land on Track for one deployment and Act for another, because mission prevalence and technical impact depend entirely on where and how the vulnerable software is actually running. A vulnerable service on an isolated test server carries a very different risk profile than the same vulnerable service running on a system your organization depends on to operate.
This is also why SSVC uses different decision trees for different roles. A supplier deciding when to ship a patch, a deployer deciding when to apply one, and a coordinator managing a public disclosure are answering genuinely different questions, so each role gets its own tailored tree with its own outcome categories, rather than one universal model applied to everyone.
How does SSVC relate to CVSS and EPSS?
These three aren't competing systems, they answer different questions and were never meant to be used in isolation. CVSS measures technical severity, how bad exploitation would be. EPSS estimates likelihood, how probable exploitation is in the next 30 days. SSVC takes both of those (along with organizational context) and converts them into an actual decision. A common, defensible approach is to use CVSS for compliance reporting and severity classification, EPSS to gauge exploitation probability, and SSVC as the layer that turns all of it into what your team does next.
CVSS vs. EPSS vs. SSVC
| Dimension | CVSS | EPSS | SSVC |
|---|---|---|---|
| Output | Numeric score (0-10) | Probability (0-1) | Action decision |
| Question Answered | How severe is it? | How likely is exploitation? | What should we do about it? |
| Context-Aware | Partial | No | Yes, stakeholder and mission specific |
| Same Vulnerability, Different Systems | Same score everywhere | Same score everywhere | Can produce different decisions |
| Best Used For | Severity classification, compliance | Prioritization filtering | Actionable remediation decisions |
FAQ
Is SSVC a replacement for CVSS or EPSS?
No. SSVC is meant to sit on top of severity and likelihood data, not replace it. Many organizations use CVSS for compliance reporting, EPSS to filter for exploitation likelihood, and SSVC to convert that combined picture into an actual remediation decision for a specific system.
Who created SSVC, and who uses it?
SSVC was developed by Carnegie Mellon University's Software Engineering Institute in 2019. CISA adopted and customized its own version in 2020 for federal agencies, state and local governments, and critical infrastructure organizations, and has since encouraged broader adoption, including through its Vulnrichment initiative, which applies SSVC decisions to CVE records at scale.
Why can the same vulnerability get a different SSVC decision at two organizations?
Because SSVC factors in mission prevalence and technical impact specific to how a system is actually deployed, not just the vulnerability itself. A vulnerable service critical to daily operations at one organization might be running on an isolated, low-value system at another, and SSVC is designed to reflect that difference rather than treat every deployment identically.
Is SSVC only used by government agencies?
No. While CISA popularized its own version for federal, state, and critical infrastructure use, SSVC was designed as a general methodology, and any organization can adopt or adapt a decision tree for its own vulnerability management program. CISA explicitly encourages broader adoption.
What's a limitation of SSVC worth knowing about?
Because SSVC is stakeholder-specific by design, its outputs aren't globally comparable the way a universal severity score is meant to be, two organizations can reasonably reach different decisions on the same vulnerability. Small differences in how decision points are answered can also shift the outcome, so consistent, well-documented criteria matter for keeping decisions repeatable across a team.
Conclusion
CVSS and EPSS describe a vulnerability's severity and exploitation likelihood, but neither one tells a team what to actually do next, that's the gap SSVC was built to close with a concrete, repeatable action decision. Saner CVEM factors exploitation status, exposure, and business context into its own risk-based prioritization across endpoints, OS, firmware, and third-party software, turning vulnerability data into the same kind of clear remediation action SSVC is designed to produce.