Skip to content

Fig Group · Practical resource

Vulnerability prioritisation: a worked example

Prioritise vulnerabilities using applicability, exploitation evidence, exposure and business impact alongside severity. Preserve each input and the reason for the decision, then assign work and verify the fix.

By Fig Group · Updated

Use the template Explore vulnerability management

All findings and scores below are fictional teaching data, not real CVEs, a live threat feed, an incident report or a claim about customer outcomes. Example deadlines are local policy choices, not universal requirements.

Keep the signals separate

CVSS describes technical severity. FIRST’s EPSS estimates exploitation activity for a published CVE over the next 30 days; it does not estimate the chance that your particular system will be compromised. CISA’s KEV catalogue identifies vulnerabilities known to have been exploited. Use a dated source for each real finding.

Confirm the affected version and configuration before prioritising. Check attack reachability, the service supported, existing controls and any scheme or contractual remediation deadline. Missing exploit information is unknown, not proof of safety.

Compare three fictional findings

Compare three fictional findings
FindingSignals and contextDecision and evidence needed
A: isolated test toolIllustrative severity 9.8. Test system, no production data, isolation asserted but not yet verified.Validate isolation today. If confirmed, schedule treatment under policy; if disproved, escalate. Keep the high original severity.
B: customer booking gatewayIllustrative severity 8.1. Applicable version, internet-facing, credible known-exploitation evidence in this scenario, critical service.Prioritise B. Technical owner reviews containment and fix with the service owner; investigate separately if there are signs of compromise.
C: internal reporting componentIllustrative severity 7.5. Restricted access and a vendor fix available; no current exploitation information.Assign a patch owner and policy deadline. Verify exposure and monitor new information; do not classify missing intelligence as low risk.

Record the reasoning and prove closure

Example decision at triage: B precedes A because it combines confirmed applicability, reachability, exploitation context and service impact. A has a parallel action to prove its isolation. C remains in the treatment queue with an accountable owner. No arbitrary average of the three scores is needed.

For B, record the approved change, temporary protections, affected assets, implementation time and verification method. After the fix, verify the version or configuration and repeat the relevant check. A closed ticket alone is not verification. If a workaround is used, retain its limitations and expiry date.

Policy deadlines still apply. A low EPSS score cannot waive a contractual or certification requirement. An overdue fix needs escalation and an authorised decision; changing the recorded deadline must not erase the original obligation.

Build a defensible queue

  1. Validate the finding

    Confirm asset, affected version, observation time and owner. Preserve the scanner result and distinguish missing information from negative evidence.

  2. Explain the priority

    Combine dated exploitation context, exposure, service importance and mandatory deadlines. Record the decision and any assumptions requiring validation.

  3. Treat, verify and revisit

    Assign action and due date, approve necessary changes, retain verification evidence and review if exposure or intelligence changes.

Copy or download the template

Use the blank worksheet in your own document editor. Replace the prompts with your organisation’s details, obtain the relevant approvals and keep a controlled copy.

VULNERABILITY PRIORITISATION RECORD
Finding / CVE (if applicable):
Asset / version / service / owner:
Observation and validation time:
Scanner evidence:
Severity score and version:
EPSS value, probability/percentile distinction and observation date:
Known-exploitation source and date:
Exposure and applicability evidence:
Business impact and dependencies:
Compensating controls and evidence:
Required policy/contract/scheme deadline:

Priority and reasoning:
Unknowns and validation owner:
Treatment / owner / due date:
Change approval / dependencies:
Temporary exception authority, conditions and expiry:
Verification method and result:
Closure approver and date:
Reassessment triggers:

Explore the workflow in Fig Group

Fig Group’s vulnerability management capability consolidates scanner output and connects findings to exploit context, assets, owners and remediation evidence. Bring contrasting findings to a demonstration and ask to see the decision trail. Confirm supported scanner connections. A separately commissioned scanning service has its own scope.

Discuss vulnerability management Explore the capability

Common questions

Should the highest severity always be fixed first?

Not automatically. Confirm applicability, exploitation, exposure and business impact while respecting mandatory deadlines. Preserve the original severity and document the reason for a different treatment order.

Does a low EPSS score mean a vulnerability is safe?

No. EPSS concerns predicted exploitation activity, not asset-specific safety. Applicable policy deadlines, known exploitation and your environment still matter.

Sources and further reading

Use the current source guidance alongside your own requirements when completing the worksheet.