SSVC Vulnerability Decisions: A Practical Guide

Choose the stakeholder and model before answering questions

SSVC vulnerability decision trees do not produce a universal severity score. They map defined evidence and context to an action for a particular stakeholder. A software supplier deciding when to create a fix, a deployer deciding when to install it, and a coordinator deciding whether to publish are solving different problems.

The current CERT/CC SSVC overview provides distinct models for those roles. Its deployer example asks about exploitation, system exposure, automatable exploitation, and human impact, then returns Defer, Scheduled, Out-of-Cycle, or Immediate. The CISA SSVC guide is a customized model with Track, Track*, Attend, and Act outcomes and different decision points.

Record the model owner, model version, stakeholder, product or deployment, and evaluation time. Saying only “SSVC says Act” hides the logic required to reproduce the decision.

Create a decision record that another analyst can reproduce

Store each decision-point value beside its evidence, source, analyst, confidence, and observation time. Keep the vulnerability identifier separate from the affected product, version, asset group, exposure, and mission context. One CVE can require several deployment decisions.

This is an authored record, not an official SSVC interchange example:

{"vulnerability":"CVE-20XX-1234","model":"certcc-deployer","model_version":"2.x",
 "scope":"internet-facing-payment-api","evaluated_at":"2026-11-10T16:42:00Z",
 "inputs":{"exploitation":"public-poc","system_exposure":"open",
 "automatable":"yes","human_impact":"high"},"outcome":"immediate",
 "evidence":[{"input":"exploitation","source":"vendor-advisory","observed_at":"2026-11-10"}],
 "owner":"payments-platform","review_after":"2026-11-11T16:42:00Z"}

Pin the actual model artifact or version used. SSVC decision points and models evolve; an unversioned label cannot explain a historical outcome.

Answer each decision point with scoped evidence

In the CERT/CC deployer decision model, exploitation distinguishes none, public proof of concept, and active exploitation. System exposure is deployment-specific: small, controlled, or open. Automatable asks whether an attacker can reliably automate reconnaissance through exploitation. Human impact combines mission and safety consequences.

Do not infer “active exploitation” from a proof of concept, or “open” from a product’s default configuration when the assessed deployment is isolated. Conversely, a compensating control supports “controlled” only when it reliably interrupts exploitation; the existence of a firewall is not evidence by itself.

Use CVSS, EPSS, and KEV as inputs with distinct meanings, not interchangeable votes. Document uncertainty and assign a review trigger rather than filling unknowns with convenient defaults.

Translate the outcome into owned operational work

Define each outcome locally before rollout: accountable owner, response deadline, permitted mitigations, approval authority, communication path, and evidence needed for closure. In the deployer example, Immediate means the highest urgency, but it still does not dictate a reckless patch to an unsafe production system.

Choose among remediation, mitigation, isolation, service retirement, or a documented acceptance using the actual operational risk. Use VEX documents to support product exploitability claims, but verify whether the claim matches your component version, configuration, and reachable code path.

Measure time from decision to containment and verified remediation, overdue work by outcome, decisions missing evidence, and outcomes reversed after review. Counting “high-priority CVEs” alone does not show whether the process reduced exposure.

Re-evaluate when evidence or deployment context changes

Exploitation evidence can move from none to public proof of concept to active use. An internal system can become internet-facing, a mitigation can fail, a vulnerable feature can be enabled, or a mission owner can discover greater human impact. These are decision changes, not mere record updates.

Trigger reassessment on new advisories, exploitation intelligence, KEV addition, configuration or exposure change, asset criticality change, mitigation failure, and model revision. Preserve the prior record and reason for the transition so auditors can distinguish a rational update from inconsistent analysis.

The CVE lifecycle also changes facts such as affected versions and references. Set maximum review ages for mutable inputs; an old “no exploitation” assessment is not evidence that exploitation remains absent.

Pilot one decision path before automating the queue

Next step: select one real vulnerability affecting two meaningfully different asset groups. Choose and version the stakeholder model, gather cited evidence, have an analyst and service owner answer every decision point independently, resolve disagreements, and record both outcomes and operational actions.

Compare the result with your existing CVSS threshold, EPSS signal, KEV obligation, vendor guidance, and business criticality. The goal is not to force agreement; it is to discover which evidence and ownership gaps a simple score concealed.

Use a synthetic vulnerability for tabletop training and workflow testing. Do not describe a simulation as live intelligence, and do not automate enforcement until human reviews show that inputs, branching logic, exceptions, and re-evaluation triggers behave consistently.