Every week brings a new batch of vulnerabilities. Most IT and security teams can't patch them all at once, so they sort by severity score and start at the top.

That feels sensible. It is also how a team spends a week on a critical flaw in a system nobody can reach, while a medium-rated one on the public login page is being used against them.

My advice: rank by what attackers are actually using and what you actually expose. Severity comes after that, as a tiebreaker.

Severity is not risk

The common severity score, CVSS, describes how bad a vulnerability could be in general. It looks at things like how easy it is to exploit and what an attacker could do with it.

It does not know whether anyone is exploiting it right now. It does not know whether the affected software runs on a server facing the internet or on one laptop in a locked room. It does not know what that system means to your business.

Those three things are what decide your real risk. A score that ignores them is a starting point, not a ranking.

Start with active exploitation

The first question for any new vulnerability is simple: is it being used in real attacks?

There are good public sources for this. CISA keeps a Known Exploited Vulnerabilities catalog, a list of flaws confirmed to be exploited in the wild, and recommends that organisations use it as an input when they decide what to fix first. FIRST publishes EPSS, a daily score that estimates how likely a vulnerability is to be exploited in the next 30 days.

Neither is perfect. A flaw can be exploited before it appears on any list. But "known to be exploited" is a much stronger signal than "could be bad," and both sources are free.

So the first sort is: exploited and open goes to the top.

Then map it to your own systems

A vulnerability only matters to you if you run the affected software. That sounds obvious, but many teams can't answer "which of our machines does this touch?" without an afternoon of digging.

You need an asset list that is good enough to answer three questions quickly:

  • Do we run it? Which systems, which versions.
  • Is it exposed? Facing the internet, reachable from the main network, or isolated.
  • What does it do for us? A payment system, a file server, a test box.

An exploited flaw on an exposed, important system is an emergency. The same flaw on an isolated test machine can wait for the normal cycle. The score is identical. The risk is not.

A simple order that works

I would rank open vulnerabilities like this:

  1. Exploited, and on systems you expose.
  2. Exploited, on internal systems.
  3. Likely to be exploited soon, on exposed systems.
  4. Everything else, by severity and how important the system is.

Keep it that simple. You are ranking, not calculating. The point is one ordered list that everyone agrees on, so nobody argues about what comes first on a Tuesday morning. It's the same idea I use for product bugs in fix the worst problems first.

Give every fix an owner

A ranked list is not a patch. Most vulnerabilities stall in the gap between "security found it" and "someone fixed it."

For each item near the top, I would record:

  • who owns the fix, by name or team;
  • which systems still need it;
  • the deadline, based on its rank;
  • the current status: not started, in progress, patched, or accepted with a reason;
  • any workaround in place until the patch is done.

Track this where the people doing the work already look. If the fix lives in a ticket system, the vulnerability should link to the ticket. If it lives in a spreadsheet nobody opens, it will not move.

Report what leadership needs to know

Leadership doesn't need a list of vulnerability IDs. It needs to know whether things are getting better.

A weekly report can answer that on one page:

  • how many exploited vulnerabilities are still open, and on which systems;
  • how many critical and high items are open, and how that compares with last week;
  • patch progress by type of system;
  • anything past its deadline, and why.

If the number of exploited-and-open items keeps going down, the team is doing the right work. If it goes up, you have a conversation to have, and the report shows exactly where.

Know what to accept

You will not patch everything. Some systems can't be patched without breaking something, some vendors are slow, and some risks are genuinely low.

That is fine, as long as the decision is written down. "Accepted, isolated system, no internet access, review in three months" is a decision. "We'll get to it" is not.

The short version

  1. Treat severity scores as a starting point, not a ranking.
  2. Put exploited vulnerabilities first, using public sources like the KEV catalog and EPSS.
  3. Map each one to your own systems and how exposed they are.
  4. Give every fix near the top an owner and a deadline.
  5. Report open exploited items weekly, not raw counts.
  6. Write down what you choose to accept.

I built a rough prototype of this idea, Sentinel. Its priority queue ranks vulnerabilities by exploitation first, then severity, and maps each one to the systems it touches. Try the demo. The vulnerabilities are real public ones, but the organisation and its systems are made up, and nothing is live.

How does your team decide what to patch first today? If you have a ranking that works for you, email me.

#Cybersecurity #Operations #Prioritization