Our approach
It was never their job
to spot the fake.
We're not trying to make everyone a cybersecurity expert. We want people to know when to stop, who to call, and how to wait.
WAS Teach people to recognize attacks.
IS Know when to stop. Know who to call.
The goal is wrong, and the whole program is built on it.
Most awareness programs begin with a goal that sounds obvious: make ordinary staff better at spotting attacks. Everything follows from it. The phishing module. The fake scam emails sent to test people. The click-rate dashboard. The quarterly score that goes in the board report.
Attackers build situations that are believable, unclear, urgent, and hard to tell apart from real work. That's the whole craft. Hand an experienced security professional a really convincing fake and we disagree about whether it's real. We disagree in the middle of incidents. We disagree in the review afterwards, with the answer already in front of us.
That was true before AI writing tools. It's worse now. Broken English, sloppy formatting, an address that doesn't quite match: those giveaways came from scammers sending thousands at a time in a second language, and they are cheap to clean up now. Awareness training still sends people hunting for warning signs that no longer reliably appear. That fails. Then it does something worse. It teaches them that the absence of one means the message is safe.
If we can't reliably tell real from fake, neither can the secretary with an invoice to pay and plenty of other work to do.
So a well-trained person keeps failing a test that was never fair, and the program records it as a people problem. It isn't. It starts with the goal.
"I don't know whether this is a scam. It was a payment change, so I stopped and called."
That's a security win. Most programs don't count it at all.
What this looks like
One invoice, and why spotting the fake can't save you.
A vendor you've paid for two years emails new bank details, and it arrives in the thread you've been on since March. The amount matches the invoice you were already expecting. The purchase order number is correct. The note explains the old account closed during a merger, and apologizes for the short notice.
There's no misspelled address, because the sender really is the vendor's address. There's no broken grammar and no threatening deadline. Nothing about the message is wrong, because the account that sent it was broken into three weeks ago and the attacker has been reading the thread the whole time.
A security professional reading that email on its own can't tell either. That isn't a training failure. That's the attack working the way it was built to.
Recognizing it isn't what stops it. A change to payment details means a call back to the number already on file, and a second person to approve it. Neither step asks anyone to decide whether it's fake. They only need two things: that a payment change was already on somebody's list, and that somebody stopped long enough to follow it.
That's the whole plan. The person doesn't need to be right about the email. They need to have been told, well before any of this arrived, that a payment change is a request nobody goes ahead with alone.
TopThe plan
What we train instead
A list, then three steps. None of them requires anyone to work out whether something is fake.
The list comes first, and writing it isn't the staff's job. Six kinds of request, named below, decided on an ordinary Tuesday, not at 8:55 on a Sunday morning. Each one goes on a card with who to call and their number. When one of them arrives, three things happen.
-
01
Stop
Don't send the payment, share a password or code, approve the request or grant access. Not yet. Stopping is what protects the organization, and it works whether or not anyone has worked out what the message is.
-
02
Call
Call the primary contact the card names for that request, on the trusted number written there. Often that's the person the request claims to come from, and if they don't pick up, the backup. Don't investigate it. Don't reply to find out. Don't call the number in the message.
-
03
Wait
Keep the request on hold until the person you called says go. No reply is not a yes, and leaving a message doesn't mean you can go ahead. A deadline in the message doesn't change that. Waiting is for the request, though. If something has already been clicked, approved or sent, call straight away.
Stop. Call. Wait. That's what the person says out loud. Three words, short on purpose, because they have to survive being remembered under pressure by somebody who isn't thinking about security. The hard part was finished before anyone walked into the room, on the day somebody decided which requests trigger the plan and whose number goes on the card.
In a church office, everyone knows their part. The secretary stops and makes the call. The pastor backs the secretary up while the request waits. The treasurer takes the call and makes the decision. Nobody has to guess what the others will do.
Stopping isn't a knowledge problem. It doesn't ask anybody to work out what the message is. It asks them to know they have arrived somewhere the organization already named, and to have been told that stopping there is the job. That's what the list is for, and the call moves the decision to whoever should own it.
Which is why it works in a building run by volunteers. The people with the most reason to want it to work are already in the room.
The card isn't theirs to write. It's yours.
Verify is a process, not a personal skill. The card is that process written down: who gets the call, on which number, and who's next if they don't pick up. Payment details change through a callback to a number already on file. New vendor access goes through the same approval every time. Those rules belong to finance and to IT, they run whether or not anyone felt suspicious, and they are the reason stopping is enough.
Asking anyone to independently verify a convincing request is how attackers talk people into approving them. It hands the decision back to the one person you just agreed shouldn't have to make it alone. The number on the card was chosen before the message arrived, so the message gets no say in who is called.
What this gets you
Not another program to run.
If you run IT, you already look after the servers, the accounts, the computers, the cloud apps, the network, the help desk, the backups, and the security tools. Then an awareness program lands on you, and now you're a teacher, a scorekeeper and the person who walks the executive director through their click rate, which is one more item on that list while the incidents keep coming anyway.
Done properly, training doesn't add a system for you to run. You don't need another thing for people to finish and forget. You need the training you already provide to be useful.
It doesn't make you the number on every card, either. If the whole plan is "call the IT person," and you're that person, congratulations. You've just been volunteered for every Sunday, every vacation and every emergency. Each card names who checks that kind of request, and a backup who has been tested.
You stay the expert, and we're there to back you up, not take over. When something has already been clicked, approved or sent, whoever it happened to calls the contact on the card straight away, and it comes to you as well, because someone still has to investigate and contain it. Training gets it there faster. Nobody has to pretend that staff are security controls.
The list
Six requests that trigger the plan.
Training people to notice everything asks for too much, and six specific requests is a list somebody can still hold on a Tuesday afternoon. Each one is genuinely hard to call, even for professionals, and each one has a process behind it that makes stopping enough.
-
Payment instructions that changed
The vendor invoice worked through above. A grant payment redirected to a new account arrives the same way, and so does a direct-deposit change sent from an employee's real address.
-
An MFA prompt you didn't ask for
Your phone asks you to approve a sign-in, the multi-factor check known as MFA, and none of you is trying to sign in. It repeats until someone approves it to make it stop, and on an account three people share, nobody is certain it wasn't one of the others.
-
A financial request from leadership
The pastor's own address, asking the office administrator to move a payment or buy gift cards, sent on a Sunday morning when checking is hardest and saying no feels worst.
-
A vendor asking for access, unprompted
Someone from the giving platform calls about a failed donation batch and needs admin access to correct it. They know the batch failed, because it did.
-
A request to change or send member records
An email in a member's name asks the office to update their contact details and send a copy of the directory. A request for citizen records or a membership export works the same way.
-
A request to skip the usual approval
It has to be done before payroll closes. The person who normally approves it is unreachable, and the request explains why the usual route will not work this time.
The objection
The standards check coverage and a record.
The first question in the room is whether changing the goal puts your compliance at risk. It deserves a straight answer, not a comforting one. The standards check three things: that training covered social engineering, who got it, and when. Social engineering means tricking a person rather than a computer. One of them goes further and names behaviors. CJIS, the FBI's security policy for anyone who touches criminal justice information, asks for training on recognizing social engineering and on reporting it.
Not one of them requires that your staff become accurate at telling real from fake, and not one measures them on it.
So the standards mostly leave the goal to you, and the goal is the part that decides whether any of it works. The three steps are taught to the same people, on the same schedule, and recorded the same way. The standards themselves, with who they reach and when they applied, are on their own page.
If CJIS reaches you, as an agency or as a vendor with access, read its recognizing requirement closely. In this model, recognizing means knowing you have reached one of the six named situations, not judging whether something is an attack. Put that reading to your auditor before you rely on it.
One caveat if you are local government. In Ohio the program itself has to be adopted by your legislative authority, so this is a proposal you take to them rather than a change you make quietly.
TopMeasurement
Click rate answers a question you didn't ask.
It tells you how many people failed a test you designed and scheduled. It doesn't tell you whether the person holding the next real request knows who to call. The question worth asking is whether the plan works for the people who have to use it.
-
01
What they say when you ask
Ask "Who do you call? What has to wait?" instead of "Is it real?" Listen to the answer, then ask a follow-up. If somebody gets stuck, work through it together and let them try again.
-
02
Whether the backup answers
Test the names on the card. Can you reach them? Do they have the authority? Do they know how to respond? Have they tried it? You wouldn't trust an untested backup of your data. Don't trust an untested backup of yourself.
-
03
How fast a mistake reaches you
When something has already been clicked, approved or sent, the time until IT or security hears about it. Someone still has to investigate and contain it, and that time is the part training can shorten.
None of these replaces knowing whether dangerous actions dropped. What they tell you is narrower and still worth having: whether the plan holds up before a real request tests it.
What you are looking for doesn't arrive as a number. It looks like somebody still calling it across a shop floor months later, about a training nobody scored. What that looked like.
The mission
Cybersecurity for people,
not just systems.
Everything above is how that works in practice.
Next
This is what our training does.
Every workshop we run is built on the plan above, whether we are teaching your staff directly, coming in as the trainer for your IT provider, or teaching your IT team to run it themselves.