Your staff are the control that fails first

When an institution asks us to look at how a fraud happened, the answer is almost never that an attacker broke the encryption. It is that someone phoned the branch, sounded authoritative, and was helped.

This is not a story about careless employees. It is usually the opposite. The people who get exploited are frequently the most helpful, most responsive staff you have — the ones who resolve things rather than escalating, who don't want to make a customer wait, who take the call at 4:45 on a Friday. Social engineering does not attack a weakness in your people. It attacks a strength, and it does so precisely because you have trained for service quality.

The mechanics are consistent enough to be predictable. The attacker manufactures authority, urgency, and a reason not to follow the normal process. A caller who is from head office, who needs this before the cut-off, and for whom the usual channel is down. Any one of those alone would raise an eyebrow. Together they produce a scenario where following procedure feels like obstructing an emergency.

The second reliable pattern is that the attacker already knows things. The manager's name. The system your institution uses. Last week's outage. Details that in the victim's mind could only be known by an insider, but that in reality came from a public post, a job advertisement, or a previous conversation with a different branch. Familiarity substitutes for verification, which is the entire trick.

So what actually helps.

Make verification a right, not a discretion. If a staff member cannot end a call and phone back on a known internal number without needing permission, they will not do it under pressure. This has to be stated explicitly, repeatedly, by senior people: you will never be criticised for verifying, even if the caller turns out to be genuine and irritated. Until that is credible, service culture will beat security guidance every time.

Kill the mechanisms that make impersonation easy. Any process where an instruction can arrive by email or phone and be acted on without a second, independent channel is a standing invitation. Payment instruction changes, beneficiary details, account access resets — these need call-backs to numbers already on file, not numbers supplied in the request. The number in the email is the attacker's number surprisingly often.

Take the pressure out of the process. If your cut-off times are genuinely inflexible, urgency becomes a usable weapon against you. A documented exception path — slower, requiring a second approver — removes the leverage. The attacker's advantage comes from there being no legitimate way to be careful and still be on time.

Train on real incidents, not on generic examples. Every institution has stories: the near miss, the invoice that was almost paid, the caller who nearly got a password reset. Anonymise them and use them. A specific story about your own branch network lands in a way that a stock illustration about a fictional company never will.

And measure reporting, not clicking. If your phishing simulation programme's headline metric is click rate, you have optimised for staff quietly deleting suspicious messages. What you actually want is a high report rate and a fast one, because the reports are how you learn you are being targeted. An organisation where the first person to see a phishing email tells someone within five minutes is in a very different position from one where the tenth recipient clicks.

None of this is about making people suspicious of customers. It is about giving them a defensible way to slow down, and making sure that using it is never held against them.

The control that fails first is the one you never told anyone they were allowed to use.