Open the latest report from your vulnerability scanner and count the lines marked "critical". Depending on the size of the organization, there are a few dozen or several hundred. They all carry the same word, they all demand the same urgency, and the team only has time for some of them. So you patch in score order, top to bottom, hoping the top of the list is also the most dangerous.
It rarely is. A critical vulnerability isn't necessarily urgent, and a "medium" one can be. Urgency doesn't come from a flaw's theoretical severity. It comes from the answer to three questions. Is it exploited? Is it exposed? Is it targeted?
Why CVSS alone isn't enough
The CVSS score is a good tool when it is used for what it is. FIRST's own user guide for version 4.0 says so plainly: the base score is designed to measure the severity of a vulnerability, not risk, and should not be used alone to assess risk. Status: official text.
Severity describes what a flaw would allow if exploited, in the abstract. Risk depends on your situation: is someone exploiting the flaw right now, can an attacker reach the affected asset, and do the people who exploit this kind of flaw go after organizations like yours? Two flaws scored 9.8 can carry very different risk: one on an internet-facing VPN appliance under active exploitation, the other on an isolated internal server with no known exploitation.
What this changes: sorting by CVSS sorts by theoretical severity. You end up diligently patching what threatens no one, while the flaw actually in use waits its turn.
Filter 1: is it exploited?
The first question is the easiest to document, because public sources answer it.
CISA's KEV catalog. The US cybersecurity agency maintains what it calls the authoritative source of vulnerabilities exploited in the wild: the Known Exploited Vulnerabilities catalog. A flaw only enters it with evidence of active exploitation. CISA recommends that every organization use it as an input to its vulnerability prioritization. Status: official source. It is a short list compared with the tens of thousands of vulnerabilities published every year, and that is what makes it useful.
FIRST's EPSS score. For flaws not yet in the catalog, the Exploit Prediction Scoring System estimates the probability that a published vulnerability will be exploited in the wild in the next 30 days. It is a probability, not a certainty, updated daily. It helps spot, in the mass, the flaws most likely to move from paper to attack.
In practice: a KEV-listed flaw goes to the top, whatever its score. A flaw outside the catalog but with a high EPSS comes next. Everything else waits for the normal cycle.
Filter 2: is it exposed?
An exploited flaw is only dangerous if the attacker can reach the asset carrying it. Two checks, often skipped:
- Is the asset really there? Scanners sometimes report flaws on versions no longer running, machines already retired or components switched off. Before mobilizing a team, confirm the asset exists and the vulnerable version is actually on it.
- Is it reachable? A service accessible from the internet, an open admin interface, an edge device: that is where an exploited flaw becomes a door. An isolated server on an internal segment still needs patching, but not with the same urgency.
This is not a gut feeling. CISA's BOD 26-04, issued on June 10, 2026 as "Prioritizing Security Updates Based on Risk", bases the remediation urgency of US federal agencies on four variables: whether the vulnerable asset is publicly exposed, whether the flaw is in the KEV catalog, whether an adversary can automate the whole exploitation, and whether exploitation gives partial or total control of the asset. For the most serious cases, it requires remediation within three days, together with a forensic triage to check for compromise. Status: official text. You are not a federal agency, but the logic holds for everyone: exposure is a first-order variable, not a detail.
Filter 3: is it targeted?
The third filter is the least used, because it requires looking beyond your own network: do the people exploiting this flaw go after organizations like yours?
Threat groups have habits. Some go after a sector, such as healthcare, manufacturing or financial services; others a country or a region; others a product family, such as remote access gateways or file transfer software. Threat intelligence exists precisely to answer this question: which groups are active against your sector and your country, and which flaws are they using right now?
This filter doesn't remove a flaw from the list. It breaks the tie, among exploited and exposed flaws, in favour of those in the sights of someone looking for you.
From thousands of lines to five or ten actions
Applied in order, the three filters change the shape of the list:
- Exploited, exposed and targeted: deal with it this week, with a compromise assessment if the flaw was being exploited before you patched.
- Exploited and exposed: within the shortest deadline in your policy, counted in days.
- Exploited but not exposed, or exposed with a high EPSS: in the next cycle, without pushing it back.
- Everything else: the normal cycle, and a review when one of the three signals changes.
The first category almost always fits in a few lines. That is the one that deserves the meeting, the budget and leadership's attention. One action doesn't mean one flaw: a single patch, upgrade or interface shutdown often clears several lines at once. That is how a list of thousands of vulnerabilities becomes five to ten actions you can name, assign and track.
One last point: the three signals change. A flaw enters the KEV catalog on a Tuesday, a device gets exposed by mistake on a Thursday, a group switches targets the following month. Prioritization is not a yearly sort, it is a continuous reading.
This week's test: thirty minutes, twenty lines
Take the twenty highest-scored vulnerabilities from your latest scan report, and answer three yes-or-no questions for each:
- Is it in CISA's KEV catalog? (A search by CVE number is enough.)
- Is the affected asset reachable from the internet, and is the vulnerable version actually there?
- Do you know whether groups active against your sector or your country exploit it?
Then count the lines with three yeses, and those with at least the first two. Three results should get your attention. None of your twenty "criticals" in the KEV catalog: your list sorts severity, not urgency; the exploited flaws may be further down. No way to answer question 2 without opening a ticket: you don't know what you expose, and that is the first job. No answer to question 3: you are prioritizing without knowing who is looking for you.
What you should have in a week
One page: your five to ten priority actions, each with the flaws it clears, the three signals that justify it, a named owner and a deadline. And a written rule going forward: any flaw that enters the KEV catalog and hits an exposed asset triggers a decision within days, not at the next monthly cycle.
The definitions of the three sources used here are in our glossary: CVSS, CISA's KEV catalog and EPSS.
Sources: FIRST, CVSS v4.0 User Guide (the base score measures severity, not risk) · CISA, Known Exploited Vulnerabilities Catalog · FIRST, Exploit Prediction Scoring System (EPSS) · CISA, BOD 26-04, Prioritizing Security Updates Based on Risk (June 10, 2026)