SSVC vs CVSS: decision tree vs score

SSVC vs CVSS: which one should a small team use to rank test findings?

CVSS gives a severity number, SSVC gives an action. A small team holding scan and penetration test findings needs to decide what gets fixed now, and the two methods answer different questions. CVSS rates how serious a flaw is in the abstract, on a numeric scale, while SSVC walks a decision tree built from exploitation status, technical impact, automatability, mission prevalence and public well-being impact, and ends in an outcome: Track, Track*, Attend or Act. The Track* outcome is the one that sits between routine handling and leadership attention, so teams should read the full tree rather than assume four buckets map onto four priorities.

CVSS suits a team that needs a common severity vocabulary across tools, vendors and reports, or that must record a severity for every finding. Its v4.0 specification says the numerical scores indicate severity relative to other vulnerabilities, and it recommends adding Threat and Environmental values for more meaningful results, though these are optional. SSVC suits a team with limited staff that must decide quickly which findings interrupt work. A score threshold such as "fix everything above 9.0" ignores whether anyone is exploiting the flaw or whether the affected system matters to the business. An SSVC outcome asks those questions directly, which is why it often ranks a moderate score on an exposed, actively exploited, internet-facing system above a high score on an isolated lab host. Confirm with your own asset inventory whether you can answer the mission and public well-being questions honestly before adopting it.

CVSS still has a place inside an SSVC process. Its base score can record the severity of each finding for audit trails, and its Threat and Environmental values can feed the tree's inputs when your evidence supports them. Regulatory duties may also require a score. PCI DSS requirement 11.3.1.1 requires vulnerabilities not ranked high-risk or critical to be addressed according to a targeted risk analysis, so a team in scope should check how its assessor expects scores and risk analysis to coexist. The practical step is to record both: the CVSS version and score for the severity record, and the SSVC outcome and decision points for the remediation decision, then review the mapping with your assessor and vulnerability management policy owner.

How SSVC and CVSS compare on output, inputs and fit

This table sets SSVC against CVSS on the question each answers, the type of output, its origin, its inputs and its fit for a small team. Read it to see whether you need a severity rank, a response action, or both. The main takeaway is that CVSS supplies a score that can feed SSVC, while SSVC supplies the action the team takes.

Comparison point	SSVC	CVSS v4.0
Question it answers	What should we do about this vulnerability now: track, attend or act?	How severe is this vulnerability relative to others?
Output type	One of four outcomes: Track, Track*, Attend or Act	A numerical score indicating severity relative to other vulnerabilities
Creator and date	Carnegie Mellon University's Software Engineering Institute with CISA, 2019; CISA-customized decision tree from 2020	Published by FIRST as the CVSS v4.0 specification
Decision points or metrics	Exploitation, technical impact, automatability, mission prevalence and public well-being impact	Base metrics, with Threat and Environmental values recommended to add context
Handling of exploitation status	Exploitation is a direct decision point in the tree	Not a core score input; consumers add it through the Threat values, which are optional
Handling of mission and public well-being impact	Built into the tree as decision points	Outside CVSS scope; the specification says factors such as regulatory requirements or breach losses are not covered
Who it suits best	Teams that need a clear action per vulnerability and leadership involvement rules for the highest tier	Teams that need a comparable severity number across a large set of findings and their own prioritization on top
Effort to adopt	Confirm with CISA's published material how much tailoring your decision tree needs for your environment	Confirm with your scanner or testing vendor which CVSS version and metric groups its reports populate
Staffing and tooling	Confirm who in your team makes the decision points and how the outcomes are recorded in your ticketing process	Confirm whether your tooling supports Threat and Environmental fields, since without them the score stays at the base level

What a CVSS score catches and misses, and what SSVC outcomes catch and miss

A CVSS score ranks how severe a flaw is in the abstract, while an SSVC outcome answers what to do next for a specific deployment. The cards below set out where each approach helps a small team and where each leaves a gap that someone must fill by hand.

CVSS orders findings by severity

A CVSS score gives every finding a number that can be sorted, which makes it useful for a long backlog from a scanner or penetration test. The ordering is only as good as the scale behind it, so it helps most when the team needs one consistent language across many teams and tools. Check that your scanner reports the CVSS version your policy names, because scores from different versions are not interchangeable.

Base scores lack local context

A Base score describes the vulnerability itself and does not know whether the affected system is internet-facing, holds regulated data, or sits behind compensating controls. The CVSS v4.0 specification recommends adding Threat and Environmental values for more meaningful results, but those fields are optional and are often left blank. Before you act on a score alone, confirm whether your tooling fills in those values for your assets.

Regulatory and breach impact sit outside CVSS

The CVSS v4.0 specification states that factors such as regulatory requirements or breach losses are outside its scope. A finding on a system that a supervisor or contract treats as critical can score modestly and still need faster action. An SSVC tree does not capture regulatory duty as such either, so the team must record that obligation in its own remediation policy.

SSVC surfaces active exploitation

SSVC asks about exploitation status as a decision point, so a flaw that attackers are using moves toward immediate action even when its base severity looks ordinary. This matters most for internet-exposed services where exploit activity arrives quickly after disclosure. Confirm that the exploitation input is sourced from a current feed, since a stale answer routes the finding to the wrong outcome.

SSVC weighs public well-being impact

The public well-being decision point lets SSVC raise a finding when a compromise could harm people outside the organization, which a score built on technical properties does not express. Operators of healthcare, utility or public-facing services should answer this question deliberately rather than default to the lowest impact. Record who answered it and why, so the outcome can be defended in an audit.

Four outcomes are coarser than scores

SSVC ends in four outcomes, Track, Track*, Attend and Act, so it cannot rank two Attend findings against each other the way a numeric score can. A small team may find that coarseness useful, since the decision is clear, but it needs a tie-breaking rule for queues that fill up. Decide in advance how Attend items are ordered, for example by asset criticality, so the queue stays predictable.

When a small team is better served by SSVC outcomes than by score thresholds

A small security or platform team that receives more scanner and test findings than it can review one by one often gains the most from SSVC. A score threshold such as "fix everything above a set CVSS number" still leaves the team deciding, ticket by ticket, what the number means for its own systems. SSVC asks a short series of questions about exploitation, technical impact, automatability and mission impact, and returns an outcome that tells the team whether to track a finding, attend to it, or act on it now. The result is a queue sorted by action rather than by a score the team must reinterpret.

Decisions to make first: Who answers the exploitation and mission questions, and where those answers come from (vendor advisories, asset owners, internal inventory).
Record the outcome: Store the decision point answers with each finding so a reviewer can see why it landed in Track, Attend or Act.
Keep CVSS as an input: Use the CVSS base data the scanner already provides where it helps answer the technical impact question.
Avoid over-engineering: A spreadsheet or ticket template can hold the decision points if no tooling is available.

What would change the choice: a team with dedicated analysts and a stable asset inventory may find a threshold simpler to automate, so confirm the workload before committing.

What PCI DSS asks for lower-severity findings and how it relates to scoring

PCI DSS requirement 11.3.1.1 does not let a score settle the question for vulnerabilities that are not ranked high-risk or critical. Those findings must be addressed according to a targeted risk analysis performed under requirement 12.3.1, so the record you keep has to show the reasoning behind the decision, not only the number. For a small team, this means the file for each lower-ranked finding should state the risk considered, who decided, the chosen response and the date of review. A CVSS base score on its own rarely covers all of that, which is why the scoring question and the risk analysis question need to be answered separately.

SSVC is a decision method, and the supplied PCI DSS material does not name it as an acceptable form of targeted risk analysis. Before you adopt SSVC outcomes such as Track, Attend or Act as the basis for lower-severity findings, ask your Qualified Security Assessor or internal assessor whether an SSVC-based record satisfies requirement 12.3.1 in your environment. Ask them to review a sample record, including the decision points you answered, the evidence behind each answer and who approved the outcome. Do not assume that a method built for a different purpose will be accepted without that conversation.

CVSS v4.0 states that Threat and Environmental values are not required but are highly recommended for more meaningful results, so a base score used alone is a weak input to any risk analysis. Whatever method you choose, document which CVSS values you used and why. Frameworks outside PCI DSS may set different expectations for how findings are ranked and recorded, so confirm the requirements of each framework that applies to your organization before you reuse one record across several audits.

How to combine CVSS and SSVC in one remediation policy

This sequence gives a small team one repeatable path from a raw CVSS score to a documented SSVC outcome and a remediation expectation. Each finding ends with a traceable record that shows why it was prioritized the way it was.

Record the CVSS version and vector
The analyst who logs the finding records the CVSS version, the full vector string and the base score exactly as the scanner or penetration tester reports them. Note the version explicitly, because CVSS v3.1 and CVSS v4.0 produce different numbers from different metric sets and cannot be compared directly. The step is done when every finding in the ticket shows a version, a vector and a base score that another reviewer can recalculate.
Add Threat and Environmental values with justification
The vulnerability owner adds Threat and Environmental values only where the team can justify them from evidence, such as a known exploit in use, the asset's role in a critical service, or compensating controls that have been tested. The CVSS v4.0 specification treats these values as optional but highly recommended, and it notes that regulatory requirements and breach losses fall outside CVSS scope, so those belong in the SSVC or policy layer. The step is done when each adjusted value has a one-line reason attached to it.
Answer each SSVC decision point with evidence
A triage lead answers the SSVC decision points for exploitation, technical impact, automatability, mission prevalence and public well-being impact, using the source named in each answer such as a threat feed, asset inventory or system owner statement. Where the team lacks evidence for a point, it records the answer as unknown and says what would resolve it, rather than guessing. The step is done when every decision point has an answer and a source reference.
Assign the SSVC outcome
Walk the decision tree with the recorded answers to reach one of its outcomes, which are Track, Track*, Attend or Act. Keep the CVSS base score on the same record so readers can see where the score and the outcome agree or diverge. The step is done when the finding carries one outcome, the decision path that produced it, and the tool or worksheet version used to walk the tree.
Map each outcome to the team's remediation expectation
The governance owner, who is usually a CISO or security risk lead, sets what each outcome means in the team's own policy, including the remediation window and who must be informed. Timelines are the team's to set, based on its risk appetite, change windows and contractual or regulatory duties, and they should not be copied from a vendor default. Confirm the outcome-to-timeline mapping with that owner before publishing it, and record the approval date and version of the policy. The step is done when the mapping is written, approved and linked from each finding type.
Document deviations from the standard expectation
When a finding is handled faster or slower than its outcome's standard expectation, the owner records the deviation, the reason, the approver and the compensating controls in place. Deviations that repeat across findings usually signal that the policy mapping or the scoring inputs need review. The step is done when every deviation has a named approver and an expiry or review point, so exceptions do not silently become the norm.
Review the mapping on a set cycle
The governance owner reviews a sample of closed findings against the policy, checking that CVSS inputs were justified, decision points were answered with evidence and deviations were approved. Changes to the outcome mapping or the decision points are versioned and applied to open findings only with a recorded decision. The step is done when the review produces a dated record of findings, decisions and any policy edits, which an auditor or assessor can trace from the original scanner output to the remediation.

What drives the effort of running SSVC and CVSS in practice

Running either scoring approach is mostly an internal staffing question, not a tool purchase. The cards below cover the inputs each method depends on, who supplies them, and which costs are one time versus recurring, so you can ask the right questions in a quote.

Asset and exposure inventory

SSVC asks about mission prevalence and public well-being impact, so every finding needs an owner who can say which systems it touches and what those systems do for the business. Internal asset owners usually supply this, and building the first version is a one-time effort, while keeping it current is recurring work for the platform or IT team. CVSS Environmental metrics depend on the same inventory, so the inventory cost is shared. Ask whether your CMDB already records business service mapping and who maintains it.

Findings volume per cycle

The number of findings in each scan or test cycle sets how much analyst time each decision takes. A large backlog of low-value findings can overwhelm a small team even when each individual decision is quick. Internal staff triage the findings, and scanner licenses or penetration testing fees may drive the raw count. Check how many findings your last two cycles produced, how many were duplicates, and whether deduplication happens in the scanner or in your ticketing system.

Decision maker time on Attend and Act

Attend and Act outcomes pull leadership into the decision, which is where SSVC's effort concentrates. Each escalated item needs a named approver, a short briefing, and a recorded decision. Executive time is the most expensive input and is recurring for every cycle. Agree in advance which roles can approve Attend items and which items must reach leadership, so the workload stays bounded.

Evidence for exploitation status

SSVC's exploitation decision point requires you to record whether a vulnerability is unproven, in proof-of-concept use, or actively exploited. Gathering that evidence means watching advisories, vendor bulletins, and threat feeds, and recording the source and date for each call. Analysts or a threat intelligence function carry this work, and feed subscriptions may be recurring licenses. Ask your team who owns exploitation status updates and how often they are checked.

Tooling that records vectors and outcomes

CVSS v4.0 scores depend on base vectors that must be captured consistently, and SSVC decisions need a recorded path through the tree to be auditable. A ticketing or vulnerability management tool can store both, but configuring fields and workflows is one-time setup work, and licenses renew on a recurring basis. Confirm which vector string and decision fields your tool stores, and whether you can export them for review.

Documentation an assessor reviews

Assessors reviewing a vulnerability management program look for a written policy, the scoring method in use, and records showing that decisions followed it. Writing the policy and decision procedure is a one-time task, but keeping records current is recurring. Internal compliance staff or consultants usually prepare this, and the work grows with the number of exceptions you grant. Ask your assessor which evidence format they expect before you design the records.

Questions teams ask before choosing SSVC, CVSS or outside help

Does SSVC replace CVSS?

No. SSVC does not replace CVSS, and the two methods answer different questions. CVSS produces a numerical score that indicates severity relative to other vulnerabilities, and the CVSS v4.0 specification recommends adding Threat and Environmental values to make that score more meaningful. SSVC is a decision tree that ends in an action: Track, Track*, Attend or Act. CISA's SSVC material lists exploitation status, technical impact, automatability, mission prevalence and public well-being impact as decision points, and CVSS data can feed some of those inputs. Many teams keep CVSS as the shared severity language and use SSVC outcomes to decide what happens next. Confirm with your own policy owner which output your SLAs will reference.

Can a small team run SSVC without outside help?

Often yes, provided the team can agree on the inputs. The decision tree is published by CISA, so the method itself has no license cost. The harder part is making consistent decisions: someone must define what counts as exploitation evidence, how automatable a flaw is in your environment, and what your mission and public well-being impacts mean for each system. A small team with a clear asset inventory and one accountable owner can start in-house. Teams without a documented inventory or without a leadership path for Act decisions usually benefit from outside help on the design. Ask any partner to state which parts they will hand over for your staff to run.

What does SSVC need from internal staff?

SSVC needs decision owners more than tooling. Internal staff must supply asset context (which systems are mission critical, which hold regulated data, which are internet facing), a named approver for Act outcomes, and someone who maintains the decision records. Security engineers typically run the triage, while system owners confirm impact and exposure. Expect recurring time for reviewing new advisories and for revisiting decisions when the environment changes. The effort scales with how many assets and products you track, so ask a partner to estimate internal hours in writing as part of the quote, and confirm the figure against your own staffing.

How long does an initial SSVC setup take?

The duration depends on your asset inventory, the number of product families in scope, and how many stakeholders must agree on impact definitions. A team with current inventory and a single product line can settle the decision inputs quickly; a multi-business-unit organization typically needs several review cycles before the outcomes are trusted. Drivers to check in any proposal include the scope of systems covered, integration with your ticketing and patch tools, and the number of approval paths. No duration is given here because no researched figure applies to your environment. Ask for a milestone plan with written deliverables before work starts.

Can an outside partner document the SSVC decision tree for an assessor?

A partner can prepare documentation that an assessor can review, but it does not issue audit reports or attestations. DeployOpen prepares systems, controls and evidence for compliance assessments, and independent auditors and certification bodies make the assessment. For a PCI DSS environment, requirement 11.3.1.1 covers vulnerabilities not ranked high-risk or critical, and it expects them handled through a targeted risk analysis under requirement 12.3.1, so the decision tree and its rationale should be written down and version controlled. Ask for the record format, the decision logs, and the sign-off trail, and confirm with your assessor which evidence they expect before scope is agreed.

Which CVSS version should we record in our vulnerability management policy?

Record the exact version you use, for example CVSS v4.0, and state whether you use Base scores only or add Threat and Environmental values. The CVSS v4.0 specification recommends enriching Base metrics with Threat and Environmental values, which it describes as not required but highly recommended. Your penetration test reports and scanner exports should name the same version so that severity figures can be compared across reports. If your scanner or assessor still reports a different version, record the mapping in the policy and confirm it with the tool vendor. Factors such as regulatory requirements or breach losses sit outside CVSS, so handle them in your risk process.

When should we pick SSVC outcomes over score thresholds?

Pick SSVC outcomes when your team needs a clear action per finding and cannot act on a long list of scores. A score threshold such as one fixed number for every system ignores exploitation status and mission impact, while the SSVC tree asks those questions directly. CVSS thresholds remain useful when your environment already runs on them, when contracts or regulators name a score, or when you lack the impact data SSVC needs. Many small teams start by mapping existing CVSS bands to SSVC inputs, then compare the two for a quarter before changing SLAs. Confirm the change with the people who sign off on remediation timelines.

How DeployOpen scopes and supports vulnerability prioritization

DeployOpen helps teams decide how SSVC outcomes and CVSS scores will sit together in their own remediation process, then builds that process inside their infrastructure. Work starts from a written scope, so the decision points, data sources and deliverables are agreed before any configuration begins.

How we scope

Written scope names which systems, scanners and penetration test sources feed the prioritization workflow.
The scope records which SSVC decision points your team can answer from its own data and which need input from owners.
Scope states whether CVSS base, threat and environmental values are recorded, and who sets them.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We configure the decision workflow and record outcomes (Track, Track*, Attend, Act) in the ticketing or tracking tool you already run.
Build work includes mapping CVSS scores from scanner and test output into the decision inputs your policy requires.
Testing covers sample findings from your own environment so the team can check each outcome against its documented rule.
Platform components are deployed in your cloud accounts, data centers or air-gapped networks, not in a DeployOpen-hosted service.

How we hand over

Documentation explains each decision point, its data source, the owner who answers it and the outcome it produces.
A written record shows which version of the SSVC tree and which CVSS version your policy references, for audit reference.
Handover includes a walkthrough with the engineers and the security leads who will triage findings day to day.
Documentation states which points are judgment calls, so reviewers know where a human decision overrides the tree.

How we support

Ongoing support, upgrades and continuous testing of the workflow are available as a retainer.
Retainer work can cover revisiting decision inputs when your asset inventory, threat model or exposure changes.
Confirm with DeployOpen during scoping how change requests to the tree and scoring rules are logged and approved.
Quotes follow from the written scope, so ask for the effort breakdown by component before you commit.

SSVC vs CVSS