Lucía works in operations, at the same financial services company we talked about in the previous piece of this series. On a Tuesday mid-morning an email arrives that feels off. She hesitates for a few seconds, decides not to click and reports it with the button. That gesture, the phishing reporting habit, is the layer of defence that took her organisation the longest to build.
From where she stands, nothing happens after that. The email leaves her inbox, no answer comes back and the week carries on.
The first time that has no consequence at all. The fifth time, it does.
We already looked at that queue from the security team’s side when we asked who opens the emails your employees report, with 47 reports from a single month waiting for a decision and some of them three days old. Those numbers come from one specific organisation’s month and are not industry averages. Here the point of view changes. The question is what happens to the person who filed those reports while they wait.
What does an employee see after reporting a suspicious email?
The circuit of a report has two ends. Through one the email enters the security team, and through the other, at some point, something should come back to the person who raised the alert. In most organisations the first end is built with care and the second one does not exist.
It is worth looking at the process with the information Lucía actually has, which is very little. She cannot see the queue or the verdict, and she does not know whether her email was first in line or number 47. She never finds out whether she was right either. Reporting is a decision made in three seconds that in practice never closes, like raising your hand in a meeting and having the conversation move on without anyone looking at you.
From the organisation’s side the matter is settled, because the email was logged and at some point it will be classified. From Lucía’s side the matter stays open forever.
Why can a simulation be answered instantly and a real email cannot?
An employee can report two very different things, and an organisation answers each of them at opposite speeds.
The first is a simulation from the awareness programme itself. Here the answer is easy, because the platform sent that email and already knows what it is. When the report comes in, the SMARTFENSE platform acknowledges the catch on the spot, gives it back to the person and adds it to their score, without anyone on the security team having to step in. It is the same mechanism behind the rest of the programme’s gamification. Lucía finds out immediately that she did the right thing.
The second is a real email. Here there is nothing the platform knows in advance, so the answer depends on somebody looking at it and deciding what it is. And that somebody has 47 reports ahead. The result is an asymmetry nobody designed.
Your programme answers in seconds when the email was yours and takes days when the email was real.
It is the opposite of what you would want. In a simulation the person already knows they are being assessed. It is in front of a real email that their decision carries weight, and that is where the programme goes quiet.
What does a mailbox that never answers teach your organisation?
A mailbox that never answers does not stay on neutral ground. It teaches something that appears in no training session, which is that reporting is one more internal formality. That is the opposite of the lesson you paid to deliver.
Why a person’s response fades when the stimulus repeats without consequence is covered on this blog in security fatigue and the point where the warning stops working and in how a shortcut becomes the team’s norm. Here the operational version of the problem is enough. Nobody decides to stop reporting. The next moment of doubt gets resolved the cheapest way, which is closing the email and carrying on, with no conversation and no complaint along the way.
That is why the decay is hard to see on the dashboard. The reporting rate does not drop sharply, it flattens, and a flat indicator reads as stability, especially if the number is still better than last year’s. The mailbox fills up first and empties later, and not because the team emptied it.
How do you design the consequence of a report?
The consequence does not have to be a thank-you email. In fact, if that is all it is, it wears out fast. There are four more useful decisions and none of them requires inventing anything new.
- Acknowledge the catch where you already can. A simulation report can be closed on the spot, so there is no reason for it to go unanswered. It is the easiest case and the most wasted.
- Shorten the time to an answer on real emails. This is the real bottleneck. As long as classification is measured in days, no design of consequence works, because the answer arrives once the person has already filed the matter away.
- Make it visible that the organisation acted. When an attack somebody reported gets blocked, say so. A short notice about an email that was spotted and stopped gives meaning back to everyone who reported, not only to the person who was right.
- Let reporting count in how the organisation reads that person. If a click on a simulation weighs on someone’s risk profile, a report should weigh too, in their favour. Today most programmes record their users’ mistakes in detail and do not record their successes.
The first two are handled by Smart Triage and Nudges. Smart Triage analyses the reported email automatically, assigns it a score and determines whether it is real phishing or a false alarm. With that result, a nudge fires on its own and gives the person who reported an almost immediate answer, through whichever channel the organisation picks: email, Slack or Microsoft Teams.
The third depends more on the organisation’s internal policy than on the tooling, and it holds up as good practice. The fourth is also handled by SMARTFENSE, through each user’s resilience index and the awareness champions report.
Which indicator tells you the habit is holding up?
This month’s reporting rate does not answer that question. Three readings do.
The first is how many distinct people reported in the period, not how many reports came in. The monthly total can rise while the base of people reporting shrinks, because a small group of highly alert people offsets the ones who went quiet. Those are two opposite situations with the same number on top.
The second is the proportion of real emails to simulations. Reporting a simulation is answering a familiar test correctly. Reporting a real email is the behaviour you were after, and it shows up when the person trusts that the alert is good for something.
The third is how long a report takes to get an answer. That number does not measure your users, it measures you, and it explains the other two.
That is why the indicator María cares about is not how many reports came in this month. It is whether Lucía is still reporting in month twelve.
What Lucía never sees
Lucía is not going to ask for an answer. It is not her job and she probably does not frame it that way. The only thing she will do is decide, the next time an email gives her pause, whether it is worth stopping.
That decision plays out in the time between her report and the answer. When it is measured in days, the answer arrives too late for her and too late for the organisation. When it is measured in minutes, the circuit closes on its own and the habit holds up without campaigns.
Compressing that time is the job of the reports console, and it is what the next piece of this series is about. There we will follow the email Lucía reported minute by minute, from the second she presses the button to the moment the security team starts to act.
Leave a Reply