How to read severity ratings
Most reports you will see today use CVSS 4.0 or CVSS 3.1. The difference between the two matters for how you read the numbers. CVSS 4.0 separated exploitability and impact more cleanly than 3.1, added Supplemental Metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency), and changed the base score structure to better represent the actual attack path rather than just the vulnerability class. If your report cites CVSS 3.1, the scores are still valid, but the vector strings look different and some edge cases score differently.
The CVSS 4.0 base score ranges are:
- 0.0 — None
- 0.1 to 3.9 — Low
- 4.0 to 6.9 — Medium
- 7.0 to 8.9 — High
- 9.0 to 10.0 — Critical
Severity ratings tell you how bad a vulnerability is in abstract. They do not tell you what to fix first. A Critical finding against a non-production sandbox with no path to customer data may be lower remediation priority than a Medium finding that sits directly in your authentication flow. The base score does not account for your specific environment, your existing compensating controls, or the actual exposure window. That context is what determines triage order, not the number alone.
A good report includes a remediation priority section that separates the CVSS score from the recommended fix order. If your report just hands you a sorted list by CVSS score, your developer will work in the wrong order. The engineer who tested your system knows which findings chain together, which ones have working exploits available publicly, and which ones are blocked by other controls. That context belongs in the report.
Informational findings are worth keeping track of even though they are not vulnerabilities. They show up in good reports because the tester noticed something worth flagging: missing security headers, verbose error messages that reveal stack traces, overly permissive CORS configuration, default credentials on a non-critical internal tool. None of these are urgent on their own. Collectively, they often indicate a security hygiene pattern that the next tester will find again. A backlog item is the right treatment, not an emergency.
What working proof of concept means
A working proof of concept proves that the vulnerability is real in your system, not a theoretical possibility. This is the difference between a scanner report and a penetration test report.
A scanner alert says: "this endpoint matches the pattern for SQL injection based on the response timing differential." A working PoC says: here is the exact payload, here is the HTTP request, here is the response showing three rows of customer data extracted from the database, and here is how your developer can reproduce it in 90 seconds using the request in Burp repeater.
The form of a PoC depends on the attack surface. For a web application finding, it is typically the HTTP request and response captured in Burp, with the relevant headers and body annotated. For an API finding, it may be a curl command your developer can run against staging. For a cloud IAM finding, it is the policy chain that escalated privileges, the CLI commands used, and the resulting access level. For a mobile application finding, it may be a Frida script output or a decompiled code snippet showing where the logic fails. For a network finding, it may be a Metasploit module output or a manual packet trace.
The PoC matters for remediation because your developer needs to see exactly what to fix, not a description of a category of vulnerability. It also matters for the retest: the engineer who returns to verify the fix needs to reproduce the original PoC and confirm that the same request or technique now fails. Without a documented PoC, the retest is a best-effort check, not a verified confirmation.
See what every pentest.systems engagement produces and how we approach penetration testing across web applications, APIs, mobile, network, cloud, and IoT.