Do not remediate in raw CVSS order — CVSS is environment-agnostic and does not know what is exposed or what data sits behind it. Triage by real risk = likelihood × impact in your context. Fix anything already exploited in the test or reachable from the internet first, then separate quick wins from strategic fixes, assign an owner and a severity-based SLA to every finding, and drive each to a decision: fixed (and retested), accepted, or deferred with a date on a risk register. A good report already re-ranks by contextual risk — start there.
// 01 Why not just sort by CVSS?
The instinct is to sort the findings table by severity and start at the top. It is the wrong instinct, because a raw CVSS base score is deliberately environment-agnostic — it describes the vulnerability in the abstract, not in your specific deployment. It does not know that the "critical" issue is on an isolated lab box unreachable from anywhere that matters, or that the "medium" is on the authenticated checkout flow of your internet-facing store. Context flips priorities constantly.
Real risk is likelihood of exploitation multiplied by business impact, evaluated in your environment. A competent penetration test report already does much of this re-ranking for you — which is one reason a validated pentest beats a raw scanner dump, where everything arrives at inflated, context-free severity.
// 02 The triage process, step by step
Validate & de-duplicate
Confirm each finding is real and unique. Remove any false positives before you plan a single hour of work.
Re-rank by real risk
Score likelihood × impact in your context. Exploited-in-test and internet-facing rise; isolated and heavily mitigated fall.
Split quick wins vs strategic
Separate fast, high-value fixes (a config change, a patch) from structural work (an auth redesign) that needs a project.
Assign owners & SLAs
Every finding gets a named owner and a deadline set by severity. Unowned findings never get fixed.
Remediate, retest, record
Fix, verify with a retest, and formally document anything you accept or defer on a risk register.
// 03 Ranking by likelihood and impact
A simple risk matrix keeps the conversation honest. Plot each finding on two axes — how likely it is to be exploited, and how bad it would be — and let position, not label, drive order.
| Signal that raises priority | Signal that lowers priority |
|---|---|
| Already exploited during the test | Requires unrealistic pre-conditions |
| Internet-facing / unauthenticated | Isolated, internal-only, heavily segmented |
| Leads to sensitive or regulated data | No meaningful data or impact behind it |
| Part of a proven attack chain | Strong compensating control already in place |
| Trivial to weaponise (public exploit) | Theoretical, no known practical exploit |
// 04 Severity-based remediation SLAs
Give each severity band a target so remediation does not drift. These are a common, defensible baseline — tighten them to whatever your framework or customer contracts demand:
| Severity | Typical SLA | Note |
|---|---|---|
| Critical | 7–15 days | Internet-facing / exploited: treat as immediate |
| High | 30 days | Plan into the current sprint |
| Medium | 60–90 days | Next cycle, or batch with related work |
| Low | Best-effort / next cycle | Fix opportunistically; don't ignore permanently |
Whatever the label, anything actively exploitable from the internet is your most urgent work, full stop.
// 05 Quick wins, accepted risk and closing the loop
Two moves separate a mature response from a stalled one. First, bank the quick wins early: a handful of config changes and patches often removes a surprising share of real risk in the first week and shows momentum to auditors and customers. Second, never let a finding silently vanish. Anything you cannot fix now becomes a formal, documented decision — accepted or deferred risk with a named owner, a rationale, compensating controls and a review date, recorded on a risk register. Auditors expect that register; a time-boxed acceptance is defensible, an undocumented open critical is not. Then close the loop with a retest so "fixed" means verified, not assumed — the evidence your auditor, and your own board, will ask for. Fold the lessons into a tighter next engagement.
// 06 Frequently asked questions
How do you prioritise penetration test findings?
By real risk in your environment — likelihood times business impact — not raw CVSS. Fix anything exploited in the test or reachable from the internet first, then work down by contextual risk, separating quick wins from strategic fixes.
Should you fix findings in CVSS order?
No. CVSS is environment-agnostic — it doesn't know what's exposed or what data sits behind it. Use the report's contextual ranking, adjust for your own knowledge of exposure and data sensitivity, and treat CVSS as one input, not the decision.
What's a reasonable remediation SLA?
A common baseline: critical in 7–15 days, high in 30, medium in 60–90, low best-effort. Internet-facing and actively exploitable issues are most urgent regardless of label. Align to the strictest framework or contract that applies.
What about findings you can't fix immediately?
Record them as accepted or deferred risk with an owner, rationale, compensating controls and a review date on a risk register. A documented, time-boxed acceptance is defensible; an undocumented open critical is not. Retest everything you fix.
// 07 References
- FIRST, Common Vulnerability Scoring System (CVSS) — base vs environmental metrics.
- Related reading: how to read a penetration test report and retesting after remediation.