Phishing Training That Actually Changes Behaviour

Once a year everybody watches a video, answers a few questions and gets a tick against their name. By the following week almost nothing is left. That is not a comment on your staff. A thing you watched in March has very little hold on a decision made in July, on a phone, in the gap between two meetings.

Everyone already knows that emails can be fake. The distance between knowing that and catching a good one in the moment is where the whole problem sits. Real phishing does not look like the example in the video. It looks like the rest of your inbox, because it was written to.

What moves behaviour is practice with feedback close behind it, repeated often enough to become a reflex, and a way to raise a hand that costs the person nothing. Everything below is about building those two things and then making sure a single mistake is survivable.

There is a second reason the yearly session fails. It is aimed at everybody equally, and your risk is not spread equally. The person who pays supplier invoices, the person who can reset passwords and the person who approves changes to bank details are standing somewhere quite different from the rest of the company. They need their own session, built around what they actually do.

Most phishing programmes report a click rate and stop there. Click rate is easy to move and easy to flatter. Send an obvious simulation, watch the rate fall, present a tidy chart to the board. Nothing about your actual exposure has changed.

The thing worth measuring is whether people report, and how quickly the first report arrives. A real campaign lands in many inboxes at once. If somebody flags it within minutes, your IT team can pull the message out of every mailbox before most people have opened it. If the first report comes in the next morning, you are doing clean up instead.

So watch two things over time. What share of the people who received a simulation reported it, and how long it took for the first report to land. Both should improve as the programme matures, and neither improves by frightening anyone.

Report rate has a property that click rate lacks. It rises when people feel safe. It falls the moment they do not. You are therefore measuring the culture at the same time as the training, for free.

The instinct after somebody fails a simulation is to make an example of them. A name on a list. An extra mandatory course. A note to their manager. It works, in the narrow sense that the click rate falls. What falls with it is your reporting.

Look at what you have taught. Clicking is punished. Reporting a click means confessing to the thing that gets punished. The next person who clicks a real link, at half past four on a Friday, now has a strong reason to hope it was nothing and say nothing at all. You have traded a small visible number for a large invisible one.

The outcome you actually want is the person who clicks and then reports it straight away. That person has handed you the sender, the domain, the landing page and the fact that one set of credentials may now be somewhere it should not be. Say out loud, to them and to their team, that this is the reason the response started early.

None of this means there are never consequences. Ignoring a written payment approval process is a performance matter. So is deliberately switching off a control. Being fooled by a well made forgery is neither of those, and treating it as though it were will cost you the reporting you depend on.

If reporting means forwarding a message to an address somebody has to go and look up, most people will simply delete it. Put a report button in the mail client where everyone can see it. One click, the message leaves the inbox, and the people who deal with it get the full original including the headers.

Then answer every single report, including the ones that turn out to be ordinary marketing. A short reply saying thank you, this one was a genuine newsletter, please keep sending them. Reporting dies quietly when messages disappear into a mailbox and nothing ever comes back.

When a report leads somewhere, close the loop loudly. Someone reported this, we found it in other mailboxes, we removed it from all of them. That single habit does more for your reporting rate than any amount of course content, and it costs one message.

Make sure it works on a phone. A good share of the bad decisions happen there, where the display name hides the sender address and there is no way to hover over a link. A report button that only exists in the desktop client is missing during the hours it is most needed.

A simulation is a training tool rather than a test you win. Start easy and get harder over the year, so people build the habit before they meet something genuinely difficult. A first campaign that catches nearly everybody teaches embarrassment and very little else.

Send the lures that are actually used against businesses like yours. An invoice with changed bank details. A supplier asking you to update payment information. A message from a real partner whose account was compromised last week. A document sharing notification. A sign in approval prompt arriving when nobody asked for one. That is what shows up, so build that.

Avoid the lures that damage trust more than they teach. A fake bonus announcement, a fake redundancy notice, a fake message about somebody's payslip. They produce a very high click rate and buy you nothing, because the lesson people take away is that their employer lied to them about money. If you want a hard test, use a hard business lure instead.

Deliver the teaching moment immediately and privately. The landing page should say calmly what the giveaway was in this specific message and how to report the next one. Keep it short. Nobody who has just clicked wants a lecture, and a wall of policy text at that moment is a wall nobody reads.

The advice about poor grammar and blurry logos has aged badly. Plenty of phishing now arrives well written, correctly branded, and sent from a real account at a real company that was compromised a week ago. The sender check most people were taught fails completely against that.

What holds up is the shape of the request. Urgency that discourages checking. A request to move money, or to change where money goes. A conversation that jumps to a new channel. An instruction to keep it between you. A login page reached by following a link rather than a bookmark. A sign in prompt you did not start.

Teach verification as a specific action rather than as a principle. If payment details change, you ring the supplier on the number you already hold, never the one in the email. If a colleague asks for something unusual, you reach them a different way before doing it. If a login page appears after a link, you close it and go to the site yourself.

For finance, procurement and anyone with administrative rights, run a separate session built on their real workflow. Put a genuine looking invoice change request in front of them and ask what they would do next. The gaps come out of that conversation far faster than out of any course.

Training reduces how often somebody is fooled. It will never take that to zero, and any plan resting on nobody ever being fooled has already failed. The other half of the work is making a successful phish survivable.

Multi factor sign in on every account, with a method that resists prompt spamming for the accounts that matter most. Payment changes verified out of band by a second person, with the callback recorded. No standing administrative rights on the accounts people read email with. An alert when a mailbox rule starts forwarding outside the company, because that is one of the first things an attacker sets up.

Then make recovery boring. Everyone should know that reporting a click means their password gets reset and their sessions revoked within the hour, and that this is routine rather than a penalty. When the response is dull and quick, people trigger it earlier.

Judge the whole arrangement by how quickly you find out. A click reported in minutes is a password reset and a mildly annoying afternoon. The same click found a fortnight later, in a log somebody happened to open, is an investigation.

Reporting is ordinary. People forward things without apologising for wasting your time, and a useful fraction of what arrives turns out to be worth acting on.

Finance follows a callback rule without being reminded, and treats an emailed change of bank account as a normal thing to verify rather than as an accusation against the sender.

You hear about real campaigns from your own staff before any tool tells you, and you hear about them while the campaign is still running rather than after it has finished. And when somebody does get caught, they say so the same hour. Everything after that is easier, cheaper and quieter than it would otherwise have been.