Understanding Vulnerability Severity Levels: CVSS Scores Explained
CVSS scores classify vulnerabilities as Critical, High, Medium, or Low. Learn what each level means, how to prioritise remediation, and SLA recommendations per severity.
What is CVSS?
The Common Vulnerability Scoring System (CVSS) is the industry standard for assessing the severity of security vulnerabilities. It assigns a numerical score from 0.0 to 10.0, where higher scores indicate greater severity.
CVSS is maintained by FIRST (Forum of Incident Response and Security Teams) and is used by vulnerability databases like the National Vulnerability Database (NVD), security scanners, and incident response teams worldwide.
The current version is CVSS v4.0, although many tools still use CVSS v3.1. The core concepts are the same across versions.
CVSS score ranges
| Score Range | Severity | Colour (common) |
|---|---|---|
| 9.0 -- 10.0 | Critical | Red |
| 7.0 -- 8.9 | High | Orange |
| 4.0 -- 6.9 | Medium | Yellow |
| 0.1 -- 3.9 | Low | Blue/Green |
| 0.0 | None | Grey |
What each severity level means in practice
Critical (9.0 -- 10.0)
Critical vulnerabilities can be exploited remotely with little or no user interaction and lead to complete system compromise. Think:
- Remote code execution without authentication (e.g., EternalBlue, Log4Shell)
- Exposed database ports with no authentication (see exposed database ports)
- Default credentials on internet-facing admin panels
- SQL injection on authentication endpoints
What this means for you: An attacker can compromise your system right now, likely with automated tools. Every hour this remains unpatched increases the probability of breach.
High (7.0 -- 8.9)
High severity vulnerabilities are serious but may require some preconditions to exploit -- like user interaction, authenticated access, or specific configurations. Examples:
- Cross-site scripting (XSS) on a page that handles sensitive data
- Missing email authentication allowing domain spoofing (see email spoofing prevention)
- Privilege escalation from a low-privilege account
- Weak TLS configurations that could enable traffic interception
What this means for you: Exploitation is realistic but may not happen immediately. Prioritise these right after criticals.
Medium (4.0 -- 6.9)
Medium vulnerabilities require more specific conditions to exploit or have a limited impact. Examples:
- Information disclosure that reveals internal paths or version numbers
- Missing HTTP security headers (see HTTP security headers)
- DMARC policy at
p=none(monitoring only, not enforcing) - Weak cipher suites that could theoretically be exploited
What this means for you: These are unlikely to be the first thing an attacker goes after, but they weaken your overall posture and may be combined with other findings in an attack chain.
Low (0.1 -- 3.9)
Low severity vulnerabilities have minimal impact or are very difficult to exploit. Examples:
- Minor information disclosure (server version in headers)
- Self-XSS (only affects the user who triggers it)
- Verbose error messages that reveal technology stack
- Non-sensitive cookie without the Secure flag
What this means for you: Not urgent, but cleaning these up improves your overall security hygiene and audit readiness.
How to prioritise remediation
CVSS scores are a starting point, not the final word. Smart prioritisation considers additional factors:
Exploitability
Is there a known exploit in the wild? A vulnerability with a CVSS of 7.5 and a public exploit is more urgent than a vulnerability with a CVSS of 9.0 that is theoretical.
Check:
- CISA Known Exploited Vulnerabilities (KEV) catalog
- Exploit-DB
- Vendor security advisories
Exposure
Is the vulnerable system internet-facing or internal only? A medium-severity vulnerability on a public web server is often more urgent than a high-severity vulnerability on an isolated internal system.
Business impact
What data or functionality does the affected system handle? A medium-severity finding on your payment processing system may deserve higher priority than a critical finding on a development sandbox.
Compensating controls
Are there other security measures that reduce the risk? A SQL injection vulnerability behind a WAF and on an internal network is less urgent than the same vulnerability on a directly exposed endpoint.
Why not all criticals are equally urgent
Consider two critical vulnerabilities:
- CVE with CVSS 9.8 -- remote code execution in a library your public-facing web server uses, with a Metasploit module available and active exploitation in the wild
- CVE with CVSS 9.1 -- remote code execution in a library used only by an internal tool, no known exploits, requires authentication
Both are "critical," but the first demands immediate action while the second can be scheduled for the next maintenance window. Context turns a CVSS number into a real-world priority.
Risk-based prioritisation framework
A practical approach combines CVSS with context:
| Factor | Priority boost | Priority reduction |
|---|---|---|
| Known exploit in the wild | Treat as higher severity | -- |
| Internet-facing | Treat as higher severity | -- |
| Handles sensitive data | Treat as higher severity | -- |
| Behind WAF/firewall | -- | Can deprioritise slightly |
| Internal only | -- | Can deprioritise slightly |
| Low-value system | -- | Can deprioritise slightly |
SLA recommendations per severity
Remediation SLAs set clear expectations for how quickly vulnerabilities must be fixed. These are widely adopted benchmarks:
| Severity | Recommended SLA | Aggressive SLA |
|---|---|---|
| Critical | 48 hours | 24 hours |
| High | 7 days | 3 days |
| Medium | 30 days | 14 days |
| Low | 90 days | 30 days |
These SLAs should be documented in your vulnerability management policy. If you are pursuing ISO 27001 certification, auditors will specifically ask about your remediation timelines and whether you are meeting them.
What to do when you cannot meet the SLA
Sometimes a vulnerability cannot be patched within the SLA -- perhaps because the patch requires a major upgrade, or there is no patch available yet. In these cases:
- Document the exception with a clear justification
- Implement compensating controls -- WAF rules, network segmentation, disabling the affected feature
- Set a review date to reassess the risk
- Escalate to management if the risk is critical
This exception process is a key part of NIS2 compliance and ISO 27001 audit readiness.
How this maps to ISO 27001
ISO 27001 control A.8.8 (Management of technical vulnerabilities) requires a documented process for handling vulnerabilities. Your severity levels and SLAs are the operational core of this process.
Auditors will check:
- That you have defined severity levels (CVSS or equivalent)
- That remediation SLAs exist for each level
- That you are actually meeting those SLAs (with evidence)
- That exceptions are formally documented and reviewed
See our full guide on ISO 27001 vulnerability scanning requirements for what auditors expect.
How SurfaceScan helps
SurfaceScan assigns a severity level to every finding based on CVSS scores and additional context like exploit availability and internet exposure. The dashboard groups findings by severity so you can see your critical and high issues at a glance. Trend reporting shows whether your mean time to remediate is improving or deteriorating, and exportable reports provide the evidence trail auditors need to verify your vulnerability management process is working.
Related articles
ISO 27001 Vulnerability Scanning Requirements: What Auditors Expect
Learn which ISO 27001 controls require vulnerability scanning, what evidence auditors want to see, and how to build a compliant vulnerability management process.
NIS2 Compliance: Vulnerability Management and Attack Surface Monitoring
The NIS2 directive requires organisations to manage cybersecurity risks including vulnerability scanning. Learn who it applies to, what it requires, and how to comply.