7 Questions To Ask When Auditing Your IT
Business growth does not happen overnight, nor does it happen without addressing what is working well and what isn't working well within an...
Blaine Kahle : Oct 21, 2024 7:30:00 AM
3 min read
The phrase “patch all critical vulnerabilities within X days” is misleading, because “critical” in public scoring (CVSS) is not the same as “highest risk to your business.”
Real-world patching should be driven by risk: adjust CVSS scores for your environment, use data like EPSS to see what is likely to be exploited, and then prioritize accordingly.
If you re-score and prioritize vulnerabilities in context, you can honestly focus on what matters most instead of chasing every “critical” label on a fixed-day timer.
If you've dealt with an audit, cyber insurance, or third-party vendor due diligence, you've probably seen some variant of that question above. The dirty IT secret is, I bet not a single organization can answer yes – not if they're being 100% true to the question, as stated and implied.
Many factors affect the criticality and timeliness of vulnerability patching, for example:
When was the vulnerability published vs when did your organization become aware of it?
Is a patch available (yet)?
Is your organization in control of the system? Perhaps it's managed by someone else.
What's the maintenance window? Some systems are so critical that downtime for maintenance is only permitted at certain intervals.
What's the actual Risk to your organization?
...What's that last one? Risk? Isn't the title "critical" the indicator of risk?
It's not! At least, it's not that simple. Let's dive in...
Most software security vulnerabilities are scored using the Common Vulnerability Scoring System (CVSS). In fact, America's cyber defense agency (CISA) and the National Institute of Standards and Technology (NIST)'s National Vulnerability Database rely on CVSS scoring when publicizing the latest cyber threats.
Yet, the very second sentence of NIST's summary of the CVSS is, "CVSS is not a measure of risk" (and the bold text comes from them!).
The CVSS score assigned to each vulnerability is a way of scoring the potential severity of a threat, and the likelihood of it happening, absent other factors. This scoring system is both an indicator of potential severity and a resource for calculating the severity specific to your organization.
To evaluate the actual risk of a particular vulnerability, first the environmental aspects must be considered. The CVSS Base Score (the published score) is functionally the "worst case scenario" for that particular issue, but how it maps to your specific organization's characteristics might alter the practical risk to you.
Seems intuitive, yes? That's why the CVSS calculators, all the way back to version 1.0 in 2005, have always included an "environmental" section of factors! Since that section is specific to each organization, it's left blank by default when calculating the CVSS Base Score. And rarely do organizations use it...
So how does this recalculate the threat of a particular vulnerability? Let's go through a hypothetical rescoring situation to see:
Take a CVSS v3.0 score of 9.8 out of 1.0 – a "near worst case" vulnerability, where the attacker can easily exploit the vulnerability without anyone else's involvement, over the internet, no credentials required, and it compromises the entire software package.
What if you have that software, but it's only accessible from within your organization? It's not exposed to the internet; the attacker can't easily "reach out and touch it." If you change the CVSS "attack vector" metric to "adjacent network", that vulnerability score drops to 8.8, a "High" instead of a "Critical" score.
Now what if the impact of that system being hacked is not significant to your organization? Perhaps it's a single system in its own demilitarized zone (DMZ) segmented from your primary business operations, the data it contains is not of high value, and you can rebuild the whole thing without much effort. Setting these three impact metrics to "low" results in a new final score of 6.9, a "Medium" risk. That significantly changes how you prioritize this theoretical vulnerability.
And there's that magic word: Prioritize. That's ultimately the point of any of these evaluations – whether by your cyber insurance provider or an auditor – to gauge how you manage practical risk factors and prioritize them. Like any other aspect of risk management, you can never take care of everything, and never all at once. No organization has unlimited money and unlimited time for IT security improvements. You must prioritize the risks that are most probable and are of higher impact to you.
So which critical vulnerabilities should you address first? This is where the newer Exploit Prediction Scoring System (EPSS) comes into play. The EPSS comes from the same working group that publishes the CVSS model, "FIRST".
If a vulnerability is not already being exploited (zero-day), then there's a window to secure systems before hackers begin to exploit the published vulnerability. By providing a data-driven model to predict which vulnerabilities are most likely to be exploited (and thus might be exploited sooner than others, if at all), EPSS can help you confidently determine what to patch or otherwise secure first in your organization.
EPSS should not be used alone without considering the environmentally-adjusted CVSS score, as well as other risk factors specific to your scenario.
For a primary on EPSS, visit this guide: https://www.first.org/epss/user-guide
If you evaluate and re-score every vulnerability first, then perhaps you can safely answer yes!
It's understandable, though, that this article may have raised more questions for you than it did answers. That's okay – risk management is a complex job best left up to IT security experts. If you're in need of some IT expertise or assistance with risk management in your organization, reach out to an expert here at Five Nines. We're here to help!
Because it assumes every “critical” vulnerability in the public database carries the same urgency and impact for every organization. In reality, you may not even know about some vulnerabilities on day one, patches may not exist yet, vendors may control certain systems, and some assets are too sensitive to patch immediately without careful planning. A literal “yes” would require unlimited staff, zero change constraints, and instant awareness — conditions that do not exist in any real environment.
A CVSS base score (for example, 9.8) reflects the theoretical technical severity and exploitability under worst‑case, generic conditions, ignoring your specific environment. Even NIST emphasizes that CVSS is a severity measure, not a direct risk measure. It tells you how bad something could be, not how bad it will be for you given your architecture, exposure, and controls.
You adjust for context. That includes: how the system is exposed (internet‑facing vs internal only), network segmentation, the sensitivity and business value of the data it holds, how easy it is to rebuild, and any compensating controls you already have. When you plug those environmental factors into a CVSS calculator, a base “critical” may reasonably drop to “high” or “medium” for your environment, which changes how urgently it must be patched.
EPSS (Exploit Prediction Scoring System) adds a data‑driven view of likelihood by estimating how likely it is that a given vulnerability will be exploited in the wild. Used together, an environmentally adjusted CVSS (impact for you) plus EPSS (likelihood of exploitation) gives you a much better basis for deciding what to fix first, instead of treating every public “critical” as equally urgent by the same deadline.
Internally, build and document a risk‑based patching process:
Triage new vulnerabilities with CVSS and your environmental factors.
Use EPSS and threat intel to highlight those most likely to be exploited.
Define SLAs by risk tier (e.g., high‑risk internet‑facing issues patched within X days, medium within Y, etc.).
Then, when you respond, you can accurately say you patch high‑risk vulnerabilities within defined timeframes according to a formal risk‑based process — rather than pretending every public “critical” gets fixed in an identical number of days regardless of real impact.
Business growth does not happen overnight, nor does it happen without addressing what is working well and what isn't working well within an...
As long as old computers are still running with limited problems, they don't need to be replaced...right? It may seem easy to place these updates on...
Do you feel as though your IT environment is a sinking ship that you are trying to keep afloat? Keeping your IT environment efficient is the best...