Severity describes how serious a flaw is in itself. Priority says how soon your team will fix it, given everything else going on. The tester or security team usually suggests severity, and product and engineering leaders set priority. Keep them in separate fields so each can change without confusing the other.
The difference in one table
| Severity | Priority | |
|---|---|---|
| Question | How bad is this flaw? | When do we fix it? |
| Depends on | The flaw and its potential impact | Exposure, workload, deadlines, risk appetite |
| Set by | Tester or security, reviewed | Product and engineering |
| Changes when | New facts about the flaw appear | Circumstances or capacity change |
| Example | High: any logged in user can read other invoices | P1: fix this sprint |
A high severity flaw in a feature nobody can reach may be low priority. A medium severity flaw that is being actively abused may jump to the top.
What goes into a severity suggestion
Write the reasoning, not just a label. Useful facts:
- Who the attacker must be: anonymous, logged in, admin.
- What they need: network access, a victim click, a special setting.
- What they gain: read data, change data, take over accounts.
- How much is affected: one record, one tenant, everything.
- Whether the flaw is hard or easy to trigger.
If your team uses a scoring system, record the score and the vector that produced it, so others can check the working. Remember that a score describes the flaw in general. It does not know your environment.
What goes into a priority decision
- Is the affected feature reachable in production?
- Is there any sign of attempted abuse?
- Are customers, contracts or regulators affected?
- Is there a workaround, such as a feature flag or a configuration change?
- How big is the fix and what else will slip?
Document the decision and the person who made it. A ticket that says "P3" with no reason invites argument later.
Common mistakes
Mixing the two into one field. Teams then lower the "severity" to get a lower priority, and the record loses the truth about the flaw.
Letting the reporter set priority. They do not see the whole roadmap.
Letting priority hide severity. A low priority high severity ticket needs an owner and a review date, or it sits for years.
Changing severity to match deadlines. If new facts reduce it, say what they were.
Review rhythm
Look at open high severity tickets weekly. Ask whether the priority still makes sense. If a ticket is parked, record the compensating control and when it will be revisited.
For tickets with an agreed fix time, track the age and flag the ones about to pass it.
A short template line
"Severity: High, because any authenticated user can read other tenants' invoices by changing one identifier. Priority: P1, because the feature is live and used by all customers. Decided by: engineering manager, 19 October."
Try it yourself
Click through it at your own pace, or open it full screen. Notice how exploitability context changes how urgent a finding is, which is the heart of priority.
Safeguard's reachability analysis supports this decision for dependency findings. Start with the free scan.
Quick check
Can a low severity bug be high priority?
Yes, for example when it is being abused or blocks a contractual commitment.
Who should record the reasoning?
Whoever sets the field. The tester explains severity and the decision maker explains priority.
Last reviewed: 19 October 2026.
