Home / Knowledge hub / Finding triage
Knowledge hub
Finding triage
Sorting new findings into fix now, fix later, duplicate or not real.
What it means
Finding triage is the first review of a new finding. Someone checks whether it is real, whether it is a duplicate, how serious it is for your system, who should fix it and by when. The outcome is a decision: fix now, schedule, accept the risk, or close as not a problem.
The word comes from hospital emergency work, where the most urgent cases are seen first. The same idea applies. A finding that arrives with no decision attached sits in a queue and ages. Triage gives each one a destination and a named owner within a short, set time.
Why it matters
Without triage, findings pile up and the team stops looking at them. Duplicates inflate the count, false alarms waste developer time, and the one critical flaw hides among forty lows. A short triage step each week stops the backlog from forming and keeps trust in the tool or report.
It is also where context enters. Severity from a report is a starting point. Someone who knows the system can say a flaw is on a retired service or is covered by another control. That is the place to apply risk-based prioritisation and to record any risk acceptance.
How it shows up
Run it as a regular short meeting or a daily check of new items. Each finding gets one of a few states: confirmed, duplicate, not reproducible, accepted risk or needs more information. Assign an owner and a due date from your remediation SLA when it is confirmed.
The common failures are triaging by severity label alone, leaving it to one overloaded person, and letting findings without evidence go through. If a finding carries a request, response and location, confirmation takes minutes. If it does not, the work shifts to whoever has to rediscover it.
Questions people ask
Finding triage, answered
Who should do finding triage?
Usually a security engineer together with the team that owns the affected code. Security can judge the risk and the team can judge the fix.
A shared review is faster than passing tickets back and forth.
How long should triage take?
A short, regular session or a quick daily check is enough when findings carry good evidence. Aim to decide within a few working days.
Long delays here make the whole fix time longer.
What outcomes can triage have?
Typical ones are confirmed and scheduled, duplicate, not reproducible, accepted risk with an owner, or sent back for more detail.
Each outcome should be recorded with a reason. A brief note on why helps whoever picks the finding up months later.
Can triage be automated?
Part of it can: deduplication, routing to owners and matching known false alarms. The decision on real risk still needs someone who knows the system.
Automation helps most when findings carry clear evidence.
What if triage disagrees with the reported severity?
Record the change and the reason, and keep the original rating visible. Both views are useful later.
Do not quietly edit severity to meet a deadline. The reasons will matter when an auditor or a customer asks about it.
Sources
Where this comes from
Related
Terms that sit next to this one
Finding deduplication
Merging reports of the same flaw so a team sees it once.
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
False positive
A reported issue that turns out not to be real.
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
Risk-based prioritisation
Ordering fixes by real-world risk, not just by the raw severity score.
Fix now, later, or never?
Findings arrive with proof attached, which makes triage a matter of minutes. We keep severity and confidence apart, so you can see how sure we are. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.