Tools · Smaller checks
What priority and deadline does this finding get?
Answer four questions about one vulnerability finding on one system, with one follow-up if it can be reached from the internet. You get its priority, the deadline that goes with it, and which answers decided it. Add the date it was detected and, if you know it, the date the vendor published a fix. Nothing you enter leaves this page.
Question 1 of 4
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: day 0 is the earlier of the day the finding was first detected on the system and the day the vendor published its fix, not the day a ticket was raised (VM-08). Leave the fix date empty if the vendor has published no fix or you do not know it, and day 0 is the day of first detection. A fix published after detection changes nothing. Deadlines are calendar days, so "fix within 7 days" of a day 0 on a Friday means fixed by the Friday after. A finding is overdue from the day after its deadline, and is overdue from the day it is detected if its deadline had already passed. The one clock in hours, Priority 1's 72-hour mitigation, runs from the moment of detection, or of the finding becoming Priority 1 when it is re-rated (RM-12), not from the vendor release, so it is shown with a time. Add the dates 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, or public exploit code for a High or Critical weakness on an internet-facing system, creates a Priority 1.
Public exploit code for a vulnerability rated High or Critical on an internet-facing system makes the finding Priority 1 (RM-14). It takes the same route as any Priority 1: the 72-hour mitigation, the compromise check in the emergency procedure, and the 7-day fix. Whether exploit code is public is not known, and an internet-facing system is treated as if it were until the standard owner records the answer (RM-14). Check public code repositories, exploit databases and attack frameworks, and re-rate the finding if there is none. Public exploit code for a Medium or Low weakness does not by itself make the finding Priority 1 (RM-14). The priority comes from the table, and under RM-06 the chair of the triage meeting may raise it, with the reason recorded.
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 counts its one-month period for critical (or, in some readings of the standard, high-security) patches from the patch's release; check the wording of your version with your assessor. Where a vendor fix exists, this clock also starts at its release when that is earlier than detection (VM-08). |
| Priority 4 — Low | 90 days | May be addressed through the normal patch cycle. |
Day 0 is the earlier of the day the vulnerability was first detected on the system and the day the vendor published its fix (VM-08). With no vendor fix, it is the day of first detection. A fix published after detection changes nothing. The 72-hour mitigation is counted in elapsed hours from the moment of first detection, or of the finding becoming Priority 1 when it is re-rated (RM-12), in your own time zone, and not from the vendor release. Every other deadline is a date, counted on the calendar from day 0, so a clock change never moves it. A finding whose deadline had already passed on the day it was detected is overdue from that day. 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 clock start 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.