SSVC Explained: From Vulnerability Scores to Decisions (Track, Attend, Act)
A CVSS score answers one question: how bad could this vulnerability be? It does not tell you what to do on Monday morning. A 9.8 on a lab server and a 9.8 on your customer portal get the same number, and your team still has to decide which one gets an emergency change window.
SSVC, short for Stakeholder-Specific Vulnerability Categorization, starts from the opposite end. Instead of producing a number, it produces a decision: Track, Track*, Attend or Act. This article explains how the CISA version of SSVC works, why the same CVE can land on different outcomes in different organizations, and how to start using it without rebuilding your vulnerability program.
Where SSVC comes from
SSVC was created in 2019 by Carnegie Mellon University's Software Engineering Institute (SEI). In 2020 CISA worked with SEI to build its own decision tree, and in November 2022 it published the CISA SSVC Guide, which describes the tree that CISA uses to communicate patching priorities.
The guide is aimed first at U.S. government agencies and critical infrastructure, but it is explicit that "any individual or organization can use SSVC to enhance their own vulnerability management practices." And its goal is stated plainly: to prioritize remediation "based on the impact exploitation would have to the particular organization(s)."
That last part is the key idea. CVSS rates the vulnerability. SSVC rates the vulnerability in your environment.
The four outcomes
Every path through the CISA tree ends in one of four decisions:
- Track: the vulnerability does not require action at this time. Keep monitoring and remediate within your standard update timelines.
- Track*: the vulnerability has specific characteristics that may require closer monitoring for changes. Still remediated within standard timelines.
- Attend: requires attention from supervisory-level staff. CISA recommends remediating sooner than standard timelines.
- Act: requires attention from supervisory and leadership-level staff. CISA recommends remediating as soon as possible.
Notice what these outcomes describe: who needs to know, and how fast to move. That is what a security team actually has to decide, and it maps directly onto the remediation SLAs most organizations already have. If you have not defined those yet, start with our guide on remediation SLAs and MTTR.
The decision points
The CISA tree walks through four questions, in this order.
1. Exploitation
What is the current state of exploitation?
- None: no evidence of active exploitation and no public proof of concept.
- Public PoC: a typical public proof of concept exists, for example in Metasploit or Exploit-DB.
- Active: shared, observable and reliable evidence that threat actors have used the exploit in the wild.
The CISA Known Exploited Vulnerabilities catalog is the most common evidence for the Active value.
2. Automatable
Can an attacker reliably automate steps 1 to 4 of the kill chain (reconnaissance, weaponization, delivery and exploitation) for this vulnerability? Yes or No. This is the question that separates a flaw that can be sprayed across the internet by a script from one that needs a patient, hands-on attacker.
3. Technical impact
If exploited, how much control does the attacker get over the vulnerable software?
- Partial: limited control over, or information exposure about, the behavior of the software.
- Total: total control over the behavior of the software.
4. Mission and well-being
This is the only question that the vulnerability cannot answer for you. It combines two inputs:
- Mission prevalence: is the affected component Minimal, does it Support your mission essential functions, or is it Essential to at least one of them?
- Public well-being impact: Minimal, Material or Irreversible harm (physical, environmental, financial or psychological).
Together they produce Low, Medium or High. In the CISA table, a component that is Essential to the mission maps to High regardless of the well-being value.
Same CVE, different decision
Here is where SSVC earns its keep. These paths all come straight from the decision table in the CISA guide:
| Exploitation | Automatable | Technical impact | Mission & well-being | Decision |
|---|---|---|---|---|
| Active | Yes | Total | High | Act |
| Active | Yes | Total | Low | Attend |
| None | Yes | Total | High | Attend |
| Active | No | Partial | Low | Track |
Two observations that surprise most teams:
- "Exploited" does not automatically mean "drop everything." An actively exploited flaw that is not automatable, has partial impact and sits on a low-mission system lands on Track.
- Your context can move a vulnerability by a full level. The same exploited, automatable, total-impact flaw is Act on an essential system and Attend on a minimal one.
This is the same intuition behind internet exposure and EPSS: the score of a vulnerability is not the risk to your business.
You don't have to answer every question yourself
The first three decision points describe the vulnerability, so they are the same for everyone. Through its Vulnrichment program, CISA adds SSVC decision points (Exploitation, Automatable and Technical Impact) to CVE records in its Authorized Data Publisher (ADP) container, and publishes the data in the public cisagov/vulnrichment repository on GitHub.
That leaves your team with the question only you can answer: how important is this asset to the mission? In practice, this means the real work of SSVC is not scoring CVEs. It is maintaining an asset inventory with business context: which systems are essential, which support them and which are minimal.
How to start using SSVC
- Classify your assets first. Tag systems as Essential, Support or Minimal. Start with the obvious ones: customer-facing services, identity, payments and anything regulated.
- Map the outcomes to your SLAs. For example: Act means an emergency change and leadership notification; Attend means remediation ahead of the normal cycle; Track and Track* follow the standard cycle. Write the mapping down so nobody debates it during an incident.
- Automate the inputs. Pull exploitation status from KEV and threat intelligence, the vulnerability-level decision points from CISA's enrichment where available, and mission context from your asset inventory.
- Re-evaluate when facts change. A Track can become Act overnight when a public PoC turns into active exploitation. Track* exists precisely to flag the ones worth watching.
- Keep CVSS, but as an input. CVSS still helps estimate technical severity. It just should not be the final word.
Frequently asked questions
Does SSVC replace CVSS? No. SSVC is a decision framework, and CVSS is a severity score. CVSS, EPSS and KEV can all serve as evidence that feeds an SSVC-style decision.
Is the CISA tree the only version? No. SSVC started at SEI as a broader methodology, and CISA built its own tree on top of it in 2020. The CISA tree is a practical place to start because CISA publishes it with a guide and uses it for its own messaging.
What if we don't know the mission value of an asset? That is the most common gap, and it is worth fixing on its own. Without business context, every prioritization method falls back to treating every system the same.
How priorIQ.ai helps
ScannerIQ enriches host findings with NVD, CISA KEV and EPSS, and CloudIQ classifies which cloud resources are actually exposed to the Internet. PriorIQ Core combines those signals with CVSS, exploit availability, active threats and your business context, the same kind of evidence that SSVC asks for, groups findings into remediation actions and pushes them into Jira, ServiceNow or Freshservice. The result is a short queue of decisions instead of a long list of scores. Request a demo.