A finance director receives an email from the chief executive requesting an urgent supplier bank-detail change. The message arrives in an existing thread, uses familiar language and has no malicious attachment. By the time the request is challenged, a payment may already be moving. A business email compromise response plan exists for this moment: when a plausible email becomes an identity, fraud and operational incident rather than a routine phishing report.

Business email compromise, often shortened to BEC, is different from high-volume credential-harvesting campaigns. Attackers may use a compromised Microsoft 365 account, spoof a trusted domain, register a lookalike address or impersonate an executive, supplier, solicitor or payroll contact. Their objective is usually to redirect funds, alter payroll details, obtain sensitive information or use a trusted mailbox to extend the compromise.

The response therefore cannot sit only with the SOC. Security, IT, finance, legal, HR, communications and senior decision-makers all need defined roles, authority and contact routes before an incident occurs.

What a business email compromise response plan must achieve

The first priority is to stop further loss. That can mean halting a payment, revoking an attacker session, disabling a compromised account, blocking malicious mail and warning recipients who may act on the request. The second is to establish what happened without destroying evidence needed for internal investigation, insurers, banks, law enforcement or regulatory decisions.

A workable plan should also distinguish between three related but different events: impersonation from an external address, takeover of an internal mailbox, and a supplier or partner compromise. The initial actions overlap, but the scope of investigation and remediation does not. A spoofed executive email may require sender blocking and payment verification; an account takeover requires identity investigation, mailbox remediation and a search for onward phishing.

Define an incident owner with authority to coordinate activity and make time-critical escalation decisions. In larger organisations, this is commonly the incident response lead or security operations manager. Define deputies too. BEC incidents often emerge outside normal working hours, and delays caused by uncertainty over who may suspend an account or contact a bank can be costly.

Start with rapid validation, not assumptions

An employee report is often the earliest and most valuable signal. Employees should be able to report suspicious messages from Outlook with minimal effort, while finance and procurement teams need explicit routes to challenge payment-change requests. A user who is uncertain should not need to decide whether an email is technically phishing before reporting it.

Triage should establish whether the message is isolated, impersonated or sent from a genuine compromised account. Analysts should preserve the original message and full headers, then assess sender authentication results, reply-to discrepancies, sending infrastructure, domain age where available, links, attachments and conversation history. They should also check whether the message was delivered to other mailboxes, reported by other users or part of a wider campaign.

If an internal mailbox is involved, investigate sign-in activity, multifactor authentication events, unfamiliar devices, mailbox rules, delegated access, OAuth application consent, forwarding settings and recent changes to recovery details. A successful sign-in alone does not prove a takeover, but it is a strong reason to expand the investigation. Equally, do not assume that a password reset alone has removed persistence.

Set severity by business effect

A credible payment instruction, payroll amendment or request for confidential data should receive an urgent fraud-led response even if technical indicators are limited. A compromised executive mailbox, shared finance account or privileged Microsoft 365 identity should normally be treated as high severity because of reach and authority.

Severity should reflect the likelihood of loss, the value of the requested transaction, the number of recipients, the sensitivity of exposed data and whether the attacker still has access. This allows the organisation to focus its most urgent response on the incidents that can cause the greatest harm.

Contain the fraud and the access

Containment needs to run in parallel. One workstream addresses the business transaction, while another removes attacker access and stops malicious communication. Waiting for every technical question to be answered before contacting finance is a poor trade-off when funds could be transferred within minutes.

For high-severity cases, the incident lead should ensure the following actions are considered immediately:

• Place a hold on pending payments and use independently verified contact details to speak with the supplier, customer or bank.
• Disable or restrict the affected identity where compromise is suspected, revoke active sessions and reset credentials through an approved recovery process.
• Remove unauthorised inbox rules, forwarding configurations, delegates and suspicious consented applications after evidence has been captured.
• Search Microsoft 365 for matching messages, URLs, senders and subjects, then quarantine or remediate copies from recipient mailboxes.
• Block known malicious indicators where controls support it, while recognising that BEC frequently uses legitimate services and rapidly changing infrastructure.

Where payment has been made, finance should contact its bank immediately through established fraud channels. The organisation should retain payment references, timestamps, recipient details and all relevant correspondence. Security teams must not promise recovery outcomes, but rapid reporting provides the best opportunity to interrupt or trace fraudulent transfers.

External communications need control. Staff may need a concise warning not to act on payment or data requests from a named account, but broad messages should not disclose unnecessary investigation detail. If a supplier relationship is affected, contact should be made through a known telephone number or contractual route, not by replying to the suspicious thread.

Investigate the attack path and blast radius

Once immediate harm is contained, investigate how the attacker gained credibility and what they did with it. For account compromise, build a timeline from initial suspicious activity through successful authentication, mailbox changes, messages read or sent, files accessed and remediation actions. This supports both technical recovery and a defensible record of decision-making.

Mailbox searches should look backwards as well as forwards. Attackers commonly review historic invoices, supplier names, projects and travel arrangements before sending their request. They may have accessed sensitive correspondence without downloading documents, so the scope assessment should consider mailbox content, shared mailboxes and connected cloud services.

Check for lateral activity. A compromised account can send convincing internal messages to colleagues, request credentials, distribute malicious links or establish trust for later fraud. Review whether recipients replied, clicked, shared information or completed transactions. If the mailbox had elevated rights, assess administrator activity and changes to conditional access, authentication methods and transport rules.

Preserve relevant audit logs, message traces, screenshots and copies of malicious emails in line with the organisation's retention requirements. Evidence collection should be proportionate: an investigation that takes days to approve or reconstruct will not help a live response.

Recover safely and communicate with purpose

Recovery is more than re-enabling an account. Confirm that authentication methods, recovery contacts, privileged roles, mailbox rules, delegated permissions and authorised applications are legitimate. Require the user to re-enrol in multifactor authentication if there is doubt about the security of the existing method. For privileged or high-risk identities, additional monitoring and access review may be appropriate before normal access is restored.

Legal, privacy and compliance teams should assess notification requirements based on the data involved, affected individuals, contractual commitments and regulatory obligations. The correct response depends on the facts. Not every BEC attempt creates a reportable data breach, but an assumption that no disclosure occurred can create avoidable exposure.

Communications should be factual and audience-specific. Finance needs transaction status and verification requirements. Affected users need clear recovery instructions. Leaders need business impact, decisions required and residual risk. Staff-wide messaging, where justified, should explain the relevant tactic and reporting route without turning a real incident into speculation.

Use each incident to improve phishing resilience

A BEC incident exposes gaps across people, process and technology. The review should focus on evidence, not blame. Was the message reported quickly? Did triage have enough context? Could analysts identify all delivered copies? Did finance have a mandatory out-of-band verification process for changed bank details? Did technical controls identify unusual forwarding, login or consent activity?

This is where human risk management becomes operational rather than theoretical. Targeted simulated phishing can reflect the tactics observed, particularly executive impersonation, invoice fraud and supplier-change requests. Training should give high-risk teams practical decision points: verify through a trusted channel, do not rely on a reply email, and report the original message promptly.

Threat intelligence from reported emails and completed investigations should feed back into Microsoft 365 protection, mailbox search playbooks, detection logic and executive reporting. Trends may reveal a repeatedly targeted department, a supplier ecosystem exposed to compromise, or an approval process that attackers can reliably exploit.

Wise Fish supports this lifecycle by combining employee reporting, phishing triage, remediation and specialist Cofense expertise for organisations that need phishing response to operate as a repeatable service rather than an improvised escalation.

The most useful test is not whether the plan looks complete in a policy folder. It is whether a finance employee, service desk analyst and incident lead can each take the right first action under pressure, with enough information to protect the organisation before a convincing email becomes a completed fraud.