What should teams do first when payroll diversion is suspected?

What teams should do before touching payroll instructions

The first priority is to treat the report as potentially genuine but not yet trusted. Verify it through a known contact channel, pause any payment changes, and confirm the employee and bank details before anyone updates the payroll system or approves a redirection request.

This is less about investigating motive and more about stopping unauthenticated instructions from taking effect. If the request came through email, chat, or a self-service portal, the team should switch to an out-of-band check using a number or contact method already on file.

How to verify without helping the diversion

Use a trusted call-back process that does not rely on the channel where the change request arrived. Confirm the employee’s identity, the exact change requested, and whether any recent banking update, address change, or manager approval explains the request. If the details do not line up, hold the change and escalate immediately.

Where payroll changes are time-sensitive, the safe approach is to slow the process rather than speed it up. A valid request can wait for verification; a fraudulent one usually benefits from urgency, secrecy, and a short processing window.

What to preserve and who to tell

Keep the original message, timestamps, headers, screenshots, portal activity, and any approval trail intact so responders can reconstruct how the request was made. Notify payroll, finance, and fraud responders at the same time so payment holds, account reviews, and recovery actions can begin in parallel.

If the suspicion is tied to a compromised mailbox, HR portal account, or payment workflow, the issue is no longer just payroll administration. It becomes an access-and-trust problem, and the team should review whether the attacker may still be able to submit or alter instructions.

Risk and Threat Considerations

Payroll diversion works because payment workflows are designed to trust change requests that appear routine. The main risk is that one unauthenticated instruction can redirect recurring salary payments before the fraud is noticed, especially when approvals are rushed or handled by staff who are not used to challenging urgent requests.

Failure mechanism: The attacker impersonates an employee, compromises an inbox or HR account, or submits a fake change through a legitimate workflow, then exploits delay in verification to let the altered bank details take effect.

Impact: Wages can be misdirected, payroll operations can be disrupted, and the organisation may need to recover funds, investigate account compromise, and review whether other employees were targeted through the same route.

Practitioner Guidance

What to prioritise: Stop the change first, then verify it. If the request cannot be confirmed quickly through a known contact path, treat it as suspicious and keep the payment instruction frozen until proven otherwise.

What to verify: Check whether the request matches a known employee, a known bank account pattern, and a normal approval path. Mismatched contact details, unusual urgency, or a request that bypasses usual controls should be treated as strong warning signs.

Practitioner takeaway: In payroll diversion cases, the safest first move is to preserve the current payment state while verification happens out of band, because speed without authentication is exactly what the fraud depends on.

Related resources from NHI Mgmt Group

• Guide: Payroll Diversion Fraud Guide
• What should teams do in the first 24 to 72 hours after suspected package compromise?
• What should teams do in the first 24 to 72 hours after token abuse is suspected?
• What should organisations do first when infostealer activity is suspected on user endpoints?
• How should security teams reduce the impact of lateral phishing, invoice fraud, and payroll diversion as attackers target human behaviour instead of technical flaws?