Write one severity definition and one timeline table, approve them together, and store them where all three teams read the same copy. Each team will then rank, fix and report findings the same way. Without it, one team calls an issue high, another calls it medium, and the audit report shows both.
Why separate scales cause trouble
Product security often uses the score from the vulnerability record. Platform may rank by effect on uptime. Compliance may follow whatever the policy text says. All three are reasonable, but a finding rated critical by one and medium by another produces a dispute in every meeting.
A base score describes a flaw in general. It does not know whether your code calls the vulnerable function, whether the service is exposed or whether the issue is known to be exploited. Those facts change real urgency. NIST SSDF task RV.2.1 gives the example of calculating risk from estimates of exploitability and potential impact, and not from the score alone.
Build the scale in three steps
- Start with the base score band, such as critical, high, medium and low.
- Add adjustment rules that move a finding up or down, written as plain conditions. For example, up one level when the issue is known to be exploited, down one level when the vulnerable code is not reachable.
- Add a floor and a ceiling so adjustments cannot hide something serious.
Then set the timeline
| Final severity | Fix target | Exception allowed |
|---|---|---|
| Critical | Short, in days | Only with leadership approval and short expiry |
| High | Longer, in a few weeks | Product security approves with expiry |
| Medium | Next planned cycle | Service owner approves, product security informed |
| Low | Backlog | Tracked, no expiry needed |
Pick your own numbers and write them down. The post on container vulnerability SLAs by severity and fix availability goes deeper on timelines. The important point here is that all three teams approve one table.
Write the exception rule
Exceptions are part of the scale. NIST CSF 2.0 outcome ID.RA-07 says changes and exceptions should be managed, assessed for risk impact, recorded and tracked. Each exception needs a reason, an approver and an expiry date, and its record should be linked to the finding.
Review it
Revisit the scale at least yearly, or after an incident shows it misjudged something. NIST SP 800-218 task PO.4.1 mentions defining key performance indicators, key risk indicators and severity scores as measures for software security, so these definitions are part of a normal secure development program.
Try it yourself
Click through it at your own pace, or open it full screen. See how exploitability changes how urgent a finding should feel.
Where Safeguard fits
Safeguard's reachability analysis supplies the context behind adjustment rules, and its policies can enforce your timeline. A free scan shows findings with that context.
Quick check
Can compliance override a severity?
Compliance should not change technical severity. It can ask for the reasoning to be recorded and checked against the agreed adjustment rules.
What if a customer contract sets a different timeline?
Note the stricter commitment in the table for the affected services, so engineers see the one that applies to them.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, tasks RV.2.1 and PO.4.1.
- NIST Cybersecurity Framework 2.0, outcome ID.RA-07.
Last reviewed: 19 October 2026.
