SSVC replaces the number with a decision. The four typical tree outputs are 'immediate', 'out-of-cycle', 'scheduled' and 'deferred'. Each one translates to a concrete remediation action with SLA, not to a theoretical severity label.
What SSVC is
SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision framework developed by CISA and Carnegie Mellon's CERT/CC that prioritises vulnerabilities through decision trees tailored to the decision-maker. Instead of returning a number, as CVSS or EPSS do, SSVC responds with an action: act immediately, out of cycle, scheduled or deferred. The decision is built from variables such as exploitation status, technical impact, prevalence of the affected asset and system mission, and the specific tree depends on who is deciding: an agency managing critical infrastructure does not face the same problem as a software vendor receiving a vulnerability report.
Why it matters
Any experienced security leader has seen how isolated scores (a CVSS 9.8 without context, an EPSS value without asset information) produce lukewarm or wrong decisions. SSVC tackles that problem directly: instead of a number, it offers an explicit tree that forces the right questions in the right order and justifies every decision. That makes conversations with leadership easier, audits the criteria applied and, above all, allows the list of urgent vulnerabilities to stop being endless. For programmes aligned with NIS2, DORA or ISO 27001, having a traceable decision framework is one of the best pieces of evidence of risk-based management.
Key points
Different trees exist for different roles: supplier (what to do with a vulnerability reported in my product), deployer (how to prioritise patches in my estate) and coordinator (how to handle disclosures affecting several vendors). Applying the wrong tree turns the framework into noise.
The deployer tree (the one most used by corporate security teams) typically asks: is there public exploitation? Is the asset reachable from outside my control perimeter? Is technical impact total or partial? Is the mission it supports critical? Those four questions resolve most findings without endless CVSS debates.
SSVC does not compete with CVSS or EPSS: it consumes them. CVSS provides signal on technical impact, EPSS on exploitation probability, and SSVC integrates them into an actionable decision together with asset context and mission.
The strength of the framework is traceability. Every decision is documented with the tree's answers, which turns prioritisation into an auditable, reviewable artefact rather than an opinion.
SSVC requires the organisation to know its own context: which assets are critical, what is exposed to the internet, what mission each system supports. Without that prior inventory and classification work, the tree responds with generics and loses its value.
Example: SSVC tree applied to a SaaS provider with personal data
A SaaS company is notified of a new critical vulnerability in one of its technology stack components. Without a framework, the team gets into debate: CVSS is 9.1, there is no official patch yet, no confirmed public exploit, the component runs in thousands of installations globally, and the organisation uses it in an internet-facing service handling personal data. With SSVC the debate disappears. The deployer tree walks through four questions: is there confirmed public exploitation (KEV)? No. Is a public exploit available? Yes, in repositories. Is the affected asset reachable from outside? Yes, it is a public service. Is the supported mission critical to the business? Yes, it handles personal data.
The tree output is 'out-of-cycle': mitigation or patch within 72 hours, with notification to the CISO and the product owner. The team applies a WAF rule as temporary containment, schedules the version change once the official patch is published and documents the whole decision chain. That documentation — tree answers, deadline, containment, definitive patch — serves as evidence for the next audit and as a reference for the next similar case. The conversation with leadership shifts from 'we have a CVSS 9.1' to 'we have classified the case as out-of-cycle and contained it within 24 hours'.
Common mistakes
- Treating SSVC as a replacement for CVSS or EPSS. SSVC integrates those metrics; it does not replace them. CVSS is still needed for contracts and policies, EPSS for exploitation probability. SSVC adds the decision.
- Applying the wrong tree. The supplier, deployer and coordinator trees answer different questions. A corporate team using the supplier tree reaches absurd conclusions because the variables do not match its role.
- Skipping asset inventory and mission classification. SSVC needs to answer 'what asset is this' and 'what mission does it support'. Without prior classification, the tree responds with generic values and loses the value it adds.
- Documenting only the output, not the tree's answers. SSVC's strength is the traceability of every decision: why 'yes' or 'no' was answered at each node. If only the final label is saved, the reasoning is lost and the decision can only be reviewed from memory.
- Expecting SSVC to be operated by a single person. The most useful approach is to define default answers (based on asset and mission) and review them as a team when a case falls outside the norm. Keeping the decision in a single head turns the framework into a bottleneck.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
Does SSVC replace CVSS?
No. CVSS remains the standard technical severity metric and appears in contracts, policies and tools. SSVC turns CVSS, EPSS and asset context into a decision to act. Serious organisations usually keep CVSS as a descriptive metric and apply SSVC as the prioritisation framework.
What is needed to start applying SSVC?
Three things: the tree that matches the role (typically the deployer tree), an asset inventory with mission classification and a process to document each decision. You can start with a well-structured spreadsheet; modern vulnerability management platforms already include the tree as a configurable workflow.
Is SSVC compatible with NIS2, DORA or ISO 27001?
Yes. SSVC produces exactly the type of evidence these regulations require: risk-based prioritisation, written criteria, traceability of every decision and documented remediation deadlines. When trees are mapped to the corresponding regulatory control, SSVC becomes a solid source of continuous evidence.
Can SSVC be combined with CTEM?
Yes, and they reinforce each other. CTEM defines the cycle (scoping, discovery, prioritisation, validation, mobilisation) and SSVC provides the decision framework applied in the prioritisation phase. Subsequent validation confirms whether the tree's decisions hold up in practice and helps refine the default answers.