Tools · Smaller checks
What priority and deadline does this finding get?
Answer four questions about one vulnerability finding on one system. You get its priority, the deadline that goes with it, and which answers decided it. Free, no account, and nothing you enter leaves this page.
Question 1 of 5
One finding means one weakness on one system. The same flaw on twenty systems is twenty findings, and each can end with a different priority.
How the pack counts: the day the finding was first detected on the system is day 0, not the day a ticket was raised. Deadlines are calendar days, so "fix within 7 days" of a finding detected on a Friday means fixed by the Friday after. A finding is overdue from the day after its deadline. The one clock in hours, Priority 1's 72-hour mitigation, runs from the moment of detection, so it is shown with a time. Add the date and time to see the actual dates.
This finding
Answer the questions and the priority appears here. Some answers settle it before all four are given.
- 4 questions, about 2 minutes
- Nothing is stored, not even in your browser: reloading starts again
- If you accepted analytics, we count how far people get through the questions, never what they answer.
How this was calculated, and what it is not
The questions come in a fixed order, and the order matters more than the numbers. Evidence that attackers are using the weakness comes first, because it outranks the severity score: an exploited weakness is never below Priority 2 (RM-02). Then reach from the internet and how critical the system is, then the scanner's severity. A Critical system raises a finding by one level, but never to Priority 1 (RM-05). Only evidence of real attacks creates a Priority 1.
Where exposure, criticality or severity is not known, the more urgent value is used, so gaps in your asset inventory cost the people who can close them (RM-03). Where exploitation is not known, the finding counts as not exploited and is checked again at the next weekly triage.
| Exploited? | Severity | Internet-facingStandard or High system | Internet-facingCritical system | InternalStandard or High system | InternalCritical system |
|---|---|---|---|---|---|
| Exploited | Any | Priority 1 | Priority 1 | Priority 2 | Priority 1 |
| Not known exploited | Critical or High | Priority 2 | Priority 2 | Priority 3 | Priority 2raised from 3 |
| Not known exploited | Medium | Priority 3 | Priority 2raised from 3 | Priority 4 | Priority 3raised from 4 |
| Not known exploited | Low | Priority 4 | Priority 4 | Priority 4 | Priority 4 |
| Priority | Deadline | Note |
|---|---|---|
| Priority 1 — Emergency | Mitigate within 72 hours; fix within 7 days | Treat as a potential incident. Notify the standard owner immediately. |
| Priority 2 — High | 14 days | Escalate to asset owner's manager if not fixed by day 10. |
| Priority 3 — Medium | 30 days | PCI DSS sets its own clock for critical patches: one month from the patch's release, not from detection. |
| Priority 4 — Low | 90 days | May be addressed through the normal patch cycle. |
The 72-hour mitigation is counted in elapsed hours from the moment entered, in your own time zone. Every other deadline is a date, counted on the calendar with the day of detection as day 0, so a clock change never moves it. Priority 2 goes to the asset owner's manager if it is still open on day 10. Any finding still open after its deadline, with no approved exception, is overdue from the next day and goes to the asset owner's manager, then to the approver 14 days later.
Re-rating a finding
- More urgent (RM-12). When a finding becomes more urgent because an input has changed — for example, it has just been added to the Known Exploited Vulnerabilities catalogue — its new deadline is the earlier of its existing deadline and the date the change became known plus the new priority's period. For Priority 1, the 72-hour mitigation also runs from that date.
- Less urgent (RM-07). A priority may be lowered only by the standard owner, with the reason recorded (VM-10), and only because an accepted compensating control changes an input. The finding is re-read from the lookup table with the changed input; the result is its new priority. A lowering is never made to avoid a missed deadline, and is not considered once the deadline has passed — the route then is the exception process (VM-16) or overdue escalation (VM-19).
- The clock does not restart (RM-08). Lowering a priority does not restart the clock: the new deadline is the date of first detection plus the new priority's period.
- If the control goes (RM-09). If a compensating control relied on under RM-07 is removed or stops working, the finding returns at once to its original priority and deadline. If that deadline has passed, the finding is overdue.
Two things the model does not say, so the page does not guess: when the day-10escalation falls after a re-rating, and whether a deadline ends at the start or the end of its day. The page shows dates, and treats a finding as overdue from the day after.
What it is not
- Not your standard. The priorities and deadlines are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones.
- Not a way to lower a priority. Making a finding more urgent needs no approval. Making it less urgent needs the standard owner, a recorded reason and a control that actually changes one of the four answers, such as taking the service off the internet. "The firewall should block it" does not.
- Not a risk acceptance. If the fix cannot be made in time, ask for an exception before the deadline.
- Not incident handling. If the weakness may already have been used against you, treat it as an incident now instead of waiting for the fix.