They should treat it as a contained incident, not just a training moment. The employee should hang up, record the details, and report through an official channel so security teams can assess whether the call was part of a broader campaign. Quick reporting improves containment, supports investigation, and helps teams spot patterns across channels, departments, and access levels.
Why This Matters for Security Teams
A suspicious call is often an early indicator of social engineering, credential harvesting, or pretexting aimed at employees who can approve payments, reset access, or reveal operational details. Security teams should treat the event as a reportable signal because the value is not only in the single call, but in the attacker’s attempt to map people, processes, and control gaps. The NIST Cybersecurity Framework 2.0 places clear emphasis on response, recovery, and continuous improvement, which is exactly the posture needed here.
What organisations often get wrong is assuming the call is harmless because no password was shared or no money moved. In practice, a caller may be testing whether a target will follow instructions, disclose workflow details, or bypass internal checks on a second attempt. That makes fast reporting, preservation of call details, and correlation with other alerts essential for both incident handling and fraud prevention. In practice, many security teams encounter the campaign only after a second employee has already engaged with the caller rather than through intentional early reporting.
How It Works in Practice
The right response is to move the event into a simple, repeatable incident path. The employee should stop the conversation, note the caller identity, number, time, wording, and any requested actions, then use an official reporting channel such as the service desk, SOC intake, or security hotline. From there, analysts can decide whether the call is isolated, part of a phishing or vishing campaign, or linked to account takeover attempts.
Operationally, the goal is to preserve useful context. That means teams should capture:
- the phone number, caller ID, and any extension or voicemail callback details
- the exact request, especially if it involved MFA codes, passwords, wire approval, access changes, or device instructions
- the business unit, role, and system access of the targeted employee
- whether the same script or caller ID appears in other reports
This process should be backed by playbooks that integrate awareness, triage, and investigation. NIST guidance on incident handling and the broader response lifecycle helps organisations standardise escalation, while detection teams can compare the event against known social engineering patterns. For threat pattern mapping, MITRE ATT&CK is useful for understanding how initial access attempts and credential abuse often unfold across channels. Where organisations have voice systems, call logging and security operations correlation can also support trend analysis alongside email and endpoint alerts.
Security leaders should also decide in advance what happens next: whether the account owner is temporarily flagged for extra verification, whether related help desk requests are reviewed, and whether finance, HR, or executive assistants need a targeted warning. The best outcomes come from rehearsed reporting paths, not from ad hoc judgment during the call itself. These controls tend to break down in organisations with decentralised help desks and no single incident intake point because reports are delayed, duplicated, or never correlated.
Common Variations and Edge Cases
Tighter call-handling controls often increase workflow friction, requiring organisations to balance faster reporting against employee convenience and business urgency. That tradeoff becomes more visible in customer support, executive offices, and finance teams, where legitimate external calls are frequent and the pressure to respond quickly is high.
Some environments need extra nuance. For example, a call may be part of a legitimate vendor verification process, a journalist inquiry, or a lawful testing exercise by an internal red team. Current guidance suggests these cases should still be logged if they involve identity, access, or sensitive operational details, because the control value lies in traceability. There is no universal standard for recording every suspicious call, but consistent escalation criteria are more important than perfect detection.
Identity-sensitive functions deserve special attention. If a caller asks for password resets, MFA resets, payroll changes, privileged access, or knowledge of internal tooling, the event may intersect with account takeover risk and privileged access management. That is where CISA insider threat guidance can help shape broader reporting and escalation expectations, even when the incident is external rather than insider-driven. Organisations should also consider whether a suspicious call is the opening move in a multi-channel campaign that later continues by email, SMS, or chat. If the call targeted a service desk or identity verification workflow, the case should be reviewed as a trust and process issue, not only as a user-awareness issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.AN-1 | Suspicious calls need triage and analysis to decide if they indicate broader compromise. |
| MITRE ATT&CK | T1566 | Vishing is a social engineering entry point commonly used to initiate attacks. |
Triage the report quickly, correlate it with other signals, and determine whether escalation is needed.
Related resources from NHI Mgmt Group
- How can organisations prevent orphaned AI agents after employee turnover?
- Should organisations rotate secrets after employee off-boarding?
- What should organisations do after an employee uses generative AI with business data?
- What should organisations do first after detecting suspicious package installation behaviour?
