Use dated EPSS scores with local exposure evidence
Keep exploitation forecasts separate from asset risk. Record EPSS date, probability, percentile, local applicability, and the remediation decision.
EPSS can help order a vulnerability queue, but it does not know which software your organization runs or how a particular service is configured. Start with verified advisory applicability. A forecast for the wrong component is not useful prioritization evidence.
FIRST defines EPSS as a forecast of exploitation in the wild over the next 30 days. Probability and percentile are different fields. Neither is the probability that your specific application will be compromised.
Preserve the score's context
Record the vulnerability identifier, score date, model information where supplied, probability, and percentile. Do not save an unlabeled number that a later dashboard might interpret as severity. Keep the original source reference alongside any internal priority.
| Field | Meaning in the triage record | Local question still needed |
|---|---|---|
| EPSS probability | Dated exploitation forecast | Is our installed component affected? |
| EPSS percentile | Relative position among scored vulnerabilities | What work can the team complete now? |
| Known exploitation evidence | Separate observed threat signal | Which local paths are exposed? |
| Impact assessment | Consequence in this service | What data or authority could be affected? |
| Mitigation state | Current local control evidence | Is the control verified and temporary? |
Label a missing score as unavailable, not zero. Distinguish a data retrieval failure from a genuine published value.
Use a decision rule people can explain
Define how forecast, known exploitation, exposure, and business impact influence the queue. Review exceptional cases with the accountable service owner. A low forecast does not justify ignoring a severe, directly reachable issue or contradict documented exploitation.
Avoid producing a new probability by multiplying unrelated numeric ratings. If the team uses an internal ranking, label it as a policy ranking and record its inputs. That makes changes reviewable without suggesting statistical precision the method does not support.
Refresh the decision without erasing history
When a score changes, preserve the earlier value and the reason for any queue change. Do not overwrite the evidence behind yesterday's decision. Set recheck triggers for new exploitation evidence, a deployment change, or an expired mitigation.
At closure, verify the corrected deployed component rather than waiting for a forecast to fall. The completed worksheet should show the dated forecast, the local facts, the owner, and the action. It should help the team choose work while remaining clear about what the model did not measure.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.