SSVC Deployer Model Explained: How Exploitation, Exposure, Automatable and Human Impact Set Patch Priority

Most teams prioritize patches by a severity score, then argue about the exceptions. CERT/CC’s SSVC takes a different route: it asks four questions about the vulnerability and your own systems, and a fixed lookup table returns a priority. This article explains the deployer version of that model, reproduces its full decision table so you can check it yourself, and shows how much of the answer CISA’s public CVE data can and cannot provide.

Scope and method. We read the CERT/CC SSVC documentation on October 18, 2026: the “Prioritizing Patch Deployment” page (the deployer model), and the reference pages for Human Impact, Safety Impact and Mission Impact. We extracted the 72-row decision table from the page and checked it programmatically (counts, completeness and consistency, described below). We also read the CISA Vulnrichment SSVC values and CISA Known Exploited Vulnerabilities (KEV) entries in six CVE records from the CVE Services API on October 18, 2026. The CERT/CC pages show no publication date, so we cite the read date. We did not test SSVC in a production vulnerability-management program, and this is research-based analysis, not firsthand operating experience. If you only want to read CISA’s own three values, see our Vulnrichment guide; this article covers the other decision a deployer faces.

The short answer

• Who it is for. The “deployer”: an organization that receives a patch or mitigation from a supplier and decides how fast to apply it to systems it runs. CERT/CC recommends the unit of work be the pairing of a remediation or mitigation with one product-version instance.
• Four inputs: Exploitation, System Exposure, Automatable, Human Impact.
• Four outputs: Defer, Scheduled, Out-of-cycle, Immediate.
• How many inputs you supply yourself: two (System Exposure and Human Impact). Exploitation and Automatable can come from public sources such as CISA’s data, if you accept them.

The four inputs

“PoC” means proof of concept. Note the definition of Controlled: CERT/CC says a successful mitigation must reliably interrupt the adversary’s attack, which requires that the attack be detectable both reliably and quickly enough to respond. A firewall rule nobody monitors does not necessarily qualify.

Human Impact: the lookup table

Human Impact combines Safety Impact (v2.0.1: Negligible, Marginal, Critical, Catastrophic, based on IEC 61508 with modifications) with Mission Impact (v2.0.0: Degraded, MEF Support Crippled, MEF Failure, Mission Failure). “MEF” means Mission Essential Function. This is the lookup table published on the Human Impact page:

A documentation inconsistency you should know about. The same page also gives prose definitions of each Human Impact level, and they do not match the table in four cells:

In addition, the prose does not mention Critical combined with MEF Failure at all, while the table gives High. We use the table, because it is the full 16-cell mapping and the prose definitions do not cover every combination. This is our judgment, not a CERT/CC statement. Before adopting the model, check which one your tooling implements, and check the current CERT/CC page, as this may be corrected.

The full decision table

This is the example decision table from the CERT/CC deployer page (identified there as ssvc:DT_DP:1.0.0), reorganized so each row shows the outcome for all four Human Impact levels. The original lists 72 rows (3 Exploitation values × 3 System Exposure values × 2 Automatable values × 4 Human Impact values); we confirmed that each of the 72 combinations appears exactly once.

What the table shows (our counts)

We counted outcomes across the 72 rows and checked the shape of the table:

• Active exploitation never yields Defer. This matches a note on the CERT/CC page.
• Immediate needs Active exploitation and Open exposure. All three Immediate rows are Active, Open and one of: Automatable No with Very High Human Impact, or Automatable Yes with High or Very High Human Impact.
• No exploitation evidence is mostly Defer or Scheduled. The one exception is None, Open, Automatable Yes and Very High Human Impact, which is Out-of-cycle. The CERT/CC page makes the same observation.
• The table is monotonic. We compared every pair of rows: raising any single input, with the others unchanged or also raised, never lowered the priority in the table (zero violations out of all comparable pairs).

What CISA’s public data can feed in

CISA’s Vulnrichment adds an SSVC block to many CVE records, with three decision points: Exploitation, Automatable and Technical Impact. Exploitation and Automatable share names with two deployer inputs. We read six records on October 18, 2026; values were stamped by CISA on the dates shown and could have changed since:

Three cautions apply before you reuse these as deployer inputs:

1. Definitions may differ. CISA labels its blocks with the role “CISA Coordinator” and tree version 2.0.3. We did not compare CISA’s decision-point versions against the deployer model’s versions line by line. The names and the value sets (none/poc/active; no/yes) match, but confirm before automating.
2. A timestamp is a snapshot. CVE-2026-105207 was marked none on October 6; “none” says no evidence at that time. Recheck KEV and the vendor advisory.
3. A missing block is missing data. No CISA block does not mean low risk. See the KEV feed guide for matching KEV to your inventory.

Technical Impact is part of CISA’s own tree but is not one of the deployer model’s four inputs. Do not feed it in as if it were.

Worked examples: same flaw, different answers

Suppose the affected product is running in your environment. We take Exploitation and Automatable from the table above, then show the full range of outcomes across your two inputs. All outcomes are read from the decision table.

More useful are the in-between cases. For CVE-2026-88771 (Active, Automatable Yes):

Read that second table carefully. An internet-facing instance (Open) supporting a function with Human Impact Medium is Out-of-cycle, not Immediate; the model reserves Immediate for High or Very High impact on an Open system. An instance with Controlled exposure is Out-of-cycle at every Human Impact level. This is the model’s output, not an endorsement of those timings for your organization.

For CVE-2026-102489 (Active, Automatable No) an Open system with Medium Human Impact is Out-of-cycle, and a Controlled system with Medium Human Impact is only Scheduled, even though the flaw is listed in KEV. That is the kind of result a severity score alone would not give you, and the kind a risk owner may want to override. SSVC does not stop you from doing so.

Using it in practice

1. Pre-assign Human Impact by asset class. Record, once, the Safety Impact and Mission Impact level for each class of system, then look up Human Impact in the table. Re-deciding it per CVE is where inconsistency creeps in.
2. Define Exposure per instance, not per product. The same product can be Open in one place and Small in another. Apply CERT/CC’s strict wording for Controlled.
3. Treat mitigations as input changes. CERT/CC says a mitigation that successfully changes a decision point can lower the priority; it also warns that mitigations can fail, for example a firewall rule that is later changed. If you rely on one, record who owns it.
4. Keep legal deadlines separate. Binding timelines, such as those in BOD 26-04 for federal agencies, are not the same thing as SSVC priorities.
5. Compare with your current method. Our comparison of CVSS, EPSS and KEV shows what each signal answers; SSVC’s deployer table consumes an exploitation signal and then adds your context.
6. Reassess when inputs change. CERT/CC says remediation is not a final state, because rollbacks or new deployments can reintroduce a vulnerability.

Limits of this article

• We read the CERT/CC example table; we did not read the underlying repository files or test CERT/CC’s calculator tool.
• The CERT/CC pages show no dates, so we cannot say when the table or the Human Impact inconsistency was last changed.
• The CVE examples assume the affected product is present in your environment and are not statements about any real organization.
• Values in live CVE records can change after October 18, 2026.
• The outcome names describe urgency, not a service-level agreement. CERT/CC does not give hour or day limits for them on the pages we read, so we give none.
• We did not evaluate how well SSVC performs compared with other methods.

Sources and verification

CERT/CC pages and CVE records read October 18, 2026.

Vulnerability ManagementProcess