Organisations commonly rely on CVSS (Common Vulnerability Scoring System) scores of a vulnerability to understand their security posture. While this approach helps identify technical weaknesses, it often fails to answer a more important question:
What is the actual risk to the business if a vulnerability is exploited?
CVSS provides a measure of technical severity, but it does not account for exploitability in a real environment, the value of the affected asset or the operational impact of exploitation. To make effective remediation decisions, vulnerabilities must be evaluated in a broader context.
This blog explains why CVSS alone is insufficient, what an accurate risk assessment looks like in practice, and how organisations can move toward prioritisation that reflects real world impact.
CVSS: Useful, but Incomplete
CVSS was designed to provide a consistent, vendor neutral way of comparing vulnerabilities across different systems. It evaluates attack vector, attack complexity, required privileges, user interaction, and potential impact to confidentiality, integrity and availability. For that purpose, it works well.
The problem is what it deliberately excludes. CVSS is context free by design. It does not consider how a system is deployed in your environment, whether exploitation is realistic given your controls, or what downstream systems depend on the vulnerable component.
A CVSS 9.8 vulnerability on an air gapped system accessible only by two administrators carries very different risks from the same vulnerability on an internet facing customer portal. CVSS treats them identically.
As a result, CVSS alone cannot accurately represent business risk.
Vulnerability vs Business Risk
A vulnerability is a technical condition, a flaw in code, configuration or design that could be exploited. Risk is the likelihood of exploitation combined with the business impact of that exploitation.
Consider two examples:
- A critical vulnerability on an isolated administrative system may have limited business impact
- A moderate vulnerability on a shared service supporting multiple business applications may pose a significant risk
Understanding this difference is not optional. It is the foundation of any effective remediation programme.
Exploitability in a Real Environment
Exploitability is not a binary condition. It is not simply whether a vulnerability exists, but whether an attacker can reliably abuse it given your specific configuration, network architecture and access controls.
The following factors directly influence this assessment:
1. Accessibility of the Vulnerable Component
- Is the system internet-facing, partner-facing or internal-only?
- Can the vulnerable service be reached directly by an attacker or does it require prior access?
- Is access restricted by network controls or application logic?
2. Authentication and Privilege Requirements
- Does exploitation require authentication? If so, how easy are credentials to obtain?
- Are elevated privileges required or can a low privileged or unauthenticated user reach the vulnerable functionality?
- Does the exploit chain depend on social engineering or user interaction and is that realistic for your threat model?
3. Impact on Confidentiality, Integrity and Availability
- Confidentiality: Can sensitive or regulated data be disclosed?
- Integrity: Can data or system behaviour be modified in ways that affect business decisions or operational outcomes?
- Availability: Can the system or dependent services be disrupted and what is the downstream effect??
A vulnerability that only degrades availability on a non-critical batch processing system may be low priority. One that silently corrupts transactional data in a payment system, even with a moderate CVSS score, could have severe business consequences.
4. Component Interaction and Dependency
- Is the vulnerable component shared across multiple systems?
- Does exploitation allow interaction with databases, identity systems or message queues?
- Could compromise of this component be leveraged to affect other services?
This is particularly important in modern environments where applications rely on shared infrastructure and services.
Asset Value and Business Context
The severity of a vulnerability cannot be assessed independently of the asset it affects. A system’s role in the organisation determines the potential impact of its compromise.
Key considerations include:
- Does the system support revenue-generating services or critical operations?
- Does it process or store sensitive data?
- Is it a shared platform or foundational service?
- Would its compromise affect multiple teams or business units?
Vulnerabilities affecting foundational components often introduce systemic risk that extends far beyond the component itself. A moderate finding on one of these assets may represent greater overall risk than a critical finding on a standalone, low value system.
Translating Technical Impact into Business Impact
Security findings must ultimately be communicated in terms that enable informed decision making by people who are not security specialists. The table below illustrates how technical findings translate to business outcomes.
| Technical Finding | Technical Impact | Business Impact |
|---|---|---|
| Insufficient server side validation allows modification of request parameters | Integrity of data cannot be guaranteed. Authorisation controls can be bypassed | Risk of fraud, manipulation of records, regulatory concerns and loss of trust in outputs |
| Unauthenticated API endpoint exposes internal service data | Sensitive data accessible without credentials. No audit trail for access | Potential data breach, regulatory fines and reputational damage depending on data classification |
| Outdated third party library with known RCE vulnerability | Remote code execution possible on affected server | Full system compromise and potential pivot to internal network and downstream services |
This translation matters because it changes the conversation. A finding described as “insufficient server side validation” is easy to deprioritise. The same finding described as “an attacker could modify transaction records, bypassing financial controls” is not.
Understanding Risk Through Attack Paths
In practice, attackers rarely rely on a single vulnerability. Instead, they exploit how systems interact. This is one of the most important concepts in realistic risk assessment and one that CVSS scores are structurally unable to capture.
A vulnerability may:
- Provide access to internal services
- Expose credentials or tokens
- Allow interaction with shared infrastructure
- Enable further exploitation of dependent systems
Penetration testing focuses on identifying these attack paths and demonstrating how an initial weakness can lead to broader compromise, even when individual findings appear moderate in isolation.
A Practical Risk Prioritisation Framework
Moving beyond CVSS does not require abandoning it, it requires using it as one input alongside others.
The following factors should be considered when prioritising remediation:
| Factor | Key Question | |
|---|---|---|
| Realistic exploitability | Can this actually be exploited in your environment, accounting for access controls and compensating measures? | |
| Exploit intelligence (EPSS/KEV) | Is this vulnerability being actively exploited in the wild? Is it on the CISA KEV catalogue? | |
| Asset criticality | What is the business function of the affected system? What depends on it? | |
| CIA impact in context | What data or functionality is at risk, and what are the consequences of loss? | |
| Downstream exposure | Could compromise of this component be used to reach other systems or escalate further? | |
| Compliance obligations | Does this vulnerability create exposure under DORA, NIS2, ISO 27001 or other applicable frameworks? |
This approach allows organisations to focus remediation efforts where they will most effectively reduce risk, rather than addressing vulnerabilities based solely on numerical severity.
Regulatory Context: Why Risk Based Prioritisation Is Increasingly Mandatory
For organisations operating under DORA, NIS2, ISO 27001 or sector specific frameworks, risk based vulnerability management is not just best practice, it is a requirement. These frameworks share a common expectation that organisations understand the risk posed by vulnerabilities to critical business functions, not just their technical severity.
DORA, for example, requires financial entities to test critical systems under realistic threat scenarios and demonstrate that vulnerabilities affecting ICT services are identified and addressed proportionate to their business impact.
NIS2 places similar obligations on operators of essential services.
ISO 27001 requires that organisations maintain a risk treatment process that considers the likelihood and impact of exploitation in their specific context.
Continuing to triage primarily by CVSS score introduces both security and compliance risk. Auditors and regulators increasingly understand the distinction between severity and business risk.
The Value of Penetration Testing
Automated vulnerability scanning identifies known weaknesses efficiently. It does not assess whether those weaknesses are actually exploitable in your environment, how they interact or what the real impact of exploitation would be.
Penetration testing fills this gap by simulating realistic attacker behaviour. A skilled tester does not simply report what a scanner found, they demonstrate what an attacker could achieve, including chained attack paths that individual findings do not suggest. They validate exploitability, identify impact to critical assets and produce findings that can be directly mapped to business risk.
This makes penetration testing findings significantly more actionable than scanner output. Instead of a list of vulnerabilities ranked by CVSS score, leadership and security teams receive a clear picture of what is at risk, what an attacker would actually do and where remediation efforts will have the greatest impact.
Making Better Vulnerability Decisions
CVSS remains a useful reference point, but it was never designed to represent business risk.
Accurate risk assessment requires the understanding of:
- How a vulnerability can be exploited in your environment
- What data and systems are affected
- What compensating controls exist
- The operational and business impact of exploitation
Organisations that make remediation decisions based solely on CVSS scores are prioritising based on theoretical severity rather than actual exposure. Those that incorporate exploitability, asset criticality, attack path analysis and business context make better decisions with the same resources.
Understand Your Real Risk
If you want to move beyond severity scores and understand what vulnerabilities mean for your business, we can help.
Our penetration testing engagements are built around realistic exploitability, asset context and clear business impact, giving your team the information needed to make confident remedication decisions.
Get in touch using the form below to chat to our team. ⬇️