SSVC Explained: Stakeholder-Specific Vulnerability Categorization
Stakeholder-Specific Vulnerability Categorization (SSVC) is a decision-tree methodology for vulnerability prioritisation that produces an action call rather than a numeric score. Where CVSS measures intrinsic severity, EPSS estimates exploit likelihood, and KEV flags observed exploitation, SSVC walks a small set of decision points and emits one of four action bands: Track, Track-star, Attend, or Act. Developed by CMU SEI and operationalised by CISA, SSVC is the action-call layer above the severity and likelihood signals. For internal vulnerability management teams, AppSec teams, product security teams, GRC owners, and CISOs translating thousands of CVE-tagged findings into a small set of justified remediation decisions, SSVC is often the cleanest path from inventory to action. This guide covers what SSVC is and is not, the four standard decision points and outcome bands, the three role-specific trees (Supplier, Deployer, Coordinator), the CISA Tier-1 simplified tree, the CISA Decider tool, how SSVC composes with CVSS, EPSS, KEV, and reachability evidence, common failure modes, how the evidence reads inside an audit, and a four-week internal-team rollout.
What SSVC Actually Is
SSVC is a decision-tree methodology for vulnerability prioritisation. The stakeholder works through a small set of decision points (typically four to six depending on the variant), each with a small set of possible values, and the tree produces an outcome band that names a recommended action. The methodology is published in the CMU SEI white paper Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization, with subsequent revisions maintained jointly by CMU SEI and CISA.
The motivation is operational. CVSS gives a programme a number, but a number is not an action. A CVSS 8.4 in an internet-facing system that has a public exploit is a different operational problem from a CVSS 8.4 in a sandboxed dev tool with no observed exploitation, even though the score is the same. CVSS-only programmes often degenerate into score-band SLAs (high in 30 days, medium in 90 days, low in 365 days) that ignore exploitation status, mission impact, and the question of whether action is justified at all. SSVC was designed to give the prioritisation decision a documented, defensible, decision-tree narrative.
The methodology is not a scoring system. SSVC does not output a number; it outputs a recommended action band. The bands are intentionally coarse because the goal is collapsing the long tail of CVE-tagged findings into a few action queues a team can actually staff. A programme that uses SSVC well typically reads its open backlog as a small set of Act findings worth pulling staff for, a larger set of Attend findings inside the standard SLA cadence, and a long tail of Track findings that ride the routine patch cadence without out-of-cycle work.
The Four Standard Decision Points
The full Deployer tree (the most widely used variant for internal security teams that operate on someone else's software) uses four standard decision points. Each point has a small ordered set of possible values; the tree walks them top to bottom and the path of values produces the outcome.
Exploitation
Captures observed and disclosed exploitation status. Standard values: None (no public proof of concept and no observed exploitation), Public PoC (a public proof of concept exists but no observed in-the-wild exploitation), and Active (observed in-the-wild exploitation has been reported). KEV listing is a strong signal that pushes Exploitation to Active. The CISA Decider tool also lets the user record exploitation evidence sourced from vendor advisories or threat intelligence feeds.
Automatable
Captures whether an attacker can reliably automate exploitation across the kill chain steps from reconnaissance to weaponisation, delivery, exploitation, and lateral movement. Standard values: Yes (the attacker can automate the full chain end-to-end) and No (some chain step requires manual effort or human judgement). Automatable Yes corresponds to high-volume worm or scanner-driven mass exploitation; Automatable No corresponds to vulnerabilities that demand targeted operator effort.
Technical Impact
Captures the technical effect of successful exploitation. Standard values: Partial (limited control, information disclosure, denial of service of a bounded subsystem) and Total (full control of the system, data exfiltration of arbitrary records, persistent attacker access, ability to pivot). Total technical impact is the strong signal. The decision point reads against the CVSS Base Impact metrics (C, I, A) but the SSVC binarisation collapses C-medium-I-medium-A-high into a single judgement call.
Mission and Well-Being Impact
Captures the consequence to organisational mission and the public well-being if the vulnerability is exploited. Standard values: Low, Medium, High. The judgement reads against the affected asset class: a backup file server with no customer data is Low, a payment-processing path that touches customer funds is Medium or High, a clinical decision-support system in a hospital is High because a successful exploit could cause clinical harm. This is the decision point that requires the most local calibration; it cannot be computed from the CVE record alone.
The Four Outcome Bands
The Deployer tree emits four outcome bands. The bands are an ordered escalation ladder: Track is the lowest action level and Act is the highest. Each band translates into a specific operational discipline.
| Band | Operating discipline | Cadence |
|---|---|---|
| Track | In inventory, monitored, no out-of-cycle remediation justified. | Standard patch cadence; no special review. |
| Track-star | Closer monitoring than Track; on a watch path that may shift up. | Standard cadence plus targeted re-evaluation triggers. |
| Attend | Supervisor attention, remediation plan inside standard SLA window. | Inside the SLA, no out-of-cycle staffing. |
| Act | Out-of-cycle remediation, executive notification, explicit completion target. | Pull staff to close. Hours to days, not the SLA window. |
The Supplier tree (used by software producers reasoning about their own products) emits Defer, Scheduled, Out-of-Cycle, Immediate. The Coordinator triage tree (used by coordinated vulnerability disclosure organisations like CERT/CC and CISA) emits Decline, Track, Track-star, Coordinate. Different stakeholders walk different trees because the decision they are making is genuinely different: a deployer is deciding when to patch, a supplier is deciding when to ship a fix, a coordinator is deciding whether to pursue a disclosure case at all.
SSVC vs CVSS, EPSS, KEV, and Reachability
SSVC is not a replacement for any of the surrounding signals. It is the action-call layer that sits above them. The defensible composition is to consume CVSS for severity, EPSS for likelihood, KEV for observed-exploitation context, reachability for code-path filtering, and SSVC for the action band.
| Signal | What it answers | Relationship to SSVC |
|---|---|---|
| CVSS | Intrinsic severity (base, temporal, environmental). | Input. Feeds Technical Impact decision point. |
| EPSS | 30-day probability of exploitation against the CVE record. | Input. Informs the Exploitation decision point alongside KEV and PoC sightings. |
| KEV | Whether the CVE has been observed exploited in the wild. | Input. KEV listing typically pushes Exploitation to Active. |
| Reachability | Whether the vulnerable code path can be invoked. | Filter. Unreachable findings move to a documented exception and skip SSVC. |
| SSVC | What action the team should take. | Output. Track, Track-star, Attend, Act for deployers. |
Sequence the signals. Reachability filters the candidate set so SSVC is not run against unfiltered noise. CVSS, EPSS, and KEV feed the decision points. SSVC walks the tree and emits the action band. The vulnerability prioritisation framework guide covers the full multi-signal scoring function for programmes that want a numeric ranking alongside the SSVC action band, and the reachability analysis guide covers the upstream filter that should run before SSVC consumes inputs.
The Three Role-Specific Trees
SSVC is not one tree. The methodology recognises that suppliers, deployers, and coordinators are making different decisions, and ships role-specific trees with different decision points and different outcome bands. Picking the right tree for the team is the first calibration step.
Supplier tree
Used by software producers reasoning about whether to ship a fix. Decision points typically include Exploitation, Utility (a measure that combines Automatable with Value Density), Technical Impact, and Public Safety Impact. Outcomes: Defer, Scheduled, Out-of-Cycle, Immediate. A supplier walks the tree to decide when the next patch ships.
Deployer tree
Used by internal security teams operating on someone else's software. Decision points: Exploitation, Automatable, Technical Impact, Mission and Well-Being Impact. Outcomes: Track, Track-star, Attend, Act. This is the tree most enterprise vulnerability management programmes adopt and the tree that the CISA Tier-1 simplified variant is based on.
Coordinator tree
Used by coordinated vulnerability disclosure organisations (CERT/CC, CISA CVD, sector ISACs). The triage tree decides whether the case is in scope at all; the publication tree decides what to publish and when. Outcomes: Decline, Track, Track-star, Coordinate. The Coordinator tree is the variant an internal security team is least likely to use directly but most likely to see referenced in coordinated disclosure timelines.
The CISA Tier-1 Simplified Tree
CISA publishes a Tier-1 simplified Deployer-style tree intended as a starting point for organisations that have not yet calibrated mission-impact taxonomies or automatability heuristics. The Tier-1 tree drops one or two decision points, keeping the action vocabulary identical so a Tier-1 implementation can mature into a fuller Deployer tree without retraining the operating discipline.
The Tier-1 simplification is documented in the CISA SSVC Guide and is the version most often referenced in federal compliance contexts. Federal Civilian Executive Branch agencies operating under CISA-aligned vulnerability management requirements typically adopt Tier-1 first and then move to a fuller Deployer tree as the programme matures. The trade-off is that Tier-1 offers less discrimination between findings inside the same outcome band, so the Attend and Track queues tend to be longer than in a calibrated full-Deployer implementation.
For organisations outside the federal sector, Tier-1 remains a defensible starting point. The benefit is operational: a Tier-1 implementation can be running in two weeks against an existing CVSS-plus-KEV pipeline; a fuller Deployer implementation requires a calibrated mission-impact taxonomy that often takes a quarter to build and another to ratify. Most internal teams that adopt SSVC start at Tier-1 and migrate.
The CISA Decider Tool
CISA Decider is a free open-source web application that walks a vulnerability through the Deployer SSVC tree and emits the recommended action. The user provides the CVE identifier or finding context, answers the decision-point questions, and Decider returns the SSVC outcome band along with the decision path that produced it. Decider is published on GitHub as cisagov/decider; CISA also hosts a public Decider instance. The tool is documented in the CISA SSVC Guide.
Decider is a calculator, not a vulnerability scanner. It does not pull live exploitation data, ingest scanner output, or maintain a finding inventory. Teams typically run Decider as a calibration tool while building an internal SSVC capability, then move the live decision into the vulnerability management platform once the tree is locally configured. Some teams keep Decider in the loop as the official second-opinion check for high-stakes decisions; others retire it after the platform-side implementation matures.
The operating value of Decider is consistency. Two analysts walking the same finding through Decider get the same answer because the tool drives the decision order. A team that adopts Decider as the calibration reference for its own SSVC capability tends to build an implementation that lines up with CISA guidance, which matters for federal-procurement contexts and for any audit conversation that references CISA SSVC literature.
The Six Common Failure Modes
SSVC programmes fail in predictable ways. Most failures stem from treating the decision tree as a scoring system rather than as a documented decision discipline.
1. Treating SSVC as a CVSS replacement
Programmes that retire CVSS in favour of SSVC alone lose the severity anchor that auditors, contracts, and vendor advisories all reference. SSVC consumes CVSS as one of several inputs; it does not replace it. Mitigation: keep CVSS as the technical anchor and treat SSVC as the action-call layer above it.
2. Skipping mission-impact calibration
The Mission and Well-Being Impact decision point is the one that requires local calibration. Programmes that skip it, defaulting to Medium for every finding, collapse the discrimination SSVC was designed to provide. The outcome bands all crowd into Attend and SSVC adds no value. Mitigation: build an asset-class taxonomy with explicit Mission Impact assignments and keep it under change control.
3. Running SSVC against unfiltered noise
Programmes that walk every SCA finding through the SSVC tree burn calibration effort on findings that should never have entered the action queue. Reachability filtering, exception register membership, and asset criticality screens should all run upstream so SSVC consumes a filtered candidate set. Mitigation: sequence the signals correctly. Reachability and exceptions first, SSVC second.
4. Outcome inflation
Without discipline, the Act queue inflates: every team has a reason its finding is critical, supervisors over-classify to avoid blame, and the action-call value erodes. Once Act is permanently 30 percent of open findings, the band is meaningless. Mitigation: cap the share of findings in each band, run periodic calibration reviews, and treat outcome inflation as a programme-health signal rather than as routine variance.
5. Stale decisions
A SSVC decision from last quarter is treated as durable evidence months later, after exploitation status changed (a public PoC dropped, KEV listing changed, vendor advisory updated). The Track finding is still Track on the spreadsheet but should now be Act. Mitigation: re-evaluate the SSVC outcome on a defined cadence (quarterly minimum) and on event triggers (KEV listing, public exploit, vendor advisory update, asset class reclassification).
6. Treating SSVC as a single-team tool
The SSVC tree is a cross-team contract. The vulnerability management team owns the tree, but AppSec consumes the action bands, GRC reads them as audit evidence, and engineering teams staff against them. Programmes that build SSVC inside the VM team without socialising the tree across stakeholders hit calibration friction the moment the first Act finding lands in an engineering backlog. Mitigation: review the tree with AppSec, engineering, and GRC before declaring it operational.
How SSVC Reads Inside an Audit
SSVC is one of the strongest forms of prioritisation evidence available to an internal team because it is documented, repeatable, and decision-tree-based. Auditors read SSVC implementations through their vulnerability-management control lenses.
- ISO 27001:2022 Annex A 8.8 (Management of technical vulnerabilities): expects the entity to evaluate the risk of identified vulnerabilities and to take appropriate measures. A documented SSVC implementation, with a chosen tree variant, calibrated decision points, and per-finding outcome records, reads as a defensible evaluation methodology. Pair with the ISO 27001 framework page for the broader control mapping.
- SOC 2 CC7.1 (System operations: detection of vulnerabilities): the criterion expects implemented procedures for identification of new vulnerabilities, with CC7.2 covering response. An SSVC implementation satisfies the prioritisation half of CC7.2 by providing a documented decision basis for which findings receive out-of-cycle action. Pair with the SOC 2 framework page.
- PCI DSS Requirement 6.3.1 (Identify and rank vulnerabilities): the requirement reads against the ranking methodology. SSVC is a defensible ranking methodology provided the implementation document records which tree is used, how decision points are calibrated, and how SSVC composes with CVSS. Pair with the PCI DSS framework page.
- NIST SP 800-53 Rev. 5 (RA-5 Vulnerability Monitoring and Scanning): the control expects analysis of scan reports and remediation of vulnerabilities within organisation-defined response times. An SSVC outcome band feeding the response-time selection produces the documented basis the control expects. Pair with the NIST SP 800-53 framework page.
- CISA BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities): the directive references SSVC indirectly through the KEV remediation timeline. Federal agencies that adopt the CISA Tier-1 SSVC tree align their internal prioritisation with the CISA-recommended decision discipline. Civilian-sector teams that mirror federal practice pick up the same audit-defensibility.
Programmes that capture SSVC outcomes per finding, pair them with the input evidence (CVSS vector, EPSS percentile, KEV listing date, asset-class mission tag), record the decision date, and re-evaluate on a defined cadence pass these audit reads cleanly. Programmes that mark findings Act in a spreadsheet with no supporting decision-path evidence fail them.
A Four-Week Rollout for Internal Teams
An SSVC programme can move from zero to operating in four weeks for a single business unit using the CISA Tier-1 tree as the starting variant. Larger multi-business-unit programmes should expect to repeat the cycle per unit while keeping the methodology document central.
- Week one: pick the tree and document the methodology. Choose Tier-1 Deployer for the typical internal team. Write a one-page methodology document covering the decision points, the value definitions, the source of inputs (CVSS, EPSS, KEV, internal mission-impact taxonomy), and the re-evaluation cadence. Walk a sample of 50 historical findings through the tree by hand to calibrate against the existing severity and remediation experience.
- Week two: build the asset-class taxonomy. The Mission and Well-Being Impact decision point requires a Low / Medium / High classification per asset class. Work with engineering and business owners to assign every system class to an Impact band. Document the assignment and put it under change control. This is the deliverable that turns the SSVC tree from theoretical to operational.
- Week three: wire the lifecycle. Capture SSVC outcome as a finding attribute alongside CVSS, EPSS, KEV. Update the SLA policy so SSVC outcome maps to a remediation deadline (Track inherits the standard cadence, Attend inherits the SLA window, Act triggers out-of-cycle staffing, Track-star carries an explicit watch trigger). Build the leadership dashboard view that splits open findings by SSVC outcome.
- Week four: calibrate and socialise. Run a calibration meeting with AppSec, engineering, and GRC. Walk through five recent Act findings, five Attend, five Track. Record disagreements and tune the decision-point definitions. Add SSVC outcome to the monthly programme review, the quarterly leadership read, and the audit evidence pack. Capture the framework mapping (ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.3.1, NIST 800-53 RA-5) in the methodology document.
Where SSVC Sits in the Wider Security Org
SSVC is one discipline inside a wider internal security organisation. It sits next to the daily operational discipline of the vulnerability management team, the engineering-side AppSec function, the GRC owner's evidence cadence, and the leadership reporting cadence the CISO produces.
For the find-track-fix-verify operator function, SSVC is the natural pairing with SecPortal for vulnerability management teams. For the AppSec function that triages SCA and SAST output for engineering ownership, SecPortal for AppSec teams covers the upstream pipeline. For internal security teams sponsoring the programme, SecPortal for internal security teams covers the cross-functional operating shape. For the CISO sponsoring the action calibration and reading the band split each quarter, SecPortal for CISOs covers how SSVC outcomes roll up into leadership reporting. For the GRC function citing SSVC as audit evidence, SecPortal for GRC and compliance teams covers the framework-mapped evidence pack.
Pair SSVC with the adjacent reading. The vulnerability prioritisation framework guide covers the multi-signal scoring function SSVC sits above. The CVSS scoring explainer covers the severity input to the Technical Impact decision point. The EPSS scoring explainer covers the likelihood input to the Exploitation decision point. The CISA KEV catalog guide covers the observed-exploitation signal that often pushes Exploitation to Active. The reachability analysis guide covers the upstream filter that should run before SSVC consumes inputs. The severity calibration research covers how CVSS, SSVC, and contextual risk compose for finding-level reads. The vulnerability management programme maturity model shows where SSVC adoption sits on the capability ladder.
Run SSVC-Aligned Vulnerability Management on a Single Record
SSVC programmes succeed or fail on the recordkeeping. The chosen tree, the decision-point inputs per finding, the resulting outcome band, the date of the decision, the re-evaluation trigger, the asset-class mission tag, and the framework mapping all need to live on the same record so audit reads collapse into a query rather than into a multi-tool reconciliation across spreadsheets, ticketing systems, and ad-hoc decision logs.
SecPortal is built around a single engagement record: findings management with CVSS 3.1 vector parsing and per-finding metadata for the SSVC outcome band, decision-point inputs, and re-evaluation trigger, document management for the methodology document and the asset-class taxonomy under change control, the activity log for the timestamped chain of state changes per finding (which analyst recorded the outcome, when the outcome was last re-evaluated, what changed), compliance tracking with ISO 27001, SOC 2, PCI DSS, and NIST framework mappings so the SSVC evidence reads cleanly against the auditor's control list, team management with role-based access control so the methodology owner, the per-finding analyst, and the GRC reader each have the right scope, and AI report generation for the leadership read of the SSVC outcome split.
None of these features run the SSVC decision tree as an internal scoring engine: the decision is the team's methodology, captured as policy. What SecPortal does is keep the chosen tree, the per-finding decision inputs, the outcome band, the lifecycle, the framework mapping, and the audit trail on the same record so the SSVC implementation is reconcilable for an internal reviewer or an external auditor without leaving the workspace.
Scope and Limitations
This guide describes the operating shape of SSVC as it is consumed by enterprise internal vulnerability management teams. The CMU SEI methodology continues to evolve: revisions to the published trees, refinements to decision-point definitions, and updates to the CISA Decider implementation should be tracked against the CMU SEI repository and the CISA SSVC documentation. Specific federal compliance contexts that reference SSVC (BOD 22-01 timing, BOD 23-01 asset visibility, sector-specific guidance) should be read against current CISA publications.
SSVC is a decision discipline, not a scoring system, and it does not replace CVSS, EPSS, KEV, reachability analysis, or any other prioritisation input. The value of SSVC is in providing a documented, repeatable, action-call layer above those signals. Programmes that adopt SSVC as a complement to existing severity and likelihood signals see durable operating value. Programmes that adopt SSVC as a single decision rule without the supporting governance, methodology document, and asset-class taxonomy tend to collapse into a coarse rule-of-thumb that adds little over CVSS-only banding.
Run SSVC-aligned vulnerability management on SecPortal
Stand up the engagement record in under two minutes. Free plan available, no credit card required.