Map scanner severity to ticket priority with a small rule table that also looks at exposure and reachability, not severity alone. Copying "critical" straight into a priority field floods teams with urgent tickets that are not urgent, and they stop believing the label.
Two scales, two jobs
Severity describes how bad a flaw is in general. Priority says how soon your team should act on it, here. They overlap and they are not the same. A critical flaw in a library used only in a test tool and never reachable from outside has high severity and modest priority.
A worked mapping
All thresholds below are examples to adapt.
| Severity | Reachable and exposed | Reachable, internal | Not reachable |
|---|---|---|---|
| Critical | Highest | High | Medium |
| High | High | Medium | Low |
| Medium | Medium | Low | Low |
| Low | Low | Low | Lowest |
Known exploitation raises any row by one step. A published fix that is a simple patch upgrade can justify scheduling sooner, because the effort is small.
Steps
- List your ticket priorities and what each means in time. For example, Highest equals fix within days, Low equals fix in a normal cycle.
- List the scanner severities in use. If you use more than one tool, normalize them to one scale first.
- Choose your adjusting signals: exposure, reachability, known exploitation, asset criticality.
- Write the table. Keep it small enough to fit on one screen.
- Implement it as code or configuration, not tribal knowledge, and store the table version in the ticket.
- Review monthly against outcomes. If Highest tickets keep turning out unimportant, tighten the rules.
Keep the original severity visible
Do not overwrite it. Store the scanner severity in its own field next to the priority, so a reader sees both and can question the mapping.
Link to the SLA
Priority should determine the due date, using your remediation SLA policy, so the mapping drives action and not only colour.
Try it yourself
In the demo, compare how many findings look urgent by severity alone, and how many remain once reachability is considered.
Click through it at your own pace, or open it full screen.
Quick check
Why not copy severity into priority?
Severity ignores your context. Copying it overstates urgency for unreachable or internal issues and teaches teams to ignore the label.
Should I keep the original severity?
Yes. Store it in a separate field so people can see both and question the mapping.
Safeguard offers reachability analysis and policies, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
