Prioritising Targets for an Audit
A real engagement almost never has enough time to deeply test everything. Prioritisation is the skill that decides where your limited hours go, and it is just as important as any technical scanning skill. This lesson closes the vulnerability analysis chapter by giving you a practical way to rank targets before moving on to exploitation.
Why prioritisation is a skill, not an afterthought
Imagine ending a five-day engagement having spent four days deeply testing a rarely used internal tool, only to discover on the last afternoon that the main customer-facing application, which you barely touched, has an obvious, severe weakness. A good prioritisation habit, applied from the very start of the vulnerability analysis phase, prevents exactly this kind of costly mistake.
Four factors to combine
Instead of ranking targets on a single criterion like "CVSS score", combine at least four factors, each answering a different question:
- Likely severity: based on CVSS scores and your own judgement from the previous lessons, how bad would it be if this specific finding were real and exploited?
- Exposure: can this target be reached from the internet by anyone, only from inside a corporate network, or only by someone who already has an account? More exposed targets are generally riskier in practice, all else being equal.
- Business value of the data or function involved: a weakness in a system holding payment details or health records matters more than the same technical weakness in a system holding only public marketing content.
- Confidence of your hypothesis: as covered earlier in this chapter, a well-matched, cross-checked candidate deserves attention sooner than a vague, low-confidence guess, even if the vague guess has a slightly higher theoretical severity.
A simple scoring approach
You do not need complex statistics. A simple, transparent approach that works well in practice: rate each factor from 1 (low) to 3 (high) for each candidate, then add them up for a rough priority score out of 12. The table below illustrates this with a few fictional example candidates:
| Candidate | Severity | Exposure | Data/business value | Confidence | Total |
|---|---|---|---|---|---|
| Outdated service on internet-facing host | 3 | 3 | 2 | 2 | 10 |
| Internal-only admin panel, weak evidence | 3 | 1 | 3 | 1 | 8 |
| Minor cookie flag missing on a public page | 1 | 3 | 1 | 3 | 8 |
Notice that two rows share the same total despite being very different findings. A score is a conversation starter with your own judgement, not a verdict: the second row deserves a careful, time-boxed look because of its potential severity and business value, even though evidence is thin, while the third row is probably safe to address quickly in writing without deep manual exploitation. A rigid numeric ranking should never fully replace experienced judgement.
Keeping the client's priorities in view
Your own technical ranking should also be checked against what the client told you during scoping in chapter 1. If a client specifically said "we are most worried about customer account takeover", a moderate-looking finding in the login flow may deserve more attention than your scoring table alone would suggest. A good tester blends an objective method with the client's stated concerns, and says so explicitly in the report.
Writing down your plan before moving to exploitation
Before starting chapter 4, a professional tester writes a short, ordered target list, with a one-line justification for each entry, directly into the engagement notes. This list becomes the backbone of the exploitation phase: you attempt the highest-priority items first, so that if time runs out, what remains untested is, deliberately, the least important material.
Legal reminder
Prioritisation never overrides scope. A high-priority idea that targets a system outside the authorised list, however interesting, stays untouched, and should instead be reported to the client as a recommendation to extend the scope in a future, properly authorised engagement.
Your fil rouge: Lighthouse Labs priority list
Using everything gathered so far in Project Lighthouse (your reconnaissance table, your CVE candidates, your scanner triage notes), build a scored priority table like the example above for three to five fictional candidate findings. Save the final, ordered list in 02-vuln/priority-list.md. This is the exact document you will open at the start of chapter 4.
Your turn: break a tie
Two findings on a client's network score identically on your table: a moderately severe weakness on an internet-facing marketing website with no sensitive data, and a moderately severe weakness on an internal file server that stores employee payroll information, reachable only from inside the office network. The client mentioned during scoping that their biggest fear is a data leak of employee personal information. Which one do you test first, and why?
See a solution
The internal file server should be tested first, even though it is less exposed from the outside, because the client explicitly named data leaks of employee personal information as their top concern, and the business value of that specific data is high. A pure exposure-based score would have favoured the marketing website, which illustrates exactly why the client's stated priorities must be weighed alongside, not instead of, the scoring table.
Tip
Revisit your priority list at the end of each day of a real engagement. New findings from exploitation often reshuffle what deserves attention next.
Key takeaways
- Prioritisation prevents wasting limited engagement time on low-value targets.
- Combine severity, exposure, business value of the data or function, and confidence of the hypothesis.
- A simple numeric score is a starting point for judgement, not a replacement for it.
- The client's own stated priorities must be weighed alongside your technical scoring.
- Scope always wins over priority: never test outside the authorised list, however tempting.
Chapter 3 is complete. You now have a disciplined, documented, prioritised list of targets. Chapter 4 turns the top of that list into confirmed, demonstrated findings through exploitation, always inside your authorised lab.