At a previous job, I watched people send suspicious emails to security and hear nothing back. Many of the messages were marketing spam, but the reports were not the problem. People were trying to help. Security gave them a black hole.
There were multiple phishing buttons, and employees told us they were not sure which one to use. All-hands meetings praised the security program while the people using it saw more roadblocks. That gap matters. The next report might be a real attack, and the person who sees it has already learned what happens when they ask for help.
If a click leads to a lecture or an automatic remedial course, people learn another lesson: keep quiet until you know whether you are in trouble. That is a security-design problem, not a reason to call employees the weak link.
A zero-fault reporting culture treats an honest mistake, uncertainty, or suspicious observation as an early signal, not an occasion to assign blame. The person who sees the signal reports the facts. The response team decides what it means and what happens next.
A click is evidence, not a verdict
Phishing simulations can be useful. They can expose a risky business process, show that a message pattern is convincing, or reveal that the reporting route is hard to find. They cannot tell an organization why a person made a decision in one pressured moment, or whether that person will report a real incident quickly.
I have been marked as failing a simulation because I put its link into a sandbox or URL-analysis tool to inspect it. The system counted a click. It could not tell that a security professional was investigating the link. If the metric cannot distinguish analysis from a risky click, it should not be used as a verdict on an employee.
That distinction matters as messages become more plausible. A vendor invoice may arrive during month-end. A password reset may follow a real support ticket. A voicemail may sound like an executive. What matters is whether people pause, verify through an independent route, and report when something does not add up.
SANS made the broader point in its September 2026 analysis, “Behavior Change Is Not the Finish Line”. Its 2026 survey found that many programs have progressed beyond check-the-box training but have not yet built the shared attitudes and relationships that make secure behavior normal. Its accompanying Security Awareness & Culture Report draws on more than 1,700 practitioners and frames culture as the next problem to solve. (No, I was not invited to participate in this survey.)
Measure the decision, not the humiliation. A simulation should teach the organization which messages, workflows, and reporting paths need work. It should not turn an employee into the finding.
The first reply teaches the next report
I started answering the reports I received. If an email was ordinary marketing, I said so, explained what I checked, and offered to help filter similar messages. Some people thanked me. Others did not reply. The important change was that more people knew security would answer. They began asking about odd messages and computer problems before they had decided whether those things were "worth a ticket."
That is the service side of security. A short, useful answer makes the next report easier to send. Praeven wants reporting to feel like working with security, not turning yourself in.
Zero fault still leaves room for responsibility. We expect people to report early, help us understand what happened, and use what they learned next time. The National Cyber Security Centre makes the same distinction: a no-blame culture protects good-faith reporting while retaining accountability. NCSC: openness around security
Report the signal, not the conclusion
People often delay a report because they do not know whether an event “counts.” They may worry that a mistaken click is too small, that a suspicious request sounds foolish in hindsight, or that they cannot explain what happened well enough.
Remove that burden. The employee does not need to prove an incident happened. Report the strange prompt, message, request, or mistake while the details are fresh. Security can check the logs and decide what it means. A report that turns out to be nothing is still better than a real warning that arrived too late.
Praeven brings this reporting habit into live briefings and workshops with a short two-person exercise. One person reports what they saw and what they did, even if they do not know whether it is an incident. The other plays the first security responder: acknowledge the report, ask one useful question, and explain what happens next. Then we reveal another detail and see whether the reporting route and response owner still hold up.
Design the reporting experience
Telling people to report is not enough. The reporting process itself has to earn their trust.
- Put one clear reporting route in the tools people already use.
- Tell people explicitly to report after a click or mistake, not only before one.
- Acknowledge the report quickly and tell the reporter what happens next.
- Ask for useful facts: what happened, when, what system or message was involved, and what action was taken.
- Close the loop with lessons learned and process improvements, without naming and shaming the reporter.
- Let leaders model the behavior by asking for help and treating reports as operational intelligence.
CISA advises organizations to make it safe to report phishing even when someone has inadvertently downloaded malware or shared data; early reporting enables faster action and can reduce wider damage. CISA: building a culture of cybersecurity
Measure the culture you want
Click rate is one data point, and as the sandbox example shows, it can misclassify what happened. A better view of the program also asks:
- How quickly do employees report a suspicious message or mistake?
- How often do people report a simulation rather than simply ignore it?
- How quickly does the response team acknowledge and close the loop?
- Which recurring workflows create urgency, ambiguity, or pressure to bypass a control?
- Can employees name their reporting route and use it without hunting for a policy?
SANS now promotes reporting alongside click behavior in its phishing measurement model, and recent summit work has emphasized moving from click-based outcomes toward the quality of the decision under uncertainty. SANS: phishing awareness training and SANS Summit 2026: decision-focused design.
The goal is not a workforce that is afraid to make a mistake. It is a workforce that recognizes a signal, verifies the decision when it can, and reports early enough for the organization to respond.
That outcome needs more than annual training. People need a reporting route, a response owner, and leaders who will act on what they hear. Praeven's security briefings let teams practice the first report and the first response. The Security Program connects that habit to the people and decisions that keep it working between sessions. The self-paced training program is still in development.