Make Cybersecurity Reporting Easier for Employees

1. Instead of measuring click rate (a number that wrongfully punishes people for clicks on systems that have access to clients' MT4/MT5 servers and can thereby cost you a weekend of trading), we at TradingFXVPS measure time-to-report (i.e., the time it takes for a user to click and for us to have been informed of the click). And we cut all the friction to a report: there is one report button in the mail client. There is no form to fill out, no ticket opened. If reporting takes more than 5 seconds, then reporting does not happen.

2. Close the loop fast. Before we closed the loop so fast, every report now receives a human reply within 15 minutes with a verdict of "junk," "real phish," or "legit" as was the case with this particular report of a credential-harvest email spoofing a data center provider email address. Reports used to disappear into space, and as a result, nobody wanted to admit guilt by reporting. We treat reports of security incidents on the servers the same as we do incidents on the servers, i.e., alert, triage, fix, and inform the reporter of what happened in the process. Our median report time has decreased from hours to under 10 minutes.

Most reporting programs fail because they measure compliance, while employees experience social risk. A phishing simulation score may tell leadership who clicked, but it says little about whether someone will surface an unusual payment request before money moves. The more public the scorecard, the less useful the human signal becomes.

I recommend separating learning metrics from incident intake. Track themes privately for training, but make the reporting channel frictionless and neutral, like flagging a typo in a customer proposal. Then close the loop with language explaining what happened because of the report. People repeat behaviors when they can see action changed an outcome, not when told they passed a test.

I encourage early reporting of suspicious emails or activity by thanking the reporter in front of the team and never punishing a false alarm, so raising a concern feels like doing the job, not risking blame. In the Australian Army Signals Platoon I learned that leaders are human and miss things, and the person closest to the radio or the screen often sees the odd detail first. Later, coaching business teams on basic cyber hygiene, I used the same rule: if someone forwards a weird email or flags a login they did not recognize, the first response is public thanks, not a quiz about whether they should have known better.

The practice that made people raise concerns earlier was a short weekly reminder that reporting is expected work, plus a no penalty promise for false alarms written into the team notes. In one coaching group, after we started thanking reporters out loud, suspicious email forwards rose from almost none to several a month, and two of those catches stopped a payroll redirect attempt before money moved. Fear shuts the channel. Gratitude and a clear job expectation open it. People report early when they know a wrong call still earns respect.

I don't want employees thinking they'll get in trouble for asking whether an email is legitimate. Mistakes happen, and the most important thing is how quickly someone brings a concern forward. I encourage employees to contact the appropriate person as soon as something looks unusual, even if they aren't certain there's a problem.

We make the reporting process simple and identify exactly whom employees should contact. Removing uncertainty made people more comfortable speaking up before a small issue could become a larger one.

We have improved the quality of reports by using one simple phrase. We tell employees to "report suspicion, not proof" because many people stay silent when they think they need evidence before raising a concern. Removing this pressure encourages them to speak up sooner. As a result, we receive reports that are more timely and useful.

We repeat this message whenever a questionable email or unusual request comes up. We do not expect employees to identify or explain an incident. Instead, we ask them to share what made them uneasy, such as an unfamiliar tone, an unexpected attachment, or a rushed payment request. This approach makes speaking up easier and helps employees trust their instincts while following a clear process for reporting concerns.

Make verifying normal. The most effective security practice we have at Stratus10 is also the simplest: anyone can ask "was this you?" and nobody thinks twice about it.

We've had employees get emails and texts from people pretending to be me. Each time, a quick message asking me directly was all it took to stop it. That's the culture you want. Checking is never treated as an overreaction, so people raise concerns early instead of quietly deciding whether something is worth bothering someone about.

We run regular security trainings, but training isn't what usually catches these attempts. General awareness is. Our team asks each other for verification directly, searches a company name or checks a link before clicking it, and treats a second opinion as good judgment.

The leadership piece is making sure the person being impersonated is the easiest one to verify with. If someone gets a message that looks like it came from me, I want asking me about it to feel completely routine.

Scams are everywhere now, but awareness has caught up. The companies that handle this well make asking "is this real?" as ordinary as asking a coworker for a file.

Nobody reports a suspicious email to a team that makes them feel stupid for it. We are a remote team of about 60 and most of our talking happens in Discord. So there is a channel just for anything that looks off. The first reply to every report is thanks, before anyone checks whether it was real.

Leaders post their own near misses there too. I clicked a fake invoice reminder myself in the spring, from what looked like a tool we pay for. I had typed half my password before something felt wrong. Posting that did more than any training slide we own.

Reports went up after that, false alarms included. I would rather read 10 harmless ones than miss a real one. When did someone senior on your team last admit to clicking something?

We use brief security recaps that focus on patterns rather than people. For example, a recap might explain how an unusual invoice request used a familiar logo and urgent language. We never identify the employee who flagged it or the person who received it. This keeps the discussion practical and prevents colleagues from feeling that reporting will lead to public scrutiny.

We have found that this approach builds stronger habits than generic warnings. Employees learn to notice small details that deserve a closer look while knowing they will not be blamed for receiving a convincing message. We believe leaders should make reporting concerns part of daily operations. It should sit alongside checking figures, questioning unexpected changes, and seeking context before taking action.

The practice that does the most is the owner reporting their own near-miss out loud, first. When the person in charge says "I almost clicked a fake invoice link this morning, here's what tipped me off," the whole team learns that reporting is normal and nobody gets graded for it.

Our cleaning teams work inside hundreds of homes, carrying door codes and lockbox details on their phones. A phishing text pretending to be a booking change is a real risk for that kind of operation. The people who catch it are the ones in the field, not the ones in the office.

So the report path has to be short. One message to one person, no form, no ticket number. If it takes five minutes to report a weird email, people will decide it's probably nothing and move on. A quick "does this look off?" in the group chat gets answered in minutes, and the answer is a thank-you before it's anything else.

The thank-you matters more than people expect. A report that turns out to be nothing still gets a reply that says it was worth sending. People remember how the last report was received, and that memory decides whether they send the next one.

I also share the near-misses with the whole team, with no names attached. Everyone sees that a fake link got caught, how it looked, and who spotted it early, if they're fine being mentioned. The report becomes a small win people can point to.

The strongest reporting cultures separate learning from discipline. If employees expect punishment for every misstep, they will hide the small signals that security teams need most, such as an unexpected login prompt, a strange invoice, or a request to bypass a normal approval step. Those details can reveal an attack before monitoring tools have enough context to detect it.

A useful leadership habit is to discuss near misses in team meetings without naming individuals. I have seen this make threats tangible while showing that anyone can be targeted under the right conditions. The discussion should focus on the attacker's technique, the decision points, and the safer path. That approach improves secure behavior without shame, while reinforcing that prompt reporting is a contribution to resilience, not a performance failure.

Employees raise concerns earlier when reporting is positioned as a contribution to collective judgment, not an admission of uncertainty. In large, fast-moving teams, individuals may see only one fragment of a broader pattern. A strange calendar invitation, altered payment instruction, or unexpected login prompt may appear minor alone, yet become meaningful when combined with other reports. That makes early escalation operationally valuable.

One effective communication habit is to publish a brief weekly pattern note, without technical jargon or blame. It can describe the types of unusual requests appearing across the organization and the questions employees should ask before acting. I find this creates shared situational awareness while reinforcing that reporters help others make better decisions. The message is simple, reporting protects the workflow, not just the individual.

The practice I rely on at Streamrise is a rule about how a report is received: the symptom someone describes is treated as a fact and is never argued with. Only the explanation is checked. In my experience people hesitate far less when they know they will not have to defend what they saw.

The distinction matters. When someone says "this looks wrong", two things arrive together: what they observed, and their guess about why. Most of the defensiveness in reporting comes from the receiver attacking the guess and, in doing so, dismissing the observation. Our rule splits them. What you saw is accepted as real. Why it happened is a hypothesis, checked against data rather than by questioning the person who raised it.

Two real moments where this paid off: - Our owner looked at a routine daily report and simply said the result could not be right. The instinct would have been to explain why it was. Instead the observation was taken at face value and the method was checked. The method had only looked at new items, not the whole open backlog. The concern was correct, and it came from someone who had no technical evidence, just a sense that a number was off. - In September a reported problem came with a confident explanation: monitoring had missed the start of two orders. The symptom, 49 hours with no activity, was real. The explanation was not: one query showed the customer had paused the orders through our API. Nobody was wrong for raising it; the check just pointed somewhere else.

How I would apply this to suspicious emails and security concerns: 1. Thank the reporter for the observation before any analysis. A false alarm is a successful report of something that looked dangerous. 2. Never make the reporter prove their theory. Your team checks the cause; their job ends at "I saw this". 3. Close the loop with what the check found, in plain words, so people learn what a real threat looks like without feeling judged. 4. Treat the most confident-sounding reports with the same care as the hesitant ones, including those from senior people. Certainty is not evidence in either direction.

Punitive security culture usually is not about punishment. It is about making people feel interrogated. Separating what they saw from why it happened removes most of that.

I want people to send us a suspicious email as soon as they notice it, even if they've clicked. My first reply thanks them, asks what they saw and did, and assigns someone to check the technical risk. I won't start by asking why they clicked. We can discuss the decision after we've contained any exposure; delaying the report while someone tries to explain themselves costs us the time we need to investigate.

The person reporting doesn't have to identify the attack. I ask for the original message and when it arrived, then whether a link or attachment was opened and whether credentials or application access were granted. A security owner can inspect account activity, active sessions and connected applications, then decide what to revoke. Keeping that first exchange focused on observable facts makes it easier to raise a partial concern early.

We saw what weak detection can cost in a CRM compromise. A phishing message led to a rogue OAuth authorization; the attacker created an admin account and altered CRM data. The durable signal appeared in an API usage dashboard rather than a security alert. I would have the leader tell the reporter what the team checked and what happens next, without turning that person's name into a cautionary tale. Security verifies the event, and the team reviews its process after containment. The first reply should give the reporter a clear path to hand over what they know.

People respond to the metric they believe management truly values. In damages litigation, a record can look thin not because an injury was insignificant, but because the wrong details were never documented. Security teams create the same distortion when they celebrate only confirmed incidents and treat false alarms as wasted effort.

I would have leaders track and recognize timely reporting, not merely accurate threat identification. That sends a more honest signal about an employee's role. Most staff are not investigators, and asking them to act like investigators raises the threshold for speaking. Recognition should affirm judgment under uncertainty. The goal is preserving a signal for examination, not a flawless conclusion.

We believe early threat reporting improves when leaders separate accountability from blame. Accountability means learning from an issue, responding properly, and making improvements. Blame focuses on making someone feel exposed or responsible for the problem. These approaches may seem similar, but they lead to very different information sharing.

We use after-action reviews to examine the conditions behind a decision rather than focusing on the person who made it. We ask whether the request created urgency, the workflow made verification difficult, or expectations were unclear. These questions help reveal process weaknesses that could affect anyone. Sharing the changes we make shows employees that reporting concerns can improve working conditions. This builds more trust than simply reminding everyone to be careful.

I lead device certification teams that work daily with carriers, chipset vendors and external test labs. Our inboxes are full of build links, log uploads and meeting invites from outside the company, which makes us an easy target. A fake "updated test plan" from a spoofed vendor domain looks just like the twenty real ones we get every week. What changed reporting on my team wasn't another training module. It was how I handled one engineer's mistake. A junior engineer clicked what looked like a SharePoint share from a lab partner and entered his credentials. He realized within about ten minutes and messaged me, clearly worried. I thanked him first, then we called the security desk together, reset his password and checked active sessions. Because he spoke up fast, nothing came of it. At the next team call, with his permission, I walked through what the email looked like and what gave it away. I didn't present him as the person who clicked. I presented him as the person who caught it early. Reports from my team went up noticeably after that. Most were false alarms, and that's fine. I tell people plainly: if you're 50/50 on an email, report it. I'd rather security close ten harmless tickets than miss the one that matters. A few habits that keep it going: * I reply to every report the same day, even if it's just "good catch, it was legit, thanks for checking." Silence tells people reporting is pointless. * I never ask "why did you click?" I ask "what made it look real?" That gets useful answers without putting anyone on the defensive. * Once a month we spend five minutes in a team meeting on a real phishing attempt we received, names removed. Engineers spot patterns quickly once they've seen real ones. * I share my own near-misses. When a senior manager admits he almost opened a fake invoice, the embarrassment disappears for everyone else. If I had to pick one practice, it's the first response. When someone reports a mistake, the whole team is watching how you react. If they see blame, they stay quiet next time. If they see you fixing the problem alongside them, you've built a reporting culture without ever using the word "culture."

In my opinion reporting dies when the first person who speaks up feels like they are in trouble. So the right response to reporting is to treat it as a win irrespective that it is false positive or not.

In my experience, the practice that works best is "Thank first, Investigate Second". It creates a positive culture when you say thank you to reporter instead of "Why did you click it?", not undermining the importance of investigation at earliest.

The following two things back it up: 1. Sharing anonymised stories of early reports i.e. Early report last month saved us from global phishing campaign. So staff sees reporting as protecting the company, not exposing a mistake. 2. Admitting your own slips i.e. I almost fell for this phishing link, it looked so similar to the original. So sub-ordinates feel that they can speak up.

The real win is to make people feel that reporting early is the safe choice, and that silence is the real risk.

Last year one of our engineers at Softline spotted a weird Slack DM asking for GCP service account keys. It looked like it came from our team lead. The engineer almost ignored it, figured it was probably legit. But he pinged me first, said "this feels off." Turned out it was a compromised account. If he'd stayed quiet we could've lost access to production infrastructure serving 1500+ client accounts. That incident changed how I think about security culture. The problem isn't that people can't spot phishing. Most engineers know what suspicious emails look like. The problem is they don't want to look paranoid. Nobody wants to raise a false alarm. So we started something simple. A dedicated Slack channel called #caught-something. The rule was easy, you post anything that looks suspicious. No context needed, no analysis required. Just drop the screenshot and move on. And here's the key part, we celebrated every post. Even the false alarms. Especially the false alarms. I replied to every report within 30 minutes. Not with a security lecture, just a quick "good catch, checking it now" or "this one's legit but smart to flag it." We tracked reports on a dashboard. The team that posted the most catches each quarter got mentioned in our all-hands. Reports went up 4x in three months. But what really mattered was speed. People started flagging things within minutes instead of sitting on them for days (or never mentioning them at all). I learned something similar at MyTona where I worked on Cooking Diary (22M+ downloads). When you're handling player data at that scale, one compromised credential can expose millions of accounts. We had engineers who noticed odd API patterns but didn't report them because they thought it was probably a deploy artifact. That "probably" is what kills you. The practice that works is making reporting feel like a normal engineering task. Like filing a bug. You don't punish someone for filing a bug that turns out to be expected behavior. Same logic applies to security. When someone reports a suspicious email and it's nothing, you say thanks. When someone catches a real phishing attempt, you say thanks the exact same way. The leadership piece is consistency. If you respond to the first ten reports with genuine appreciation, the eleventh comes faster. If you ever make someone feel stupid for a false alarm, you won't hear about the real attack until it's too late. Timur Rakhmatullin, Senior Software Engineer, Softline Solutions

Encouraging employees to report suspicious emails or activity starts with building a relationship where they feel safe raising uncertainty, concerns, and mistakes. In our book, Awakened Leadership, we explore how a leader's self-awareness, emotional regulation, and willingness to acknowledge personal limitations influence the culture around them. In cybersecurity, an employee may hesitate because of what they believe speaking up will mean: "They will think I am careless," "I should have known better," or "I could lose my job." Leaders need to address those fears through consistent behavior. One communication practice I recommend is beginning every report with the same response: "Thank you for bringing this to our attention. You did the right thing by speaking up. Let's understand what happened and what we need to do next." That response matters whether the employee caught a suspicious message before opening it or realized afterward that they clicked a questionable link. The leader's first reaction teaches the employee what honesty will cost them. A frustrated tone, public correction, or immediate interrogation can undermine even a carefully written reporting policy. A calm, respectful response makes room for useful information and timely action. Leaders also need to notice their automatic reactions, including anxiety, irritation, or the urge to assign blame, and consciously choose a response that supports early reporting. Pair that approach with a clear reporting channel and a simple message: "You do not need to prove something is wrong before asking us to check." Follow up privately to explain what was learned and how the report helped, even when the concern turns out to be harmless. Leaders can also acknowledge their own uncertainty and mistakes. Accountability remains essential: examine what happened, provide needed coaching, and improve the process while preserving the person's dignity. When sharing lessons with the wider team, remove identifying details and emphasize what everyone can do next time. If a report reveals a confusing procedure, explain what will change and who will own the improvement. Over time, employees learn through experience that raising a concern is a responsible contribution to the organization. That trust gives people a reason to speak early, while there is still an opportunity to respond.

If an employee flags a suspicious email, it disappears into a security inbox, and they never hear another word. No idea if it mattered or whether anyone read it. Do that a couple of times and they stop bothering.

The practice that changes it is telling people what their report did. A two-line reply: "Good catch. That was a real phishing attempt, and because you flagged it we blocked it for 4,000 colleagues before anyone else opened it." That one message turns a chore into a contribution. People don't feel policed. They feel like part of the defence.

Then make it visible. A monthly "best catch" shout-out from a senior leader, with the actual email shown so everyone learns what to look for. Name the person if they're happy to be named. Suddenly spotting a scam is a skill people take pride in, not a test they're afraid of failing.

Employees dont get enough recognition as it is, given them this as a basic will increase compliance without a doubt.

The practice I push with every leadership team: publicly thank people who report, especially false alarms. Most employees stay silent because they've seen someone shamed for flagging a legitimate email, or reported into a black hole and heard nothing back. My advice to founders: when someone reports a phish, reply to the whole team, name them, say what you checked, and thank them. Do that three times and reporting becomes cultural. The line that works: "You will never be punished for reporting. Ever." Awareness training doesn't change behavior — leadership's visible reaction to the first three reports does

Employees are more likely to report suspicious activity when they know the goal is to protect the organization, not to embarrass someone for a mistake. Cybersecurity processes fail when people fear blame for clicking a wrong link or questioning a legitimate-looking request. This fear reduces early reporting when it matters most.

I would make reporting simple, visible, and easy to use. Employees should know where to forward suspicious messages, how to flag unusual requests, and whom to contact if unsure. They should not have to navigate a complex approval process to ask for help.

Communication should use realistic examples relevant to daily work. An employee might receive an unexpected request to change payment details, disclose sensitive information, or bypass procedures due to an urgent message. Training should explain why these requests need extra scrutiny and how to verify them through trusted channels, especially when financial information or access credentials are involved.

Leadership behavior is also important. When an employee reports something suspicious, the response should focus on understanding and containing the risk. If someone made an honest mistake, prompt reporting can limit consequences. Constructive responses reinforce the desired behavior.

I would use recurring questions and reports to identify where employees need clearer guidance. If the same suspicious requests cause confusion, the organization may need better examples, clearer procedures, or more safeguards. A healthy security culture combines clear expectations with psychological safety so employees feel able to speak up before small concerns become larger incidents.

Early reporting depends on psychological safety, but that phrase can become vague. Employees need a concrete promise, the organization will investigate the message, not put the reporter on trial. The difference is visible in the questions leaders ask first.

We train managers to begin with "What did you notice?" and "What happened next?" Those questions gather useful facts without implying fault. I avoid opening with "Why did you do that?" because it invites defensiveness and often produces incomplete information. After the review, a leader can discuss safer choices privately if needed. The public lesson should remain process-focused, such as checking a changed banking request through a known phone number.

The fastest way to kill reporting is to punish the click. If someone feels stupid for flagging something, they'll just delete the next one quietly — and that's the one you needed to see.

Make reporting a 10-second, no-blame action: one obvious button or forward address, no form, no interrogation about why they clicked. Then close the loop fast — thank them publicly, tell them what it actually was, and what happened next. People report more when they see their report mattered, not when they're lectured about it.

The goal isn't a perfect user who never clicks. It's an early signal. Most post-breach phishing succeeds because it looks routine and personal, so the person who raises their hand early is doing you a favor, not creating a problem.