Patch today when a flaw is known to be exploited, the vulnerable code is present and reachable on the client's site, and the site is exposed to the internet. Everything else goes on a schedule. Three questions sort most of the pile in a few minutes.
An agency with many sites will always have a backlog. Triage keeps the urgent items from sitting behind the cosmetic ones.
The three questions
- Is it being exploited? CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation in the wild, and CISA says organisations should use it as an input to prioritisation.
- Is the vulnerable code actually in use? A plugin that is installed but has the affected feature disabled, or a library that is never called, is less urgent than one on every page. This is reachability.
- Is it exposed? A public login or form is more urgent than an admin screen behind a network restriction.
A triage table
| Exploited in the wild | Reachable on this site | Exposed | Timing |
|---|---|---|---|
| Yes | Yes | Yes | Same day |
| Yes | Unknown | Yes | Same day, until proven otherwise |
| No | Yes | Yes | Within a week |
| No | Yes | No | Next planned window |
| No | No | Any | Quarterly, or remove the component |
These timings are examples, not standards. Pick numbers you can keep and write them into the retainer.
Do not skip the "unknown" row
If you cannot tell whether code is reachable, assume it is. The cost of checking wrongly is a missed patch. The cost of patching unnecessarily is a short change window.
Batch the rest
Group low urgency updates into a monthly window, staged on a copy of the site first. This also reduces the number of times a client sees a change. Keep a log of old and new versions so a regression can be traced.
Remove what you do not need
A component that is not installed cannot be exploited. Part of triage is asking whether the plugin or package is still needed. The WordPress hardening guide's first theme is limiting access and reducing entry points, and removing unused plugins is the simplest way to do it.
Tell the client what you decided
For anything urgent, send the short message described in our post on telling a client about a vulnerable plugin. For the routine items, a monthly summary is enough.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out when only reachable ones are kept, which is the second question in the list.
Safeguard's reachability analysis applies this to dependencies in a project repository, and the free scan is a way to try it.
Quick check
Is a high severity score always urgent?
No. Combine it with evidence of exploitation, reachability and exposure before deciding timing.
What if I cannot tell whether a site is affected?
Treat it as affected until you can show otherwise, and patch on the faster timeline.
Sources
Last reviewed: 19 October 2026.
