What should employees do first when they receive a suspicious request?

Why the first move is to slow the request down

The safest first response is to create a verification pause. Suspicious requests often succeed because they pressure the recipient into acting quickly, so the goal is to break the apparent urgency and confirm the person, channel, and context before any action is taken.

That pause matters even when the request seems routine. A convincing email, chat message, or phone call can still be fraudulent, and the request may be designed to trigger credential theft, payment diversion, or an improper approval.

Verification should happen outside the thread or message that carried the request. Use a known phone number, an internal directory, or an established ticketing workflow so the response is tied to a source you already trust rather than to the message being challenged.

What not to do before identity and intent are confirmed

Do not click embedded links, open unexpected attachments, or forward secrets while the request is still unverified. Those actions can expose credentials, tokens, or internal information before anyone has had a chance to confirm whether the request is legitimate.

Also avoid replying with helpful partial information that could support a later abuse attempt. Even confirming that a mailbox, account, vendor, or project is active can help an attacker refine a social engineering attempt.

If the request asks for an urgent exception, a change in payment details, MFA approval, password reset, or access approval, treat the exception itself as a warning sign. Pressure to bypass normal checks is often what makes the request dangerous in the first place.

How to confirm and escalate without delaying the response

The best practice is to verify first, then escalate quickly if the request still looks suspicious. If the requester cannot be validated through an independent channel, route the case to security or a manager and preserve the original message for review.

FIRST incident response coordination guidance is useful here because suspicious requests often become incident-handling problems once fraud or compromise is suspected.

NIST Cybersecurity Framework 2.0 supports the basic operational pattern: identify the request, protect the user from unsafe action, detect the anomaly, and respond before damage spreads.

NIST AI Risk Management Framework is also relevant where a suspicious request may be generated or amplified by automated systems, because the same verification discipline helps keep delegated actions bounded and reviewable.

Risk and Threat Considerations

Suspicious requests are high-value because they exploit trust, urgency, and routine approval habits. The main risk is not just that a single message is fake, but that a hurried response can expose secrets, authorize a fraudulent action, or create a foothold for follow-on abuse.

Failure mechanism: The attacker relies on the recipient treating the message channel as proof of identity, then uses urgency or authority cues to push the person into acting before independent verification occurs.

Impact: The result can be credential theft, unauthorized payments, session compromise, malware execution, or an approved change that should never have been granted.

Practitioner Guidance

What to verify: Confirm the requester through a second channel that you already trust, and verify the request details independently rather than asking the sender to restate them in the same thread. If the request concerns money, access, credentials, or sensitive data, verification should be mandatory, not optional.

Decision rule: If the request cannot be validated quickly through a known contact path, stop work and escalate. Do not let convenience override the need to establish identity and intent before action.

Practitioner takeaway: The first control is not technical, it is procedural discipline: separate the verification step from the message itself, because that small pause is what prevents a suspicious request from becoming an incident.

Related resources from NHI Mgmt Group

• What should employees do when they receive a job offer or recruitment message from an unknown sender?
• What should teams do first when they suspect a public repository has been cloned and altered for a pull request attack?
• How should malware analysts approach reverse engineering when they first encounter a suspicious binary?
• What do employees get wrong when they try to verify a suspicious email or text?