The boss wants an exception: designing a process that can survive authority
A process is not reliable if the people with the most organizational status can silently bypass it. Build escalation and verification into the rule itself.
An employee receives a message from a senior leader: make the payment now, keep the acquisition confidential, and do not slow things down with the normal approval chain. The employee sees two risks. Complying may move money on a fraudulent request. Refusing may look obstructive, disloyal, or incapable of handling urgency.
Security advice often tells the employee to “be suspicious.” That leaves the hardest part untouched. Status changes the social cost of verification. A junior colleague can recognize every warning sign and still comply because the organization has never given them an acceptable way to pause a powerful person.
The FBI’s business email compromise guidance recommends verifying payment and purchase requests directly and treating urgency as a warning. The design question is how to make that verification an expected service to the organization, not an act of personal defiance.
Authority, urgency, and secrecy make ordinary checking feel socially expensive.
An “exception” route that removes the same controls designed for high-impact decisions.
Create a faster governed route with independent approval, known contacts, and a visible audit trail.
An exception is still a process
Real organizations have emergencies. A factory line stops, a supplier changes terms, or a legal filing cannot wait. A rule that assumes every transaction has three calm days will be bypassed. The answer is not to eliminate the rule; it is to define an emergency path before an emergency arrives.
That path should identify who can declare urgency, which controls remain mandatory, what temporary limits apply, and how the action is reviewed afterward. For example, an emergency supplier payment might allow a shorter deadline but still require independent contact using the supplier master record and a second approver. The limit could be lower than the ordinary payment authority, not higher.
| Weak exception | Governed exception |
|---|---|
| “The CEO said it is confidential” | Confidentiality limits distribution but not required approval |
| Approval in the same email thread | Second approver uses the transaction system or known contact |
| New phone number supplied in message | Number comes from the directory or prior supplier record |
| Vague urgency | Deadline and operational consequence are recorded |
| No time for documentation | Minimal record now, mandatory review after the event |
Make the protective script legitimate
Employees need language that protects the relationship while preserving the boundary. A useful script does not accuse the requester:
“I can move this through the urgent-payment route. It requires confirmation through the directory and a second release. I’ll start both now.”
That sentence accepts the goal, names the process, and gives a next step. It moves the conflict from employee versus executive to request versus established governance. If the requester is genuine, they learn what is needed. If the request is fraudulent, the attacker must cross an independent channel.
Leaders have a special role here. They should state publicly that verification is expected even for their own requests and should respond calmly when challenged. A policy in a handbook cannot overcome a leader who punishes the first person who uses it.
Our discussion of manufactured urgency explains how deadlines narrow the perceived choice. The exception design should widen it again: pause, route, confirm, or decline. “Do it now or fail” is rarely the complete operational picture.
Separate confidentiality from isolation
Legitimate deals, investigations, and personnel matters may need restricted knowledge. Attackers exploit that reality by turning confidentiality into “tell nobody.” Those are not equivalent.
A confidential workflow should still have named participants: legal counsel, finance leadership, a designated approver, or an incident contact. Access can be logged and limited. The requester does not get to invent a one-person process merely by using a sensitive project name.
A secret that cannot survive contact with any authorized colleague is not a workable control environment.
Organizations can maintain a small roster for restricted approvals. Employees do not need to disclose transaction details broadly; they need one authorized route that the requester cannot replace. This also protects genuine leaders from mistakes and compromised accounts.
Controls that resist real accounts and real voices
A lookalike address is only one version of the problem. The senior leader’s actual mailbox may be compromised. A voice call may be imitated or routed through a new number. The executive may genuinely ask for something outside their authority.
Design controls around the effect:
Payment destination changes require verification against the existing vendor record and dual approval.
New beneficiaries require legal-entity information and a hold before first release.
Credential or data requests require an approved transfer channel and least-privilege access.
Recovery changes trigger notifications to the old contact and a reviewable delay.
High-risk exceptions create an incident-style record that cannot be erased from the requester’s channel.
This is why the invoice bank-change workflow remains useful even when the email is technically authentic. The control validates a business change, not just a message.
Test the human path
Tabletop exercises should not only show a bad email and ask whether participants spot it. Give a participant a realistic message from a simulated executive during a busy period. Then observe the surrounding system.
Can they find the emergency policy quickly? Does the directory expose a known contact? Is a second approver available across time zones? Does the payment system preserve a hold? Does the simulated leader reward the challenge? If the correct action requires knowing an obscure phone extension or risking public embarrassment, the organization has tested memory and courage rather than the process.
Record false-positive cost as well. If every urgent request waits for a committee that never meets, employees will create side channels. Tune the route so that verification is faster than improvisation.
After an exception request
If the request is suspicious, preserve the original message and report it through the organization’s incident channel. Do not continue a long exchange to collect proof; engagement can reveal which objections an attacker needs to answer. Security teams should review similar messages, account activity, forwarding rules, and pending transactions.
If the request was legitimate, the event can still reveal a process gap. Did the requester know the route? Was the approver unavailable? Did the policy require information no one could obtain? Fixing those problems is not “giving in” to urgency. It is making the approved system usable enough to displace unsafe shortcuts.
Authority is a normal coordination tool. Social engineering works when authority becomes permission to erase boundaries. A mature organization lets leaders set priorities while requiring consequential actions to pass through controls that no single message can cancel.
An earlier FBI case summary on business email compromise controls specifically recommends secondary sign-off and calling previously known numbers for transfer requests. Those measures work because they distribute authority rather than asking one recipient to out-argue a senior persona.
Found a factual error or a source that has changed?
Send a correction →
