Combine exploitation evidence, exposure and business impact to decide which security weaknesses need attention first.
Treat the score as one input
A vulnerability scan can produce more findings than a team can resolve at once. Sorting everything by a technical severity score is a useful start, but it does not explain how a weakness affects a particular business. An exposed remote-access system and an isolated test machine may have very different consequences even when their software shares the same vulnerability.
Before assigning a deadline, confirm the affected product, version and configuration. Check whether the vulnerable component is actually present and reachable. Record who owns the system and which business service depends on it. This avoids spending effort on incorrect matches while an important exposed service remains untreated. Validation should be authorised and proportionate to the environment.
Add exploitation evidence and exposure
CISA's Known Exploited Vulnerabilities catalogue identifies vulnerabilities for which exploitation has been observed. Use it as an input to prioritisation, together with vendor advisories and relevant incident information. Absence from the catalogue is not proof that a vulnerability is harmless or will remain unexploited. Continue to assess weaknesses using the evidence available to your organisation.
FIRST's Exploit Prediction Scoring System estimates the probability of exploitation activity in the next thirty days. It answers a different question from technical severity. An EPSS value is not a prediction that a specific organisation will be compromised. Combine these signals with internet exposure, required privileges, existing controls and the sensitivity of the affected service.
Translate priority into an owned action
For each priority item, decide whether the response is a patch, configuration change, service restriction or removal of an unsupported component. Assign an owner and an agreed completion target. If a permanent fix is not immediately available, document the temporary mitigation, its limitations and how the team will confirm it remains in place. Do not close the finding merely because it has been forwarded to a supplier.
Use a short change record that includes the affected assets, the proposed action, expected operational impact and a recovery approach if the change fails. NIST's patch-management guidance covers the complete process from identifying updates through verifying installation. A successful maintenance window is not enough if some devices were offline or the update required a restart that never occurred.
Verify the result and manage exceptions
Confirm that the intended version or configuration is present, then repeat the relevant assessment safely. Also check that the application still performs its important business functions. Keep the verification evidence with the original finding. For services maintained by a third party, agree what evidence is required rather than relying only on a statement that the issue has been handled.
Some fixes will be delayed by compatibility or availability constraints. Record the reason, the person accepting the residual risk, the compensating controls and the next review date. Reconsider the decision if exploitation evidence or exposure changes. Exceptions that have no review date tend to become permanent, even when the original reason for delay has disappeared.
Use measures that reflect exposure
Report how long important exposed findings remain unresolved, how many exceptions are overdue and whether repeat scans confirm remediation. Separate unsupported technology from routine patching because it may require replacement planning. These measures encourage risk reduction across the environment and make it easier for management to understand where investment or a business decision is needed.
