Vulnerability Triage: A Beginner's Guide

Vulnerability triage is the process of evaluating, prioritising, and assigning remediation tasks to identified vulnerabilities based on real-world exploitability and business impact. Rather than working top-down by CVSS score, an effective triage process uses threat intelligence, asset context, and common sense to direct limited remediation resources where they matter most.

*Updated March 2026 to reflect changes in EPSS model version and KEV catalog scope.*

If you are responsible for fixing vulnerabilities, you already know the list is longer than the time available to address it.

Why Is Current Vulnerability Management Failing?

Times have changed and the simple fact is that if what we've been doing all this time worked, we wouldn't be seeing countless organisations spending hundreds of thousands in security programs being compromised every other week.

Statistically, on average, organisations will only manage to fix 10% of vulnerabilities. Yes, 10%. According to Kenna Security and Cyentia Institute's *Prioritization to Prediction, Volume 3: Winning the Remediation Race*, "the typical organization only fixes about 10% of its vulnerabilities in any given month" - and that holds true regardless of how many assets are in the environment. When we combine this with the fact that vulnerability exploitation is most likely to occur within the first month following the release of a patch, the problem becomes obvious: most organisations are slowest to act exactly when attackers are fastest to exploit.

What we can't do is magic up a 10-fold increase in resource or make days 240 hours long. What we can do is apply some form of intelligence, logic, and sound judgment to make sure the 10% we fix are impactful and have a meaningful reduction in real-world risk.

What Do You Need Before Starting Vulnerability Triage?

As with most topics in cyber security we could go on to write multiple books on vulnerability triage. However, for the purpose of keeping this short and sweet we are going to make some assumptions about your current security processes.

The main assumption we will make is that you perform some level of active security testing. This can range from full penetration tests and prolonged adversary emulation exercises to monthly vulnerability scans with one of the many vulnerability scanning products and solutions out there. It doesn't really matter which, so long as you're actively making some effort to identify security vulnerabilities across assets you control.

Whether it's hardware, software, process or people, the activity of identifying vulnerabilities is ultimately going to leave us with a list of issues that we need to address. Which is why we need to look at the whole Vulnerability Triage and Remediation process.

Traditionally we use CVSS

Traditionally, Penetration Testers will use a combination of the Common Vulnerability Scoring System (CVSS) and some form of impact & probability / risk metric to grade the severity of any identified vulnerabilities based upon the information they have available to them. Combined with the testers experience, report items will then be sub-ordered to ultimately provide a top-down technical report itemising the most severe to least severe vulnerabilities.

This still doesn't really work

While at first glance it appears that a lot of the hard work is done for us there will be many, many times in your cyber security journey, that will result in a High & Medium impact vulnerabilities being discovered that at first glance, all appear as critical as each other and need to be addressed as a matter of urgency, however when investigated are theoretical, have no public exploit code, have no available information and have never been used by a threat actor in a real world attack.

The result is that our 10% of fixes are directed at vulnerabilities that realistically will not be used against us and vulnerabilities that are genuinely posing a risk to the organisation remain unfixed. Obviously, this is bad.

What we need here, is a methodology that allows us to triage and fix vulnerabilities quickly, and effectively in line with realistic risk to ensure that our efforts are not wasted and make the most impact.

Why Does Vulnerability Triage Require a Formal Process?

For someone in a position of responsibility early in the cyber security process this can be a daunting task, particularly when individuals further up the chain of command are demanding immediate results.

Step 1. Take a breath and make a plan

The first thing we need to do before any level of active remediation effort takes place, is to come up with an effective remediation plan to ensure a structured approach is followed when deploying changes, as a result of security issues. Without these, one of two things are likely to happen:

1. "The task is too daunting; I have uptime and availability to worry about and this is not causing us an immediate operational impact. I will deal with this when I have time" - Spoiler Alert... The to do list never gets any smaller. The report will likely sit in a file share or a desk drawer until the next test comes around, a customer asks for evidence of security tests or, should the planets align you actually end up with the time to look into this.

1. "Let's just start at the top and work down". While this is infinitely better than the first outcome, due to the fact we're actually trying to address issues, this can still present problems. Problems can arise particularly where remediation efforts are allocated as a secondary task to normal day-to-day function. While we in no way want to disrupt the smooth operating of the organisation, if the task is not given the proper attention. We are likely going to start with the best intentions, but as other tasks get in the way the efforts tail off. The end result of this is that we remediate some or all of the high criticality vulnerabilities but don't consistently remediate all vulnerabilities.

If you fall into either of these categories, it's likely that you have two core problems. The first is that your vulnerability management process lacks enough allocated responsibility and/or resources. The second is that there is no process to analyse and triage the output of vulnerability identification exercises, so that we can produce an actionable plan that allows us to best align our efforts and yield the highest output in the shortest time.

Your Responsibilities

While not the primary objective of this blog post, it's still worth touching on the topic of responsibility. Responsibility, or more accurately the lack of it, is a common issue that particularly plagues small and medium enterprises. Just by reading this post, you are already demonstrating that you understand you have some level of responsibility for the protection of your customers' data. But with a million other things to do and budget dictating that hiring dedicated resource is unfeasible, you are going to have to work with your existing teams to be sure that these vulnerabilities get fixed.

It's worth remembering that, while the responsibility for deploying fixes at a tactical level can be delegated to relevant teams, the overall responsibility for the protection of data still lies with you. Make sure you track your team's efforts and allocate timelines that are both achievable and ensure remediation is completed before something bad happens. Once fixes get tested and deployed, ensure that efforts are made to retest so that we can ensure fixes are effective and deployed correctly.

Too many times changes are made without proper understanding of the issue, or worse, with a slapdash "just get it done" approach. The result of either of these is often the continued existence of the security vulnerability under the false understanding that the issue has been fixed. This can all be managed with a proper "Test & Deploy" process, but that's for another post.

Step 2. Set up a Triage team

However, before we allocate tasks to the relevant teams, we must perform our triage process. For this we need to delegate a separate team whose core function within the vulnerability management process is to rapidly analyse and prioritise incoming vulnerability data. This team will be known as the 'Vulnerability Triage Group' (VTG) and should hold between its members experience in the organisation's IT management, general cyber security risk and wider business risk.

The bottom line is that while you are responsible for the overall protection of your commercial, staff and customers data, you will likely need to work with several teams to implement a complete vulnerability management process. Prioritisation is the responsibility of a core group (the VTG) who have enough significant experience to understand the issues and their impact within your business context.

How Do You Triage Vulnerabilities Effectively?

Responsibility is assigned, the VTG is in place, and you have a pile of findings to work through. The goal now is the same as any good strategy: maximum impact in the least number of moves.

The NCSC's Vulnerability Management guidance is good background reading for this stage, and the steps below lean on its core principles.

Why Should You Not Triage Vulnerabilities by CVSS Score Alone?

We've already said vulnerabilities are ordered by CVSS. So why invest the time and resources into triage when it's basically done for us? Surely, we can just get stuck in.

The answer is no - a top-down CVSS approach is not sufficient.

Let's look at an example: AcmeOrg has around 20 members of staff, and a small IT team of one or two people. For the sake of argument an experienced technician and a junior in training. The CEO has been alarmed by the increasing number of cyber-attacks they see on the news and as such has allocated some budget to perform a penetration testing exercise. Having just performed their first penetration testing exercise across all their assets, from both external and internal perspectives, the team gets dumped with 2 very large reports - 47 findings across internal and external assessments - with a load of red and orange all over them. The CEO reads the report and understands that the issues are not a reflection of the current teams' efforts, but rather the nature of security coupled with a resource issue... After all, their company is growing and so should their IT team to support them. They tell you that you can sit down with them, go through the Cyber Security Skills Matrix and create a job posting to fill a more permanent position. Everything seemed to be going smoothly - so what was the catch?

"In the meantime, we need you to sort all of this report out ASAP. Go get me a timeline"

We still only have a team of two and there's a lot of vulnerabilities... Where do I start? The report is ordered by CVSS so I'll just start at the top and work down and come up with the arbitrary figure of 2 weeks because I really don't know how long it's going to take and you can get a lot done in 2 weeks.

The reality is that across those two reports, some CVSS 9 vulnerabilities are going to be less dangerous in practice than some CVSS 7.5 vulnerabilities. Take the locally exploitable missing Microsoft patch on the machine in the corner - sat on its own VLAN, no outbound access, no network path to exploitation. It scores CVSS 9. It matters, but it is not today's problem.

Now look at CVE-2021-41773: a path traversal vulnerability in Apache HTTP Server 2.4.49, scored CVSS 7.5. It is on the public-facing web server. It is in the CISA KEV catalog, which means real attackers are actively using it right now. A proof-of-concept exploit was available within days of disclosure. Its EPSS score is 0.944 - placing it in the 99.97th percentile of all known vulnerabilities by exploitation likelihood. That is not a 7.5. That is a Priority 1, regardless of what the report cover page says.

After VTG triage, those 47 findings look very different. Two of the original CVSS-9 findings move to Acknowledge. One CVSS-7.5 finding gets elevated to Priority 1. The active Fix list drops from 47 items to 12. By the end of week one, all 12 are done - versus an estimated six weeks if the team had started at the top and worked down.

So, if we take this top down approach the obvious result is that were spending time remediating vulnerabilities that are not likely to be exploited instead of fixing vulnerabilities that are more likely to be exploited for direct impact or used as part of a wider kill chain. Which is not ideal. Taking a little bit of extra time to come up with an effective plan is going to be much more efficient than just spraying update commands across everything we can see.

How Do You Categorise Vulnerabilities During Triage Planning?

Instead, we could take a morning to assemble our VTG and go through the reports to come up with an effective plan.

One objective of the Vulnerability Triage Group is to categorise vulnerabilities under three labels: Fix, Acknowledge, Investigate.

Fix

We're going to prioritise and deploy fixes for these issues. Regardless of the CVSS, these vulnerabilities pose a risk to our organisation and our ability to maintain Confidentiality, Integrity or Availability (CIA) of our data and systems.

Acknowledge

We understand these issues exist, but they aren't a priority right now, we'll justify why we aren't fixing them (In documentation!) and we'll re-evaluate the issues at a later date.

Investigate

We are not sure if we need to fix or acknowledge this vulnerability. There are unknowns that are blocking further action. We're going to allocate a completion date and investigate in the interim to get more information, so we can move the vulnerability to either the Fix or Acknowledge categories.

A note on Acknowledgment - It can be tempting at times to just "accept the risk" and start lumping everything into the Acknowledge category. Ultimately this is a business decision, but whenever something ends up in this category you need to document exactly WHY this issue is being acknowledged with sound enough justification. So that if you are compromised and this vulnerability gets exploited you can justify why you didn't fix it to third parties... remember... by knowing it's there you're no longer ignorant and your decisions now could have serious ramifications down the line.

At this point, we're making progress, we've started to document a vulnerability management process that we can use to align our efforts and make a real impact on our organisation's security. But how do we decide what vulnerability goes into what box?

Step 3: Prioritise

To prioritise vulnerabilities, it naturally boils down to two questions:

1. How exploitable is this vulnerability?
2. If it gets exploited what's the worst that's going to happen?

This line of thinking naturally dictates that externally facing vulnerabilities that will allow an attacker to gain access to data, accounts, systems and anything else we don't want them to access are going to be a priority. However, ensure you don't get tunnel vision. On the ground, networks are seldom built with the classic network boundary we all know and love. We're integrating systems all over the place. From Azure to AWS and Online CRMs the traditional network boundary is becoming blurred. So, make sure you really take time to think about the vulnerability impact and how it will be exploited. This is where the teams wider experience comes into play since the impact of exploitation is at both a technical and business level. For example, we at a tactical level, care an awful lot more about the Remote Code Execution (RCE) vulnerability than the Local file Inclusion (LFI). However, in the wider operating environment we care an awful lot more about the LFI on systems holding our Critical Data that we do about the RCE on a stand-alone printer in the guest network.

Which Threat Intelligence Sources Should You Use for Vulnerability Triage?

As we've previously mentioned, we need to direct our efforts towards things that have a higher probability of use against our organisation. The problem is that understanding this requires accurate, up to date and actionable real-world intelligence. Thankfully there are some public data sources here that can help us.

CISA Known Exploited Vulnerabilities List (KEV)

The US Government Cybersecurity & Infrastructure Security Agency (CISA) produce the Known Exploited Vulnerabilities Catalog, which currently lists over 1,500 vulnerabilities confirmed to be actively exploited in the wild (1,531 entries as of March 2026). If one of your vulnerabilities is on this list, you need to fix it as a priority because it is being actively used against real organisations right now. Check the catalog as a first step whenever a new vulnerability reaches your triage queue - a KEV listing is an immediate escalation to Fix.

Exploit Prediction Scoring System (EPSS)

The Exploit Prediction Scoring System (EPSS) is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. Maintained by FIRST and currently operating on the EPSS v3 model (released March 2023), it scores all CVEs published in the National Vulnerability Database - over 200,000 at the time of writing - refreshing every day.

EPSS assigns each CVE a probability that it will be exploited within the next 30 days if seen by an attacker. A score above 0.1 (10%) is commonly used by practitioners as a meaningful exploitation-likelihood threshold. CVE-2021-41773 - the Apache path traversal example above - carries an EPSS score of 0.944 (99.97th percentile) as of March 2026, meaning it is more likely to be exploited in the next 30 days than 99.97% of all known vulnerabilities. That kind of signal cuts straight through the noise of a report full of amber and red.

More information and access to the data feed is available at EPSS - Exploit Prediction Scoring System (FIRST.org).

Other Threat Intelligence Sources

CVSS, EPSS, and CISA KEV give you the public-data foundation, but a complete triage picture often requires additional context. GreyNoise analyses internet-wide scanning data and can tell you whether a vulnerability is being actively probed across the internet - sometimes before it reaches the KEV catalog. Shodan can show you which of your own assets are exposed and what software versions they are running, so you can cross-reference your vulnerability list against your real attack surface. Vendor security bulletins and patch notes often flag active exploitation before CISA updates the KEV list, so subscribing to advisories from your key vendors (Microsoft Patch Tuesday, Cisco PSIRT, Apache security announcements) gives you an early warning. For more mature programmes, dark web monitoring services can surface threat actor discussion about specific CVEs before exploitation becomes widespread.

What Common-Sense Questions Help Prioritise Vulnerabilities?

Sound judgment is another great way to supplement the above information and start triaging vulnerabilities. For each vulnerability in your triage queue, work through the following questions. Brief answers are provided to guide your thinking - but the context of your own environment is always the deciding factor.

• Does this system hold critical data, or is it connected to systems that do? The more sensitive the data accessible from a compromised system, the higher the priority - even if the vulnerability's CVSS score seems modest.
• Is there exploit code available for this vulnerability and, if so, is it public? A PoC on GitHub means a script kiddie can run it. Treat publicly available exploit code as a significant escalation factor.
• Is it being exploited actively in the wild? Check CISA KEV first, then EPSS score, then threat intelligence feeds. If it is already on the KEV list, it goes straight to Fix - no debate needed.
• What does successful exploitation give an attacker access to, and what systems can they reach from there? Think laterally. A low-severity vulnerability on a jump host that touches everything else is not low severity in your environment.
• What are the chances this has been exploited already? If the vulnerability is old, public, and on an internet-facing system, assume compromise until you can prove otherwise. At that point you may need to shift from remediation mode to incident response and start looking for Indicators of Compromise.
• How easy is it to detect exploitation of this vulnerability? A vulnerability that leaves no log trace when exploited is harder to catch after the fact - which makes preventing it more important.
• If this issue is exploited, does it make any other vulnerabilities exploitable? One vulnerability that enables lateral movement or privilege escalation can turn a minor finding into a full compromise. Factor in the chain, not just the link.
• How old is the vulnerability? The older and more public a vulnerability is, the more likely that working, weaponised exploit code exists for it. Age is not a measure of severity - it is a measure of exposure time and exploit maturity.
• How much is it going to financially cost to fix this issue? Sometimes the cost of remediation is disproportionate to the risk. Cost is a legitimate triage input - it affects what ends up in Acknowledge vs Fix. (Quantified risk analysis is a topic for another post.)
• How much time needs dedicating to fixing the issue? Know this before you commit a timeline. A configuration change and a vendor patch cycle are completely different problems.
• Who is responsible for the asset? No fix happens without an identified owner. If nobody owns it, the vulnerability will sit there.
• Who is responsible for the fix? Asset owner and fix owner are not always the same person. Sort this out before you assign any tickets.
• Do we need to engage any third parties to address this issue? Vendor patches and cloud provider actions have timelines outside your control. Identify these dependencies early so they do not blindside you.
• Are there any temporary mitigations we can put in place pending further investigation? Firewall rules, network segmentation, disabling a feature - compensating controls can reduce real risk while a permanent fix is being prepared.
• Has this vulnerability been identified previously, and risks accepted? If so, what is the Risk ID - and has anything changed since? A vulnerability that was safely acknowledged eighteen months ago may now be KEV-listed. Re-evaluate; do not just re-accept.

By answering the above questions, we can start to gain a deeper understanding of the vulnerabilities that exist across our assets and as such start to come up with an actionable plan that allows us to make the biggest impact in the least amount of time. Understandably though, these questions require a level of both business and technical input, which in many situations we may not possess. Don't be afraid to lean on your preferred security consultancy for help in understanding the issues. But, if you're really stuck, flustered and don't have the time to perform a full vulnerability triage exercise the following guidelines from the NCSC are a good place to start:

Priority 1: Fix Internet services and off-the-shelf web applications that can be exploited automatically across the Internet with no user (or attacker) interaction.

Priority 2: Fix bespoke/niche web applications that can be exploited across the Internet with no user (or attacker) interaction.

Priority 3: Fix Issues that can be exploited across the Internet with minimal user interaction (workstation vulnerabilities, drive-by downloads, email-based attacks).

Priority 4: Fix issues that can be exploited across the Internet with social engineering of users (malicious applications downloaded from the web or sent via email). These attacks require your users to play a part.

Compensating Controls

It's a fact of life (for the majority of us at least) that we can't afford everything we want, sometimes closing a security vulnerability in the most ideal way is going to cost far too much. It's also a fact of life that phishers are going to phish, no matter what you're told by a security vendor you aren't going to stop 100% of those emails hitting your users. Finally, it's also a fact of life that no matter how much we all want to pretend it isn't true, some systems just can't be upgraded.

When you find yourself in any of these positions we can't just say "well we can't fix it so why bother?"; we need to make the best of a bad situation. We can't implement the ideal fix, so we need to introduce compensating controls. These are changes we can make to reduce and contain the overall risk posed by the vulnerability to an acceptable level. For example, an aged legacy system that can't be patched might be better protected by a dedicated firewall and a segmented network.

Be under no illusion compensating controls can often be more difficult to implement than the ideal fix. They are in no way the easy and cheap option and should only be used when there is an absolute blocker on the preferred remediation.

Conclusion

One underappreciated consequence of poor triage is the compounding effect on team morale and organisational trust. When engineers spend weeks patching theoretical vulnerabilities while something genuinely exploitable sits unaddressed, the inevitable breach does not just cost money - it damages confidence in the security function itself. A defensible, documented triage process gives teams clarity on what they are doing and why, and gives leadership the evidence needed to understand that effort is being directed at real risk rather than administrative compliance.

At Precursor, we already do much of what is described here for our clients as part of our normal service offering. Across our engagements, we have been able to reduce clients' average Time-To-Remediate (TTR) to 3.8 days from vulnerability discovery by one of our testers to confirmed remediation - while ensuring those efforts are focused on real-world risk rather than theoretical severity scores.

Completing an initial triage exercise is a starting point, not a finish line. Once your Fix list is remediated, schedule retesting to confirm fixes are effective and deployed correctly. Set a recurring review cadence for your Acknowledge decisions - a risk accepted six months ago may now be KEV-listed and require immediate escalation. As your programme matures, topics like EPSS score querying, CVSS v4.0 severity modelling, and quantified financial risk analysis (all flagged as "another post" above) become the next layer of precision to layer onto the foundation described here.

If you would like support implementing a structured vulnerability triage programme, get in touch with the Precursor team.

Frequently Asked Questions

What is the difference between vulnerability triage and vulnerability management? Vulnerability management is the end-to-end programme: discovery, triage, remediation, verification, and reporting. Vulnerability triage is a specific step within that programme - the process of evaluating and prioritising identified vulnerabilities before remediation begins. Good triage is what makes a vulnerability management programme efficient rather than merely busy.

Is CVSS score enough to prioritise vulnerabilities? No. CVSS measures theoretical technical severity based on the characteristics of a vulnerability in isolation. It does not account for whether exploit code is publicly available, whether the vulnerability is being actively exploited in the wild, or whether the affected system is internet-facing and holds critical data. EPSS and CISA KEV provide the real-world exploitation signal that CVSS cannot.

What is the CISA KEV catalog and why does it matter? The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities confirmed to be actively exploited in real-world attacks. As of March 2026 it contains over 1,500 entries. Any vulnerability on this list should be treated as an immediate Fix - it is not theoretical. Federal agencies in the United States are required to remediate KEV entries within mandated deadlines; UK organisations should treat KEV listings as the clearest available signal that a vulnerability demands priority attention.

What is a Vulnerability Triage Group (VTG)? A VTG is a small cross-functional team responsible for evaluating and prioritising vulnerabilities before remediation tasks are assigned to asset owners. Effective VTG membership spans IT management, cyber security risk, and wider business risk - ensuring that triage decisions account for both technical exploitability and business impact. The VTG is not responsible for fixing vulnerabilities; it is responsible for deciding in what order, and with what urgency, fixes should be deployed.

When should a vulnerability be placed in the Acknowledge category rather than Fix? A vulnerability belongs in Acknowledge when the realistic risk it poses - after considering exploitability, asset exposure, available exploit code, and business context - is judged to be acceptable without remediation, and that judgment can be documented and defended. It should never be a shortcut to avoid difficult fixes. If the risk profile changes (for example, the vulnerability appears on the KEV catalog, or a public PoC is released), Acknowledge decisions must be reviewed and escalated if necessary.