Risk Rating & Remediation

A vulnerability's severity and its risk are not the same thing, and confusing them produces reports that mis-direct the client's effort. Severity is a property of the flaw in the abstract — how bad it is on paper. Risk is what that flaw means in this environment: severity weighed against how likely it is to be exploited here and what it would actually cost the business.

The consequence is sometimes counter-intuitive. A "Critical" CVE on an isolated lab host with no route to anything valuable can be a lower real-world risk than a "Medium" misconfiguration on the server holding the crown-jewel data. Your job as the tester is to do that weighing for the client — to take the raw scores and turn them into a prioritized picture of where the organization is genuinely exposed.

Before you can weigh risk, you need a stable yardstick for severity — and the cardinal rule is to pick one metric and use it identically throughout the entire report. The industry default is CVSS. Whatever you choose, define it once (in the appendix), explain the scale to the client, and never mix metrics mid-document. A report that rates one finding "8.8 CVSS" and another "high-ish" has no usable severity ranking at all.

Most reports collapse the metric into named bands the client can act on at a glance:

The technical guidance in NIST SP 800-115 is a useful external anchor for how severity feeds into a structured assessment.

The model that turns severity into business risk is simple to state and where the real judgement lives: risk = likelihood × impact. Real findings rate the two separately and then combine them, because the combination is what tells the client how worried to be.

• Likelihood asks how realistically an attacker reaches and uses this. Is it internet-exposed or internal-only? How reliable is the exploit? What does the attacker need first — a network position, an authenticated foothold, a user to click?
• Impact asks what they gain. Data exposed? Credentials that may match corporate logins? Remote code execution? A pivot to a more sensitive network? And what is the business or regulatory cost of that?

Worked against the sample Valley Veterinary Ventures engagement, the same model produces very different ratings for superficially similar issues:

Notice how the third finding, despite a frightening "RCE" label, settles at a lower risk than the unglamorous default-credentials issue — precisely because likelihood matters as much as the headline severity.

A finding without a usable fix is half a finding. Good remediation is actionable and tied to the root cause — and since most findings fall into the three families of authentication, configuration, and patching, most remediation does too. Identify which one you are dealing with and the shape of the fix follows.

The single most important rule of remediation writing: recommend the security outcome, not a specific named product. You are not positioned to tell a client "stop using Apache Tomcat and switch to product X" — you do not have the knowledge of their environment, contracts, and constraints to make that call, and it reads as a sales pitch rather than security advice. Instead, describe what must become true:

• Not "replace the app," but "enforce strong, unique credentials for all accounts with access to the application, backed by multi-factor authentication."
• Not "use a different web server," but "bring the configuration in line with the vendor's latest hardening guidance" — and link to that guidance.
• Not "buy a newer system," but "patch the application to the current supported release."

A list of problems is not a plan. Once every finding has a risk rating, sort by risk so the highest-impact issues rise to the top of the report — the client should be able to read the findings in order and be reading them in priority order. Then help them sequence the work: separate the quick wins (change a default credential, disable a service, apply a waiting patch) from the strategic fixes (roll out MFA org-wide, re-segment a flat network).

Be realistic about what the client can execute. Remediation that ignores their operational reality gets shelved. A roadmap that says "this week, this quarter, this year" turns your findings from a source of anxiety into a source of direction — and that, ultimately, is what they paid for.

Just as the same findings recur, so do their fixes. Keep these reusable patterns ready — tailored, never pasted:

• Weak passwords — enforce multi-factor authentication (and verify it is implemented correctly), and screen new passwords against breached-password deny-lists so credentials exposed elsewhere cannot be reused.
• Unpatched / end-of-life software — upgrade or patch to a currently supported release; establish a patch cadence so it does not recur.
• Default credentials — remove or change every default account, and review where the device sits on the network and what it can reach.
• Default web pages — complete the hardening the install skipped and remove the default content that advertises an unfinished setup.
• Exposed networking / IoT gear — segment it away from sensitive networks so a foothold on a printer or a camera does not become a foothold on the domain.
• General hardening — align systems to recognized baselines such as the CIS Benchmarks.

You have now seen every piece of a finding and how to rate and fix it. Time to assemble one yourself — the hands-on Report Builder lets you compose a finding, rate its risk, and watch a quality checker react in real time.