{"id":45755,"date":"2026-09-09T19:24:46","date_gmt":"2026-09-09T17:24:46","guid":{"rendered":"https:\/\/smartfense.com\/?p=45755"},"modified":"2026-09-09T19:25:10","modified_gmt":"2026-09-09T17:25:10","slug":"phishing-report-triage-manual-or-automatic","status":"publish","type":"post","link":"https:\/\/smartfense.com\/en\/blog\/phishing-report-triage-manual-or-automatic\/","title":{"rendered":"From twenty hours to three, what changes when triage stops being manual"},"content":{"rendered":"

The month this series has been talking about had 183 emails reported by employees themselves. The previous piece<\/a> followed one of them from the button to the security team\u2019s decision, and that journey took four minutes. This piece looks at the same month from the other side of the desk, back when the triage of phishing reports was still manual work and those 183 emails were opened one by one. The numbers come from one specific organization, the same one as the earlier pieces, and they are not industry averages.<\/p>\n

How much time does it take to classify a reported email by hand?<\/h2>\n

Every report asked for exactly the same thing. Open the original email. Review the headers and the sender authentication. Check the reputation of the domain and of every link, one at a time. Analyze the attachments. And only then classify.<\/p>\n

Each report took between five and fifteen minutes, depending on how ambiguous the case was. They added up to around twenty hours a month, half a work week spent overwhelmingly on confirming that 160 emails were harmless.<\/p>\n

The first step on that list is also the one nobody wants to take. Opening the original email means handling by hand the file somebody reported precisely because it looked dangerous, with all the care that requires, on the computer of whoever is reviewing it.<\/p>\n

There is something worse than the total hours, and it is the order. A queue processed by arrival date treats the new supplier\u2019s email and the targeted attack exactly alike, because until somebody opens them there is no way to know which is which. Priority does not exist before classification, so classification is the first thing to get out of the way.<\/p>\n

What work is left when triage is automatic?<\/h2>\n

Reports enter the console already resolved. Each one arrives with its verdict, with a risk score from 0 to 100 that also names the band it falls into, and with the detail of what was checked to get there. The listing is still ordered by date, like any inbox, but now it can be filtered by verdict and the severity can be read at a glance, without opening anything.<\/p>\n

\n

Your team stops classifying emails and starts reviewing decisions.<\/p>\n<\/blockquote>\n

The month takes a different shape. The ones flagged as phishing get a close review, and they are few and already arrive with the evidence assembled, while the false alarms get an audit pass to check they are correctly classified. Three hours. The other seventeen go to investigating the confirmed threats, which is the work that person was hired for.<\/p>\n

That score should not be confused with the human risk score<\/a> of the person who reported. One measures how dangerous an email is. The other measures behaviour over time, and reporting counts in your favour.<\/p>\n

Who has the final say on the verdict?<\/h2>\n

The analysis proposes and your team decides, and that rests on the mechanics rather than on a promise. Any report can be confirmed or corrected by hand from its own detail view, in one click. If somebody corrects the verdict while the analysis is still running, the person\u2019s correction wins.<\/p>\n

The console does not lose track of who decided what either. Every report shows with an icon whether its verdict was left by the automatic analysis or by a person, and that same distinction travels to the exported listing. The name, the time and the classification that was there before the change stay in the report\u2019s audit trail.<\/p>\n

That is what answers the question that shows up six months later, when somebody wants to know why an email was classified a certain way. The answer is on record, with an author and a date, and when the author was the analysis the record says so too.<\/p>\n

What happens when the analysis gets it wrong?<\/h2>\n

It gets things wrong, the way email security gets things wrong and the way a person gets things wrong at six on a Friday evening. What decides whether that is a problem is how cheap it is to correct the error and how visible the change stays.<\/p>\n

The audit pass over the false alarms is that control, and it pays off more with an explicit criterion. A dangerous email filed as a false alarm costs far more than a false alarm treated as phishing, so the review concentrates on one side only rather than on debating the correct calls.<\/p>\n

When somebody corrects a verdict, that report stops counting as resolved by the analysis and starts counting as resolved by a person. That is the right reading, and it is also what keeps the month\u2019s tally clean, because what the dashboard presents as automatic classification is exactly what nobody had to touch.<\/p>\n

How do you keep the alerts from overwhelming the team?<\/h2>\n

Alerts are controlled with three independent notices, each with its own switch.<\/p>\n