Verify out of band: the callback rule
When a request is risky, check it through a different channel you already trust. Here's how to design a verification procedure people will actually use.
In 60 seconds
Verify out of band: the callback rule
When a request is risky, check it through a different channel you already trust. Here's how to design a verification procedure people will actually use.
Why 'in band' checks fail
The building blocks
- 1
Define high-risk requests
Payments, bank or payee changes, payroll changes, password or MFA resets, new access, sharing sensitive data, gift cards. - 2
Call back on a known number
Use the company directory, your vendor records or a contract. Never a number from the request itself. - 3
Use code words for the highest risks
Agree a phrase or question in person for very sensitive requests. Change it if it may have leaked. - 4
Two-person rule
Payments and access changes need a second person who verifies independently. - 5
Make 'no' safe
Anyone may pause a request to verify it, even from the boss, without blame. - 6
Record it
Note who verified, how and when. This helps audits and investigations.
| Request arrives by… | Verify by… | Never verify by… |
|---|---|---|
| Phone call to the known number, or in person | Replying to the email | |
| Phone or voice note | Call back on the directory number, or message on the company chat | Calling the number that called you |
| Video call | Leave the call; phone the person on a known number | Asking people on the same call |
| WhatsApp or SMS | Call the known number or check in person | Replying in the same chat |
| Company chat | Phone call or in person, especially for money or access | Asking in the same chat thread |
Make it OK to say no to the boss
"Thank you. As per our payment policy, I verify all
such requests by calling back on the directory number.
I'll call you in five minutes."Watch and read more
Lab
A one-page verification policy for your team, ready to share with your manager.
The problem
Write a one-page verification policy for your team or a made-up small company. Include:
- Scope: a short list of high-risk requests.
- How to verify: which channel for each type of request, and where the known contact details are kept.
- Two-person rule: which actions need a second approver, and any amount threshold.
- Code words: whether you use them, for what, and how they are shared and changed.
- Leadership statement: one or two sentences from leadership saying checking is always welcome.
- Reporting: who to tell about a suspicious request, and how.
Then test it against one scenario: a WhatsApp voice note, in the MD's voice, asks HR to change the MD's salary bank account before today's payroll run. Mark the step where your policy stops it.
You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1Your policy is strong but staff skip it when busy. How would you find out, and what would you change?Reveal
Look at records: are verifications logged for every bank change? Ask staff privately what slows them down. Then simplify: shorten the high-risk list, keep contact numbers one click away, set backup approvers, and have leaders praise people who pause to check. A rule people actually follow beats a perfect rule they skip.
Q2An attacker has taken over your manager's company chat account. Which parts of your policy still protect you?Reveal
The callback to a known phone number still works, because the attacker controls the chat, not the phone. The two-person rule adds a second independent check. Code words help if they were never typed in chat. Reporting lets IT lock the account. This is why no single channel should be enough for high-risk actions.
Questions people ask
What if the real person is travelling and can't answer the callback?
Then the request waits, or goes to a named backup approver who is verified the same way. A real urgent request can almost always wait a short time. Plan backups in advance so this doesn't create pressure.
Isn't a code word enough on its own?
No. Code words can leak, be forgotten, or be shared in chat by mistake. Use them as an extra layer for the highest-risk requests, together with callbacks and a second approver.
How do we keep the known-number list safe?
Treat it like bank details. Changes need verification and approval, and are logged. An attacker who can change the phone number on record can defeat the callback rule.
Does this apply to small amounts too?
Set a clear threshold for payments, but apply the rule to all bank-detail changes, access changes and sensitive data requests, whatever the amount. Attackers sometimes start small to build trust.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.