Skip to article
BITTUMailPOWERED BY BITTU ICLOUD
The Mail BlogSecurity

A Safe Way to Verify an Unexpected Request From a Colleague

A practical routine for checking unexpected colleague requests involving access, money, or confidential material—without relying on contact details in the message.

Original paper illustration of a sealed blue envelope and brass key.
Original BITTU Mail editorial artwork. Illustrative image.

An unexpected email or chat can sound ordinary: a colleague needs a file before a meeting, asks you to change an account setting, or wants a payment handled quickly. The risk is not limited to messages that look obviously suspicious. A familiar name or convincing writing style does not confirm who sent a request. Use a short routine before acting: pause, reach the person through a contact method you already trust, and confirm the precise action and details. Keep that verification separate from links, numbers, and reply instructions in the unexpected message.

The useful bits

  • Pause before opening links, sharing files, changing access, or moving money.
  • Contact the colleague using a channel or details you had before the request arrived.
  • Confirm the exact action, recipient, amount, file, or deadline before proceeding.

Create space before you respond

Do not treat urgency as proof that a request is genuine. A short deadline may be legitimate, but it is also a reason to slow down enough to check. Avoid replying with sensitive information, opening an attachment, changing permissions, or starting a payment while you verify.

Leave the original message available for reference, but do not use its contact details to perform the check. If you are in a shared workplace, follow the usual process for sensitive actions rather than making an exception because someone says they are unavailable or the matter is confidential. If you cannot verify promptly, wait and tell the requester you are checking through a separate channel.

Choose a channel you already know

Use contact information saved before the message arrived: for example, a number in your existing address book, a previously used work chat, or an established in-person route. Start a new conversation or call using that known route. Do not click a phone number, meeting link, or profile link supplied in the unexpected message, and do not simply reply to it.

The key is independence. If the message says to call a new number, switch to that number only after you have confirmed it from a trusted source separate from the message. If your normal channel is unavailable, ask a manager or use an established internal contact directory or procedure. Do not guess at an alternative.

Confirm the particulars, not just the sender

Ask the colleague to state what they want you to do, without reading the message back as a prompt. A broad confirmation such as “Did you send that?” can leave important details unchecked. Verify the specific action and the details that would make it safe to carry out.

For an access request, confirm the person or account receiving access, the resource, and the intended level of access. For money, confirm the amount, recipient, and payment instructions using your normal approval process. For confidential material, confirm which file or information is needed, who may receive it, and what approved sharing method to use. If any detail differs, stop and resolve the mismatch first.

Keep the verification separate

Do not use a reply address, phone number, payment account, or link from the unexpected message to validate that same message. Those details are part of the request, not independent confirmation. Keep the original request and your verification conversation distinct so that a convincing message cannot steer the check back to information it supplied.

If the colleague confirms the request through the known channel, still follow your organization’s approval and access rules. A colleague’s identity does not automatically authorize every action. If they deny sending it, or cannot confirm the details, do not comply. Use your organization’s normal reporting route for suspicious messages, and avoid forwarding confidential material while asking for help.

A realistic check in practice

Suppose an email appears to come from a project colleague and asks you to send a confidential file to a new external address before a meeting. The message includes a phone number described as the colleague’s temporary contact. Do not call that number or send the file. Use the colleague’s previously saved work contact or an established chat instead, then ask them to identify the file, intended recipient, and approved sharing method.

EXAMPLE / ADAPT TO YOUR SITUATION
Unexpected message: “Please send [confidential file] to [new recipient] before [deadline]. Call [number in message] if you have questions.”

Separate check through a previously known channel: “Did you request [confidential file] for [recipient]? Which approved sharing method should I use?”

Proceed only if the colleague confirms those exact details and the request follows your normal approval process.

Know when the check is complete

You have verified the request when you reached the person through a channel known before the message, heard a clear confirmation of the exact action and relevant details, and checked that the action is permitted by your usual process. A familiar display name, a quick “yes,” or a successful reply to the original message is not enough on its own.

If the person cannot be reached, the details remain unclear, or the request changes during the check, leave the action undone and seek guidance through an established workplace route. Keep any necessary record in line with your organization’s practices, without copying sensitive content into an unnecessary message. The aim is not to prove who sent every message; it is to avoid taking a sensitive action until the request has been independently confirmed.

About this guide

Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.

View current plans · Security information · Suggest a correction