Priority is a workflow decision
Severity, exploitation signals, and scores help sort a queue, but priority also depends on confirmed affected assets, reachability, authentication boundaries, business process impact, data sensitivity, compensating controls, patch availability, vendor guidance, detection coverage, and the safety of the change. These categories support local decisions; they are not universal service-level agreements.
Decision matrix
| Workflow category | Typical evidence | Next step |
|---|---|---|
| Immediate investigation | Confirmed affected, exposed asset plus strong exploitation or business-impact signal. | Validate owner, containment options, vendor guidance, and escalation path. |
| Expedited remediation | Confirmed affected service with a tested patch or bounded mitigation path. | Plan change, rollback, validation, and evidence retention. |
| Planned remediation | Affected scope confirmed but exposure or operational urgency is lower. | Schedule with owner and track dependencies. |
| Monitor and validate | Local applicability or exposure remains unknown. | Request evidence, set a review time, and watch relevant source changes. |
| Risk acceptance review | Remediation is deferred with documented residual risk and controls. | Obtain time-bound approval and revalidation. |
Practical workflow
- Confirm product, version, asset, owner, and vulnerable path.
- Assess exposure and reachable attack conditions; do not infer them from severity alone.
- Review KEV, EPSS, CVSS, exploit evidence, vendor guidance, and detection coverage as different inputs.
- State the action category, constraints, owner, review date, and evidence needed for closure.
Common mistakes
Do not require the same deadline for every organization, treat no scanner result as not affected, or call an unavailable patch a reason to stop. A compensating control can reduce risk without eliminating it, and a high-value internal service can still justify early review.