THE SHORT ANSWER

Reduce BEC risk by independently confirming new or changed payment instructions, separating vendor-data changes from payment approval, requiring a second approver for consequential exceptions, and recording confirmation outside the requesting email thread.

Build on the existing BEC explanation

Read Phishing, Social Engineering & Business Email Compromise for recognition and message handling. This resource starts after the request reaches a finance, procurement, payroll or admin process.

Evidence & context: Cybersecurity and Infrastructure Security Agency

Make consequential changes require independent confirmation

  • Call a known vendor or colleague contact when payment instructions change.
  • Separate permission to edit vendor master data from permission to release payment.
  • Require a second approver for defined amounts, new destinations and urgent exceptions.
  • Record confirmation in the business system, not only in the email thread.

Evidence & context: Federal Bureau of Investigation

Treat urgency as a reason to preserve the control

An exception route should name who can authorize it, what evidence is needed and how it will be reviewed. If leaders routinely bypass controls, employees learn that verification is an obstacle rather than part of the work.

Walk through one request safely

Choose a non-live example such as a supplier bank-detail change. Identify the requester, data owner, approver, known callback record and evidence retained. Fix unclear ownership without constructing a realistic scam message.

Sources & further reading

  1. Business Email Compromise

    Federal Bureau of Investigation. Official defensive guidance explaining BEC and recommending independent verification when account numbers or payment procedures change. Reporting routes are United States-specific.

  2. Phishing Guidance: Stopping the Attack Cycle at Phase One

    Cybersecurity and Infrastructure Security Agency. Current defensive guidance on phishing resistance, MFA and organisational controls. Specific authentication choices depend on service support and risk.

Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.

A correction, a counterexample or an experience worth sharing?

Join the conversation ↗