Run a vulnerability triage meeting weekly for 30 minutes with the security lead, a champion and an owner or two. Review only new and high-risk items, sort them by exploitation evidence, reachability and exposure, make one of four decisions for each, assign an owner, and write the reason down.
Prepare before the meeting
Never triage from a raw export. Before the meeting, someone prepares a short list: new findings since last week, findings that moved into a higher risk class, and items past their due date. Everything else stays in the dashboard. Aim for no more than fifteen items, so each gets two minutes.
The sorting questions
Ask these in order and stop when you have a decision.
- Is it being exploited? Check whether the vulnerability is in the CISA Known Exploited Vulnerabilities catalog, which lists flaws exploited in the wild and is meant to be an input to prioritisation.
- How likely is exploitation? The EPSS score, maintained by FIRST, estimates the probability that a published CVE will be exploited in the next 30 days. It is a probability from 0 to 1, updated daily, and is useful for ordering the rest.
- Is the vulnerable code reachable? A flaw in a function your service never calls is a lower priority than one on a request path.
- Is the service exposed? Internet facing, or internal only?
- What data or action sits behind it? Customer data or payments changes the answer.
No single score decides. Use them to explain the order.
The four decisions
| Decision | Meaning | Record |
|---|---|---|
| Fix now | Owner patches within the agreed window | Owner and date |
| Schedule | Fix in a planned change | Ticket and target date |
| Mitigate | Reduce risk without patching | Control and expiry |
| Accept | Not worth fixing now | Reason, approver, expiry |
"Wait and see" is not a decision.
Meeting rules
- Time box each item. If it needs more than five minutes, assign a follow up and move on.
- The owner speaks first. They know the service.
- Security brings facts, not verdicts.
- Anything that needs engineering judgement goes to the team lead afterwards.
- End by reading out new assignments and dates.
What to track afterwards
Keep a simple log: item, decision, owner, date, reason. Review it for patterns. If the same service keeps appearing, look at its dependency update habits. If many items end as "accept", your scanner may be too noisy.
Try it yourself
Open the exploitability demo and look at how reachability and exploitation evidence change the order of findings.
Click through it at your own pace, or open it full screen.
Quick check
Should every finding be discussed?
No. Triage the new and high risk items. Low risk items follow default rules and are reviewed in aggregate.
Is CVSS enough to order the list?
It describes severity of the flaw, not whether it is being exploited or reachable in your code. Combine it with exploitation evidence and context.
Safeguard provides reachability analysis to help order a backlog, and you can try a free scan to see it on your own dependencies.
Sources
Last reviewed: 19 October 2026.
