I've delivered more security awareness sessions than I can count. I'm also a social engineer, which means I've been the person those sessions are trying to prepare people for. That gives you a unique view of the problem.
I’ve delivered more security awareness sessions than I can count. I’m also a social engineer, which means I have been the person those sessions are trying to prepare people for.
That gives you a unique view of the problem. You start to see the gap between the version of social engineering people are often trained to spot, and the version that actually works in the real world.
It is the kind of gap that helps explain why an organization can run a mature, well-funded awareness program, see phishing simulation results improve year on year, and still find itself exposed in ways the training was built to help prevent.
The problem is not that people are not paying attention. It is that they are often being taught to pay attention to the wrong things.
A lot of security awareness training is built around a recognizable character. The imagined attacker is urgent, pushy, slightly threatening. They rush people, apply pressure, and make requests that feel strange, clumsy, or outside the normal context of the person receiving them.
That character is useful because it is easy to teach. You can build a module around it. You can test whether people recognize it. You can show improvement over time. The problem is that this character often has very little to do with effective social engineering.
The effective social engineers I have worked with are not usually cold, aggressive, or forceful in the moment. They are warm, patient, easy to talk to, and often just technical enough to sound plausible while still needing help. They sound normal. They sound grateful. They sound like somebody you would probably be happy spending ten minutes on the phone with.
In the kind of work I do, the goal is often to become the easiest interaction someone has that day. If the person on the other end has spent the morning being chased by frustrated users, I do not want to be another problem. I want to be the person who understands they are busy, who is polite, who is grateful, and who makes the conversation feel lighter rather than heavier.
That matters because people often have a picture in their head of what an attacker is supposed to sound like. The scammer. The bully. The impatient caller. The person who gets angry when challenged. A good social engineer knows that picture exists, and then steps around it.
They deliberately do not sound like the thing you have been warned about. They become the opposite of the stereotype: friendly, a bit lost, helpful, grateful, normal.
That is the bit that makes this hard. The attack is not always trying to look dangerous. Sometimes it is trying to look like the kind of interaction you have been rewarded for handling well every day of your working life.
Effective social engineering lives in ordinary moments: the service desk agent with too many tickets open and a queue that keeps growing, the HR coordinator helping someone who sounds stressed and embarrassed, the receptionist who does not want to be difficult when someone friendly and plausible is standing in front of them.
These people are not failing because they are stupid. Often, they are doing exactly what good colleagues are asked to do. They are helping, keeping things moving, and giving somebody the benefit of the doubt.
That is why we need to be careful about how we talk about people after social engineering incidents. If the conversation becomes “they should have known better”, we miss the more useful question: what did the system ask of them in that moment?
A colleague of mine once failed every single verification question on a service desk call. Not one or two. Every one. And still walked away with the credential reset.
That did not happen because the person on the other end did not care about security. It happened because the rapport had been built carefully enough that the person wanted to help, and the process did not have a strong enough answer for what to do when someone nearly passed. When the caller was plausible. When the conversation felt human. When saying no felt awkward.
That is not a story about a careless employee. It is a story about a process that had been written as if verification would be neat, clean, and binary.
Real conversations rarely are. Passwords do not allow near misses. People do. Processes often do too. And that is where things get messy.
A lot of awareness training tells people to challenge suspicious requests. That is good advice, but it is only half the story. What happens after they challenge? What happens when the caller has an answer that is almost right? What happens when they sound reasonable? What happens when the employee feels like they are being awkward, obstructive, or rude?
Most people are not looking for conflict at work. We smooth things over. We avoid unnecessary friction. We try not to make things harder than they need to be. A social engineer can use that, not by shouting, but by making the safe action feel socially harder than the unsafe one.
That is why process matters so much. You might give staff a list of verification questions, but does the process say exactly how many need to be answered correctly? Does it explain what to do with near misses? Does it give someone the language and backing to say, clearly and comfortably, “No, that was not quite right. I cannot continue with this request”?
These are not small details. They are the difference between a process that exists on paper and a process that survives contact with a real human conversation.
The training says challenge. The real world says that feels awkward. The challenge gets softened, the request gets processed, and from the outside it looks like a training failure. Often, it is not. It is a design failure.
The person was told to spot something suspicious, but the organization did not make the safe next step clear, supported, and socially survivable.
This is also why good simulation results can be misleading. Phishing simulations have improved a lot of people’s ability to recognize suspicious emails, and that is a good thing. But it is not the same as being resilient to social engineering.
A simulation usually tests one known attack pattern, through one channel, in a fairly controlled way. It does not always test a bad day, a short-staffed team, operational pressure, a phone call, a visitor at reception, or the moment where someone has a gut feeling but cannot quite explain it.
Most importantly, it does not always test the process around the person.
A good simulation result might tell you that people can recognize a particular kind of email. It does not tell you whether your service desk process holds when a caller is warm and plausible. It does not tell you whether managers will support somebody who slows down a legitimate request because something did not feel right. It does not tell you whether the safe action is actually the easy action.
That is where resilience lives.
Good security awareness should not make people paranoid. It should not turn every caller into a threat, every visitor into a problem, or every colleague into someone to distrust. That would be miserable, and it would also be bad security, because people cannot live in that state all day.
What good awareness should do is help people notice the small things: the pause, the mismatch, the detail that is not quite right, the request that is not obviously wrong but does not quite sit properly either.
Then the organization has to meet them there, with clear processes, verification steps that are treated as absolute rather than decorative, escalation routes people understand, managers who back the pause, and a culture that says “thank you for checking” even when the request turns out to be legitimate.
Because verification is not rudeness. Slowing something down is not failure. Asking a caller to prove who they are is not bad service. In many cases, it is the kindest thing you can do for everyone involved.
The attack your training prepared people for may be real. Urgency exists. Pressure exists. Bad links exist. Strange requests exist. But if that is the only version of the attack people are trained to recognize, then they are being prepared for the loud version and left exposed to the quiet one.
The quiet one sounds normal. The quiet one is polite. The quiet one understands that most people want to help. It does not need somebody to ignore everything they were taught. It only needs the process to become slightly unclear at the exact moment the person needs it to be firm.
If your awareness program is working as designed and you still feel exposed, it may be worth asking what it is actually measuring. Is it measuring whether people can recognize the version of the attack they have already been shown, or is it testing whether the organization can support them when the request is plausible, the person is polite, and the safest thing to do is also the most socially awkward?
That does not mean awareness training is worthless. Far from it. It means training is only part of the answer. The rest is process, culture, escalation, verification, managers who back the pause, and systems that make the safe action clear, supported, and normal.
Trust is not the enemy. Trust is the thing that makes work possible. The job is to make it safer.
Iain Jackson is a social engineer at CovertSwarm with a background in teaching, conflict management, and over three years running offensive human-layer engagements. He also leads CovertSwarm’s academy.