Tag: Security

A practical pentest workflow combines CVSS, EPSS and business impact to validate findings, prioritize fixes and document remediation decisions.

Remediation prioritization after a pentest is the process of ranking and ordering security findings based on their risk, exploitability, and business impact. A penetration test can produce any number of findings, ranging from the very low (zero) to the very high (hundreds).

The security of the tested organization depends on the findings management processes addressing the most important results first.

• CVSS alone misranks risk. Accurate prioritization relies on combining CVSS, EPSS, and business context.
• 68.4% of practitioners say a 500+ candidate finding set would strain the team or be unmanageable, so it’s important to validate first.
• 81.7% of practitioners see AI-generated findings that need significant manual validation, so validation with concrete proof remains essential.
• Document every deprioritization, because that record counts as audit evidence.

Why aren’t CVSS scores alone enough to inform remediation?

When prioritizing pentest results, some practitioners rely solely on frameworks like the Common Vulnerability Scoring System (CVSS). The logic is sound: the higher a vulnerability’s CVSS score is, the more risk it poses, and the sooner you should fix it, right?

Unfortunately, the reality is much more complicated. Boiling down a complex ecosystem of risk into a one-dimensional number means ignoring the wider business context. In the end, that means you fix vulnerabilities that pose serious theoretical risk first, while genuine exposures get pushed to the back of the queue.

Lets use two hypothetical vulnerabilities as an example.

• Vulnerability A is an RCE flaw, CVSS 9.8, on an isolated intranet site.
• Vulnerability B is a BOLA flaw, CVSS 6.5, on a public facing production payment API.

Now think about which one you would fix first.

Would you prioritize the“critical” flaw on an intranet site, containing no sensitive data that attackers could only reach if they’d already compromised your internal network? Or would you prioritize the “medium” flaw on an API that processes live credit card transactions, and that any script kiddie could manipulate?

Across an entire organization, or multiple organizations if you’re a consultant or MSP, those critical flaws can really pile up. In one AI pentesting survey of 158 base practitioners by Pentest-Tools.com, conducted in June 2026, 68.4% of respondents said a 500+ candidate finding set would strain the team or be unmanageable.

Approaching risk prioritization by trying to fix every “Critical” finding is going to exhaust you and your team. That’s when people make mistakes, and you end up with a major incident on your hands.

What separates a validated finding from a candidate?

That same distinction, in part, separates a candidate finding from a validated one. For example, vulnerability with a high CVSS score but near-zero exploitability should remain a candidate. To graduate a vulnerability from a candidate to a legally and technically validated finding, it must pass through a strict filter that involves three processes.

The first step is to eliminate as much administrative noise as possible. That means deduplicating findings and removing any that are obviously non-exploitable. 

Then, you need to confirm exploitability. That typically means executing a safe, controlled attack path against the target environment to prove that a state change, data exposure, or privilege escalation can actually occur.

Finally, you need concrete evidence. A validated finding cannot rely on a generic tool’s “confidence score.” It must include comprehensive proof that a developer or auditor can immediately follow:

• Technical proof tends to include HTTP request/response traces or specific error payloads.
• Proof of impact includes things like screenshots or server-side telemetry demonstrating unauthorized data access.

Now, many vendors are going to claim that AI-generated findings ease the strain of exploit validation. In many cases, they’re telling the truth. But as with any AI technology, a healthy level of skepticism is important. According to the same study, 81.7% of respondents encounter AI-generated findings that need significant manual exploit validation at least sometimes.

How do CVSS, EPSS and business context combine into a ranking?

Together, CVSS, Exploit Prediction Scoring System (EPSS) scores, and business context create a single risk ranking that reflects real-world danger to the tested organization.

CVSS, as mentioned earlier, measures theoretical severity. It tells you how bad a flaw is in a vacuum, but is entirely blind to context. EPSS measures probability. It tells you how likely an attacker is to exploit a flaw in the wild over the next 30 days, but doesn’t measure the potential impact of an exploitation.

Business context measures operational impact. It tells you the value of the affected asset, how easily an attacker can reach a flaw, and what they can steal. It tells you nothing, however, about the threat itself. Ultimately, business context is expressed as residual risk, the danger left over after you factor in your existing defenses. Calculating it relies on measuring four factors:

• Exposure: Whether a server is open to the public internet.
• User count: How many people use a system.
• Data sensitivity: Whether the system holds sensitive information.
• Compensating controls: Whether you have firewalls or antivirus tools actively blocking the attack path.

By checking these boxes, you won’t waste time fixing a “Critical” bug locked in an empty, disconnected server. Instead, you’ll prioritize the “Medium” bug on your public checkout page that hackers are actively trying to breach.

What goes first when dev time is limited?

Sometimes, you’re not going to have much time for remediation. That’s natural. In those situations, prioritize validated findings with high threat activity (EPSS score) and critical business exposure. They’re the findings that pose the most threat to your organization.

Prioritization done well is itself evidence. A ranked, validated list, with a written reason for what was deprioritized, is what a team can defend later.

You’ll need to record the owner (the specific individual accepting the risk), the date of the decision, the technical operational basis for deprioritization (such as an active compensating control), and a hard review date for re-evaluation.

Why does the ranked list count as audit evidence?

A prioritized ranking list counts as valid audit evidence because it proves compliance alignment with several major security frameworks. For example:

• ISO 27001 A.8.8 demands that organizations evaluate real-world exposure, take targeted corrective actions, and retain objective evidence that the remediation loop has successfully closed.
• PCI DSS 11.4 mandates that penetration testing actively validates and exploits findings, with formal retesting conducted after significant organizational changes.
• SOC 2 CC7.1 relies on this documentation to confirm that an organization maintains systemic operational consistency and rigorous vulnerability triage over time.

A ranked, validated list also gives MSPs and MSSPs a clear, auditable record of truth that clients can either accept or challenge with their own evidence. This transparency ensures both sides agree on which real-world risks need to be addressed first.

What does a defensible ranking record contain?

A defensible ranking record contains the validated asset identification, its technical CVSS severity, its real-world EPSS probability, the active compensating controls defining its residual list, the formal sign-off from the risk owner, and the targeted review schedule.

About the Author: Josh Breaker-Rolfe is a Content writer at Bora. He graduated with a degree in Journalism in 2021 and has a background in cybersecurity PR. He’s written on a wide range of topics, from AI to Zero Trust, and is particularly interested in the impacts of cybersecurity on the wider economy.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, pentest)

Source: Security Affairs · 2026-10-30