What should employees do before clicking a link or answering a suspicious call?

Pause before you trust the channel

A suspicious link or call is risky because the attacker is trying to get you to act before you verify. The safest habit is to slow the interaction down, check whether the request is expected, and switch to a trusted path that you initiate yourself. That breaks the attacker’s main advantage: urgency.

For links, the key judgment is whether the destination can be reached without using the message itself. A manually entered URL, bookmarked site, or known portal is safer than a clicked path because it removes hidden redirects and lookalike domains. For calls, the same logic applies: do not rely on the caller ID or the number offered during the call if you need confirmation.

When the request is legitimate, the separate verification step should still be easy to complete. If it becomes difficult to confirm through a known channel, that is useful signal in itself, because real business requests usually survive a pause and a callback.

How to verify without creating more risk

Verification should use contact details you already trust, not contact details supplied by the requester. That means checking the sender address carefully, reviewing the full domain, and using an independently sourced number or website when you need to confirm the request. The point is to compare the request against an outside reference, not to continue the conversation on the attacker’s terms.

A good verification routine also limits what you reveal. If you call back, ask for the minimum needed to identify the request, then verify the issue through a known internal process or a previously established contact route. Do not share passwords, one-time codes, or sensitive account details just because the request sounds urgent or official.

This is also where repetition matters. Employees need a simple rule they can apply under pressure: stop, verify, then act. The easier the rule is to remember, the more likely it is to hold when a message is designed to create haste.

Why this simple habit stops common social engineering

Phishing and pretexting work because they mix believable context with pressure, making the first response feel like the right one. Verification interrupts that flow. It forces the request to survive scrutiny, and many fraudulent messages fail as soon as they are tested against a known website, a trusted callback number, or a second channel.

That matters because the harm is often not the link or the phone call itself, but what follows after the victim authenticates, approves, or discloses something. A brief pause can prevent credential theft, fraudulent payments, malware delivery, and account takeover. In practice, the most effective defense is not perfect detection, but a consistent habit of independent confirmation.

For teams that handle sensitive access or payment actions, NHIMG’s Ultimate Guide to NHIs shows how weak verification and secret exposure can turn a single mistake into broader compromise. The same principle applies to human social engineering: if the request cannot be validated through a trusted path, it should not be trusted for action.

Risk and Threat Considerations

Suspicious links and calls are high-risk because they exploit the moment between recognition and action. Attackers rely on urgency, authority, and convenience to get a user to click, disclose, or approve before verification happens.

Failure mechanism: The user follows the message’s built-in path, which can lead to credential harvesting, malware delivery, or fraudulent instruction, instead of confirming the request through an independent channel.

Impact: A single click or callback can expose accounts, enable impersonation, or trigger financial and operational loss if the request is accepted as genuine.

Practitioner Guidance

What to verify: Train employees to verify the destination, the sender, and the requester's identity through a separately trusted source before any action. The important control is not “spotting a bad message” but proving the request through a path the attacker does not control.

Decision rule: If the request asks for credentials, MFA codes, payment changes, or rapid action, require an independent callback or manual navigation to a known portal before proceeding. If the request cannot survive that test, treat it as unsafe regardless of how polished it looks.

Practitioner takeaway: The objective is to make urgency irrelevant, because a legitimate request can withstand verification while a deceptive one usually cannot.

Related resources from NHI Mgmt Group

• What should teams verify before letting an agent call identity APIs?
• What should organisations do before allowing employees to use autonomous AI assistants?
• How should banks design fraud monitoring so suspicious transfers can still be stopped before settlement?
• What should teams verify in logging before they call it investigation-ready?