# how to prioritize security findings from a pentest

## TL;DR
A pentest report with 40 findings is a to-do list nobody will finish, so rank them by what an attacker would actually use. Internet-reachable plus easy to exploit plus sensitive data at risk goes first. Fix cost matters too: a critical that takes a quarter loses to three highs you can ship this week, unless it is being exploited right now.

```text
how to prioritize security findings from a pentest
```

## Use this when
- a pentest report just landed and nobody knows where to start
- engineering pushes back on the report's severity ratings
- you need to turn findings into a sprint plan
- leadership asks which findings actually matter

## Not for this skill when
- you are running the pentest yourself (different skill)
- the findings come from an automated scanner with no human validation (verify first)
- you need the actual code fixes (that is engineering's job)
- you want to argue with the tester about a rating (re-score for your context instead)

## Steps
1. Re-score everything for your context. The report's severity is generic; a "medium" on your internet-facing login page beats a "high" on an internal tool nobody uses. Your exposure is half the risk equation.

2. Sort by exploitability times impact. Reachable from the internet, no auth needed, public exploit exists, sensitive data behind it: findings hitting all four go to the top of the list without debate.

3. Check what is already being exploited. Search your logs for the vulnerable endpoints and the attack patterns from the report. Active exploitation jumps the queue past everything, including the criticals.

4. Bucket the rest. Fix this sprint: top risks and cheap fixes. Fix this quarter: real risk, real work. Accept or mitigate: low risk, expensive fix, with the reasoning documented. Every finding lands in a bucket; "later" is not a bucket.

5. Assign owners with dates, not "the team." Every finding gets a name and a deadline or it drifts. The owner doesnt have to fix it personally, but they are accountable for it getting fixed.

6. Retest. Have the tester verify the fixes, or re-run the check yourself. "We think we fixed it" has burned everyone at least once. Closed means verified, not merged.

### Variant: prioritizing findings from an automated scan
Scanners have higher false-positive rates, so verify before you prioritize. Confirm the finding is real, then run the same ranking. Never let an unverified scanner critical jump the queue.

### Variant: prioritizing when the report is 200 findings long
Dont rank 200 items. Sample across categories, find the systemic patterns (missing auth checks, injection in every form), and fix the pattern once. Pattern fixes clear dozens of findings at a time.

### Variant: prioritizing cloud misconfigurations vs code flaws
Misconfigurations usually fix faster than code flaws, so they often win the sprint bucket even at lower severity. A public S3 bucket fixed in ten minutes beats a medium code flaw scheduled for next quarter.

## Why this happens
Pentest reports rank by technical severity, but risk is severity times your exposure. Prioritization translates the report into a plan a team can actually execute, instead of a PDF that gets filed and forgotten.

## Edge cases and pitfalls
- Dont let perfect be the enemy. Compensating controls like WAF rules and extra monitoring buy time for hard fixes; use them and say so.
- Findings marked "informational" sometimes chain with others into something real. Skim them with chaining in mind before you dismiss the section.
- If the same finding appears in two pentests in a row, the problem is your process, not the code. Fix the review or the defaults that let it recur.
- Keep the report itself access-controlled. A pentest report is a roadmap for attackers; treat it like one.
- Tell the tester what you fixed and what you accepted. Good testers remember, and next year's test gets sharper.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7GRi6mzLRvaYxdRBmjDN0g