Business Email Compromise Risk Assessment: A Practical Framework to Prioritize Controls and Reduce Residual Risk

Key takeaways

• A business email compromise risk assessment traces how impersonation reaches payment approval, then ranks attack paths by likelihood, impact, and control weakness.
• Independent callbacks, separated approval duties, and verified vendor records protect payments even when a mailbox or executive identity is compromised.
• Residual risk estimates should credit only controls that operate under realistic pressure, with evidence recorded beside every score.
• Multi-channel simulations, tabletop exercises, and role-based training show whether employees verify, report, and escalate unusual requests.
• Findings need one accountable owner, a remediation deadline, and scheduled reassessment so residual risk stays visible to leadership.

Want more from Adaptive in your Google results?

A business email compromise risk assessment evaluates how business email compromise (BEC) exploits people, payment processes, identities, email systems, and third parties to create financial and operational loss. Security and finance leaders use it to move beyond a one-time email audit or phishing test. It establishes an evidence-backed view of exposure, control maturity, and residual risk.

This guide explains how to map high-risk payment and data flows, assess role-based exposure, review identity and mailbox evidence, and verify controls such as independent callbacks, approval separation, MFA, and payment alerts. It also shows how to turn findings into a risk register, executive scorecard, tabletop exercise, and targeted security awareness training that measures reporting and verification behavior.

An effective assessment connects technical indicators such as suspicious sign-ins, forwarding rules, and lookalike domains with human decisions made under urgency or authority pressure. With this framework, security teams can rank the most consequential attack paths, assign accountable owners, and test whether safeguards operate in practice. Improvement work can then focus where it reduces both recoverable and unrecoverable risk.

Security leaders who want a live view of that exposure can see how Adaptive Security maps human risk across roles and channels before scoping the assessment.

What Is a Business Email Compromise Risk Assessment?

A business email compromise risk assessment is a structured review of the people, payment processes, identities, email systems, third parties, data, response capabilities, and recovery controls that cyberattackers could exploit to commit fraud or steal information. It shows how a BEC attempt could move from impersonation to financial approval and where existing safeguards would fail.

The assessment also assigns ownership for closing those gaps. A one-time email security audit, phishing test, or incident investigation captures a narrow slice of that risk. This assessment measures broader human-layer and business-process exposure before an incident occurs and creates a repeatable baseline for reducing it.

What Does a BEC Risk Assessment Cover?

A BEC risk assessment examines the full chain of trust behind a high-impact transaction. Email is one signal. The attack succeeds when an employee, approval workflow, identity control, vendor relationship, or recovery process accepts a false instruction as legitimate.

The FBI's 2025 IC3 Annual Report recorded $3 billion in reported BEC losses. That scale places payment authority and verification discipline at the center of the assessment, ahead of secondary email-security details.

The scope should follow the organization's money movement and decision-making paths. Review executive and finance impersonation exposure, accounts payable procedures, payroll changes, vendor onboarding, purchase-order amendments, wire-transfer approvals, password resets, mailbox delegation, forwarding rules, multifactor authentication, domain protections, and privileged access.

Assess how employees communicate with suppliers, customers, attorneys, recruiters, executives, and financial institutions. Cyberattackers target the relationship and the process as much as the inbox.

A complete review also examines people and information. Identify employees with payment authority, access to sensitive data, public executive relationships, or high OSINT exposure. OSINT, or open-source intelligence, includes company websites, social platforms, conference videos, and public filings.

Map what a cyberattacker could learn about reporting lines, travel schedules, invoice formats, approval thresholds, and internal terminology. Test whether employees have a trusted way to challenge urgent requests without being punished for slowing a transaction.

Organizations should connect this work to their phishing simulation program because realistic exercises reveal whether written controls survive pressure. A policy on file does not prove BEC readiness. Readiness comes when the right person recognizes an unusual request, verifies it through an independent channel, reports it quickly, and limits the financial impact of a fraudulent request.

What Are the Objectives of a BEC Risk Assessment?

A primary objective is to establish an evidence-backed risk register. Each entry should describe a plausible BEC scenario, the asset or process at risk, the exposed roles, and the existing control. It should also record the supporting evidence, business impact, responsible owner, and target remediation date.

"Finance is vulnerable to phishing" is too broad to guide action. "A vendor bank-account change can be approved from an email without an independent callback" identifies a specific failure that finance and procurement can correct.

Another objective is to create a control-maturity baseline. Evaluate whether each safeguard is absent, documented, consistently practiced, measured, or tested under realistic conditions. A company might have a dual-approval policy with no enforcement in its payment platform. It might also require callback verification without maintaining an authoritative supplier phone number.

Maturity scoring exposes the difference between controls that exist on paper and controls that change outcomes during a live attack. The assessment should produce five practical outputs:

• Risk register: Documented BEC scenarios ranked by likelihood, impact, exposure, and control weakness.
• Control-maturity baseline: A consistent view of how well identity, payment, email, training, reporting, and recovery controls operate.
• Prioritized remediation plan: Sequenced actions that address high-value transactions, high-risk roles, and failure points first.
• Residual-risk estimate: The remaining exposure after current and planned controls are considered, including assumptions and confidence levels.
• Executive scorecard: A concise view of financial exposure, control coverage, unresolved findings, remediation progress, and decisions requiring leadership support.

These outputs turn assessment findings into management decisions. Security teams can use them to prioritize identity hardening and reporting workflows, while finance teams tighten payment verification and vendor-change procedures. The board can then see whether risk is falling because behavior and process controls are improving. A training completion rate that reaches its target cannot show whether risk is actually falling.

What Is the Difference Between Inherent and Residual BEC Risk?

Inherent risk is the exposure that exists before controls are applied. A company with frequent international wires, decentralized procurement, public executives, large vendor networks, and fast acquisition activity carries more inherent BEC risk. A business with fewer payment paths and limited external visibility carries less.

Inherent risk describes the attractiveness and accessibility of the target. It does not indicate that the organization has failed.

Residual risk is the exposure that remains after current controls and planned safeguards are considered. Strong multifactor authentication can reduce account takeover risk. However, it cannot stop a cyberattacker from persuading an authenticated employee to approve a fraudulent invoice.

A dual-approval rule can reduce unilateral payment risk, but it fails if both approvers rely on the same compromised email thread. Residual-risk estimates must account for control independence, employee behavior, exceptions, monitoring, and recovery speed.

The distinction prevents two common errors. Treating inherent risk as the final risk score causes leaders to overstate danger without identifying a practical response. Treating the presence of controls as proof of low residual risk leads leaders to mistake written policy for a control that actually works during an attack. A useful assessment tests each control in context and records the evidence supporting the estimate.

Who Owns BEC Risk Assessment Findings?

BEC findings require shared ownership because no single team controls the entire attack path. Security owns threat modeling, identity signals, awareness exercises, reporting channels, and incident coordination. Finance owns payment approval, bank-account changes, treasury procedures, and transaction exceptions.

Procurement owns vendor onboarding and supplier communications. Legal, HR, executive operations, IT, internal audit, and business-unit leaders each own different trust relationships and recovery decisions.

Assign one accountable owner to every finding, even when several teams must act. The owner should have authority, budget access, and a measurable completion date. A finding without ownership becomes a recurring observation in the next assessment.

Assigning a finding to security alone misplaces accountability, because the most consequential controls usually sit in finance, procurement, and executive operations. The most consequential controls often sit outside the security department.

Leadership must review exceptions and residual risk directly and avoid delegating them indefinitely. If the business chooses to preserve a fast payment process that bypasses independent verification, executives should understand the exposure. They should also approve the exception and set compensating controls. That decision belongs in the scorecard so risk acceptance remains visible and reviewable.

A BEC risk assessment becomes valuable when it connects human judgment, business process design, and technical controls into one operating picture. That picture gives security and finance teams the evidence required to trace how cyberattackers turn isolated weaknesses into a coordinated campaign.

How Does a Business Email Compromise Risk Assessment Track Five Campaign Stages?

A business email compromise risk assessment must trace an attack from reconnaissance to monetization. A payment request is only the visible endpoint of a longer trust-building campaign. Missing an earlier signal can lead to unauthorized payment, payroll diversion, or data disclosure.

The FBI Internet Crime Complaint Center (IC3), 2024 recorded more than $55 billion in exposed BEC losses from October 2013 through December 2023. Assessments must therefore test employee decisions across email, voice, SMS, and collaboration channels. Measuring email clicks alone leaves the other channels untested.

What Are the Five Stages of a BEC Campaign?

BEC attacks typically progress through five connected stages. Each stage creates a testable control point for a business email compromise risk assessment.

1. 1Target and intelligence gathering: Cyberattackers collect open-source intelligence (OSINT) from company websites, LinkedIn profiles, social media, job postings, public filings, and breached credentials. They identify payment approvers, payroll managers, trusted vendors, and executive travel patterns. The assessment should review publicly visible reporting lines, executive contact details, finance responsibilities, and employee voice or video samples. It should also check whether an outsider could identify a payment approver without accessing internal systems.
2. 2Trust establishment: The cyberattacker begins with a low-risk message that appears routine. An executive might ask whether an employee is available, a vendor might confirm an invoice reference, or an attorney might request a preferred communication channel. A controlled simulation should measure whether employees verify an unexpected identity change, report the message, and resist moving the conversation to a personal account or encrypted messaging app.
3. 3Impersonation or account compromise: The campaign uses executive impersonation, a compromised account, domain spoofing, or a lookalike domain. A lookalike domain uses a visually similar registration, while a Unicode homograph substitutes characters from another alphabet. Punycode can encode internationalized domains in a form that hides the substitution. The assessment should compare display-name recognition with full-address inspection and test whether employees use an independent directory or known phone number before acting.
4. 4Payment or data-request execution: The cyberattacker requests a bank-account change, wire transfer, payroll update, tax document, customer record, or credential. Common BEC types include invoice and bank-account change fraud, payroll diversion, vendor email compromise, attorney fraud, and real estate fraud. The assessment should require a documented callback and dual approval for payment, payroll, and sensitive-data changes, even when the request arrives inside an existing or hijacked thread.
5. 5Concealment or monetization: The cyberattacker routes funds through a mule account, cryptocurrency exchange, or third-party payment processor. Deleted messages, new forwarding rules, and continued impersonation of the victim then delay discovery. A tabletop exercise should measure detection time, mailbox review, bank escalation, evidence preservation, and law enforcement reporting.

How Do Cyberattackers Build Trust With Low-Risk Messages?

Low-risk messages work because they ask employees to perform harmless actions before introducing money or sensitive data. A fake executive may ask for a phone number, a vendor may send revised contact details, or an alleged attorney may request confirmation of a closing schedule. These exchanges establish responsiveness and reveal internal language, approval chains, and working hours.

The assessment should test the whole conversation along with the final payload. Use scenarios involving executive impersonation, vendor email compromise, attorney requests, and real estate transactions. Then measure whether employees confirm identity through a second channel.

The FBI's 2024 BEC guidance recommends secondary-channel verification for account-information changes. It also instructs employees to inspect full email addresses and watch for misspelled domains.

Conversation hijacking requires a separate test because the request can appear inside a legitimate thread. Security leaders should simulate a compromised vendor or employee account and insert a realistic change request. The exercise should measure whether the recipient checks bank details against an approved record.

Feedback should reinforce correct behavior and avoid blaming employees who miss a realistic scenario. The objective is to make verification automatic when context changes, urgency rises, or the requested action cannot be reversed.

How Does AI Change BEC Speed, Personalization, and Channel Selection?

AI makes credible BEC content faster to produce and easier to adapt. The FBI's 2024 guidance on generative AI fraud reports that criminals use AI-generated text to create believable spear phishing and financial-fraud messages at greater volume. The same guidance notes that AI helps criminals correct language errors and translate content for targets in other countries.

Traditional warning signs such as awkward grammar and inconsistent tone therefore offer little protection against AI-powered business email compromise.

Cyberattackers can combine OSINT with AI-generated phishing emails, voice cloning, deepfake video, smishing, and quishing. A finance employee might receive a polished email, a vishing call that repeats the request, and a QR code that opens a lookalike login page. This multi-channel follow-up creates artificial confirmation and increases verification fatigue.

The 2024 Arup wire-fraud case shows why visual familiarity cannot replace procedural verification. CNN reported the Arup incident in 2024, describing how an employee in Hong Kong transferred about $25 million after a video call with deepfake versions of senior colleagues.

In a separate case, NBC News reported in 2024 that an apparent deepfake caller posed as Ukraine's former foreign minister Dmytro Kuleba during a call with U.S. Sen. Ben Cardin. Both incidents show how cyberattackers exploit financial, executive, and geopolitical authority in real-time communication.

An effective assessment must reproduce that pressure safely. Test AI-generated email for personalization, voice cloning for authority, quishing for mobile behavior, and multi-channel follow-up for verification fatigue. Include executive impersonation, payroll diversion, vendor changes, and real estate payment instructions across separate channels. Then compare reporting rates, verification time, and escalation accuracy by role.

A modern Phishing Simulations program can support this methodology when simulations cover email, voice, and SMS in addition to suspicious-link exercises. The decisive metric is whether employees pause, verify identity and payment details independently, and report the signal. They must also trigger recovery procedures before the cyberattacker reaches monetization.

Which Business Processes Should a BEC Risk Assessment Map First?

A BEC risk assessment should first map the processes that move money, release sensitive data, or alter trusted relationships. Start with payment-heavy and executive-facing workflows. Then trace each request through initiation, verification, approval, execution, reconciliation, exception handling, and recovery.

Before ranking exposure, include subsidiaries, contractors, remote workers, shared mailboxes, third-party platforms, and vendor ecosystems.

1. Map Payment and Data Flows Before Reviewing Email Controls

Begin with accounts payable, treasury, procurement, payroll, executive support, mergers and acquisitions, and real estate transactions. Add customer refunds, donations, vendor onboarding, banking changes, and emergency payments. These workflows give cyberattackers credible business pretexts and a measurable path to loss.

The 2025 FBI IC3 Annual Report describes BEC as a scam targeting businesses or individuals that work with suppliers or regularly perform wire transfers. Payment workflows are therefore the right starting point for a BEC exposure review.

For each process, draw the movement of money, data, and authority. Record where an invoice enters the organization, which system stores vendor details, and who can change bank information. Also record which platform releases payment and where reconciliation occurs.

Repeat the exercise for payroll files, acquisition documents, customer account data, tax records, credentials, and confidential deal information. A fraudulent request can cause damage without triggering a wire transfer. Redirected payroll, exposed merger data, manipulated refunds, or altered vendor records can all create financial, operational, data, and reputational losses.

Use one standard flow for every process: request initiation, identity and instruction verification, approval, execution, reconciliation, exception handling, and recovery. Document the evidence available at each point. Relevant evidence includes the original email, purchase order, contract, callback record, approval ticket, payment confirmation, system log, and recovery request.

Link related workflows to the organization's phishing simulation program so employees rehearse the requests they are expected to verify.

2. Identify Approval Paths and Single Points of Failure

Convert each process map into an approval matrix. Name the requestor, reviewer, approver, executor, reconciler, and recovery owner for every transaction type. Add payment thresholds, required documentation, separation-of-duties rules, callback requirements, trusted contact directories, vendor records, and approved communication channels.

The objective is to expose where one compromised mailbox, absent employee, or urgent executive request can move a transaction without independent scrutiny.

Mark single points of failure clearly. Common examples include one treasury employee who can update bank details and release payments, or one executive assistant who handles leadership requests. Others include a shared mailbox with broad payment authority and a single employee who knows the callback process but is unavailable during a crisis.

Also mark control bypasses created by verbal approvals, after-hours payments, temporary vendor records, manual spreadsheets, and "process now, document later" instructions.

For each high-risk path, establish a verification rule that is independent of the requesting channel. A banking change should use a known phone number from the vendor record and ignore any number in the email. An emergency payment should require a second approver and a documented reason for the exception.

An executive request should be confirmed through a pre-agreed channel. These controls preserve employee judgment while removing the pressure to decide whether a familiar message is genuine.

3. Extend the Assessment Across the Real Operating Environment

A headquarters-only map creates false confidence. Repeat the review across subsidiaries, acquired entities, contractors, remote workers, shared mailboxes, third-party payment platforms, and managed service providers. Include banks, payroll processors, law firms, real estate brokers, suppliers, and other vendor ecosystems. Each party introduces different identity records, approval conventions, time zones, escalation contacts, and recovery capabilities.

Document who is authorized to initiate or approve requests for each entity and how that authority is verified. Include personal email use, mobile approvals, collaboration tools, external accounting systems, and expense platforms. Also include vendor portals where employees can change payment instructions or upload sensitive files.

Shared mailboxes require special attention because they blur ownership. They also make it difficult to prove who saw, approved, or altered a request.

Require documented evidence and avoid relying on verbal assurances. Collect current process maps, approval matrices, vendor master records, trusted contact directories, payment thresholds, delegated-authority documents, third-party contracts, platform access lists, and records of recent exceptions.

Review recent changes to banking details, urgent payments, refunds, payroll adjustments, and new vendor entries. Compare the documented process with what actually happened. The gap between those two versions represents the exposure.

Rank each process according to transaction value, data sensitivity, speed of execution, reversibility, external dependency, and control concentration. Assign an owner, verification standard, recovery deadline, and testing schedule to every high-priority path. This evidence-based map gives the rest of the assessment a precise foundation.

Which People and Roles Are Most Exposed to BEC?

A business email compromise risk assessment should compare people by the decisions they can make, the information cyberattackers can observe, and the pressure placed on them to act quickly. Finance and treasury staff face the highest direct transaction exposure. They can release funds, change banking details, or approve payment exceptions.

Accounts payable and procurement teams face frequent vendor requests. Executive assistants and executives attract impersonation because their authority can accelerate approval.

Legal, HR, sales operations, IT administrators, and vendor contacts hold different combinations of sensitive data, system access, trust, and urgency. No role is inherently careless. Exposure reflects the attack paths surrounding a role and the quality of the verification process supporting it.

How Should Organizations Score Role-Based BEC Exposure?

Role-based scoring turns a broad human-risk question into a repeatable assessment and can feed a broader human risk scoring program. Score each role across five dimensions: transaction authority, system and data access, public visibility, likelihood of receiving urgent requests, and ability to override ordinary procedures.

A treasury manager with payment authority and frequent executive contact ranks differently from an accounts payable specialist. The specialist can create vendors but cannot release funds.

Both roles require targeted practice, but the scenarios and controls should match their actual decisions. Finance and treasury staff usually combine high transaction authority with intense time pressure. Accounts payable employees process invoices and bank-change requests at volume, which makes vendor impersonation particularly dangerous.

Procurement teams can introduce or modify supplier relationships, while payroll staff can expose employee tax or banking information. Executive assistants often manage calendars, travel, invoices, and confidential communications, giving cyberattackers a route to senior decision-makers. Executives remain valuable impersonation targets even when they do not execute transactions directly.

Legal teams receive confidential deal, litigation, and contract information and often work with external counsel under deadline pressure. HR handles identity, compensation, benefits, and employment records, while sales operations manages customer data, commissions, contracts, and revenue processes. IT administrators can reset accounts, alter access, or approve privileged changes.

Vendor contacts sit outside the organization's direct control but can influence payment instructions and provide trusted communication channels. Their risk requires controls that verify requests independently of the vendor's usual email thread or contact details.

The assessment should record both inherent exposure and observed behavior. Inherent exposure describes what a role can do before training or controls. Observed behavior captures whether employees report suspicious messages, verify unusual requests, and escalate without bypassing policy.

A 2025 World Economic Forum account of the Arup deepfake fraud reinforces the lesson from that case. Transaction authority requires independent verification, even when a familiar face and voice appear on screen.

Assign low, moderate, high, or critical exposure to each dimension, then prioritize roles with multiple high scores. Use the results to set simulation frequency, approval controls, escalation paths, and manager coaching. Keep the score focused on attack opportunity and decision context, and avoid labeling any employee as risky.

How Do OSINT and Executive Impersonation Increase BEC Risk?

Open-source intelligence (OSINT) increases BEC precision. It shows cyberattackers who approves payments, who reports to whom, which vendors are active, and when leaders travel or announce major deals. Public biographies, conference videos, social media posts, press releases, job listings, and organizational charts can make a fraudulent request sound routine.

Executive assistants, finance leaders, legal counsel, and sales executives become especially exposed when their names, reporting relationships, and communication habits are easy to map. An OSINT risk assessment can show how much of that context is publicly available.

Executive impersonation works because authority compresses deliberation. A message that appears to come from a chief executive can turn an unusual transfer into a perceived loyalty test. A fake CFO voice or deepfake video can make verification feel unnecessary.

Criminals also combine channels. An email establishes the request, a vishing call creates urgency, and a smishing message confirms a supposedly private instruction.

An impersonation risk assessment should review both employee exposure and executive exposure. Identify public recordings that could support voice cloning, posts that disclose travel or deal activity, and signatures that reveal titles or approval responsibilities.

Reduce unnecessary detail in public staff directories and remove personal contact information from documents. Establish a central process for approving executive impersonation simulations. Data minimization limits the intelligence a cyberattacker can assemble without hiding the organization. It also gives employees fewer details to reconcile when an unusual request arrives.

The Cardin incident described earlier illustrates the same trust mechanism beyond corporate finance. A convincing identity signal can create credibility before the recipient verifies the channel.

Deepfake awareness training should therefore teach verification behavior and leave forensic media analysis to specialists. A known, independent contact method remains more reliable than a familiar face, voice, caller ID, or email signature. Leadership teams can extend this work with deepfake awareness training for executives.

How Should Organizations Evaluate Employee Decisions Under Urgency or Authority Pressure?

Awareness evaluation should measure decisions made at the moment of pressure. Memory of a training module is a weaker signal. Targeted phishing awareness training should test finance with payment diversion requests, procurement with supplier-account changes, HR with payroll updates, and IT administrators with urgent privilege-reset requests.

Vishing and smishing simulations should test whether a recipient challenges a familiar voice or follows up unsafely on a text message. Deepfake awareness training should rehearse video-based executive impersonation.

The strongest measurement framework observes four behaviors:

• Reporting behavior: Does the employee use the approved reporting channel, preserve the message, and notify the right team quickly?
• Verification behavior: Does the employee contact the requester through a known, independent channel and avoid replying to the suspicious message?
• Escalation behavior: Does the employee pause the transaction and involve a manager, security team, or second approver?
• Recovery behavior: After recognizing a mistake, does the employee report it immediately so access, payments, or messages can be contained?

Simulation results should guide coaching and avoid punishment. A missed test identifies a decision point that needs clearer authority, better procedure, or more realistic practice. Managers should ask what made the request credible, which policy was difficult to apply, and which safeguard would make the safe action faster next time.

Security teams should also test whether policies work during quarter-end close, payroll deadlines, executive travel, and vendor onboarding, when the urgency is real. A policy that works only in a quiet office will fail when an employee faces a real deadline and an apparently trusted requester.

A safe escalation process must be explicit. Employees should know that delaying an unusual payment is acceptable and that executives cannot bypass verification rules. They should also know that quickly reporting a suspected mistake counts as a successful security action.

Organizations can reinforce this process with role-specific simulations and continuous human risk monitoring. That monitoring connects exposure signals to targeted training without turning employees into permanent risk labels.

The assessment should end with controls, because rankings alone change nothing. Require dual approval for high-value or new-beneficiary payments, verify bank changes through a trusted channel, and restrict public exposure of sensitive organizational details. Give every employee a fast route to security support.

When authority pressure meets a practiced verification habit, employees become the control that interrupts BEC before the request becomes an irreversible transaction.

Which Technical Controls and Evidence Should a BEC Risk Assessment Review?

A business email compromise risk assessment reviews email authentication, identity and mailbox telemetry, endpoint and SaaS activity, data access, payment workflows, and forensic preservation. Treat every signal as part of a timeline. A clean authentication result does not rule out a compromised legitimate account or an employee manipulated through a trusted channel.

1. Review Email Authentication and Analyze Sender Domains

Start with the message itself, then validate the sender's infrastructure, since the visible From address cannot be trusted on its own. Preserve and examine SPF, DKIM, and DMARC results, including the authenticated domain, alignment status, policy applied, receiving server disposition, and any failure reason.

SPF verifies whether the sending IP address is authorized to send mail for a domain. It can expose direct spoofing from an unauthorized server. However, it cannot prove that a legitimate employee wrote the message or that an authorized account remained uncompromised.

DKIM verifies that a cryptographic signature matches the signing domain and that signed content was not altered in transit. It does not establish that the sender is trustworthy, because a cyberattacker using a hijacked mailbox can send a validly signed message.

DMARC evaluates alignment between the visible From domain and SPF or DKIM authentication, applies the domain owner's policy, and produces reporting data. It reduces direct domain spoofing risk. It cannot stop lookalike domains, compromised vendors, or a genuine mailbox used for fraud.

CISA's 2023 phishing guidance recommends these controls as part of email defense. They support investigation and cannot substitute for it.

Analyze the sender and reply-to domains separately. Compare the display name, envelope sender, return-path, reply-to address, and URLs against the organization's known domains and trusted suppliers. Search for lookalike domains that use character substitutions, inserted words, altered top-level domains, and changes such as company.co versus company.com.

Inspect DNS records, including A, AAAA, NS, TXT, MX, and CNAME records. Determine where the domain resolves, which provider handles mail, whether it uses disposable infrastructure, and whether its records changed near the campaign date. Record domain age, registrar, registration dates, nameservers, privacy-proxy status, and WHOIS information where available.

Domain age serves as an investigative clue. An old domain can be compromised, and a new domain can belong to a legitimate project, so age alone cannot prove fraud.

Inspect Unicode and Punycode representations for homograph attacks, where visually similar characters imitate a trusted domain. Capture the normalized ASCII form, rendered form, certificate details, redirect chain, and hosting provider before the infrastructure changes.

2. Correlate Identity and Mailbox Telemetry

Identity evidence determines whether the request came from a legitimate account, a stolen session, or an unauthorized application. Pull sign-in and audit records from the organization's identity provider, email platform, security information and event management (SIEM) system, and conditional-access or multifactor authentication controls.

Include successful and failed sign-ins, source IP addresses, geolocation, autonomous system, user agent, and device identifier. Add operating system, browser, authentication method, MFA result, risk score, and session creation time.

Flag impossible travel only as a prioritization signal. A rapid change between distant locations can indicate stolen credentials, a proxy, a mobile carrier transition, or inaccurate geolocation.

Stronger evidence appears when impossible travel coincides with an unfamiliar device, concurrent sessions, a new country, or a new internet service provider. Failed MFA prompts, token replay indicators, and unusual mailbox actions strengthen the case further.

Review legacy authentication, because protocols that lack support for modern authentication controls can expose accounts to password-based attacks. Verify whether legacy protocols were enabled, used, or blocked during the relevant period.

Examine OAuth grants and enterprise application consent. Identify newly authorized applications, consented scopes, granting user, publisher, client ID, redirect URI, token issuance time, refresh-token activity, and access to mail, files, contacts, or offline data.

A suspicious grant can persist after a password reset. Preserve the grant record, then revoke unauthorized grants and invalidate active sessions and refresh tokens as containment actions.

Mailbox telemetry should cover message reads, sends, deletes, moves, searches, downloads, exports, delegate changes, shared-mailbox access, and administrative actions. Look for new forwarding addresses, transport rules, inbox rules that hide replies, rules that move invoices into obscure folders, and changes to focused or junk-mail settings.

Review sent items and deleted items for messages removed after transmission. Examine mailbox exports and bulk downloads, because BEC operators often collect conversation history during an email account takeover before impersonating a finance or executive contact. Compare each event with the user's normal role and working pattern.

Consider a finance employee who creates an external forwarding rule, accesses a shared executive mailbox, and sends a payment request from an unfamiliar device. Together, those events present a stronger compromise case than any one of them alone. Use the evidence to trigger phishing response and mailbox remediation workflows while preserving the original records for investigation.

3. Trace Lateral Exposure Across Endpoints, SaaS, and Data Stores

BEC investigations must follow the cyberattacker beyond email. Review endpoint detection and response telemetry for browser sessions, credential theft indicators, malicious files, remote-access tools, PowerShell or shell activity, token stores, password-manager access, newly installed extensions, and connections to domains found in the message.

Capture the affected hostname, logged-in user, process tree, file hashes, command lines, network destinations, and system time zone. Extend the review to identity-provider audit logs, email-platform audit logs, SIEM events, SaaS activity, OneDrive and SharePoint access, shared-mailbox records, file-server logs, and payment-platform audit trails.

For cloud storage, examine file views, downloads, sync activity, sharing-link creation, permission changes, external invitations, bulk access, and access from unmanaged devices. For shared mailboxes, identify who opened, searched, forwarded, deleted, or exported messages.

For file servers, correlate logon sessions with access to vendor records, invoices, banking instructions, customer data, and executive correspondence.

Payment-platform evidence should show who created, edited, approved, released, or canceled a payment. It should also show which device and IP address performed each action, which beneficiary or bank details changed, and whether anyone bypassed dual approval. Compare payment events with the email timeline and out-of-band verification records.

Three events together make a fraudulent instruction obvious. A mailbox rule concealed the reply, an unfamiliar session edited bank details, and a payment platform recorded approval minutes later. That correlation connects individual alerts to the business outcome investigators must establish.

4. Preserve Evidence Before Containment Changes It

Preservation must begin before investigators reset passwords, revoke tokens, delete rules, rebuild endpoints, or purge messages. NIST's 2025 incident response guidance places incident analysis and evidence handling inside a structured response process. That structure supports consistent collection and defensible timelines.

Create a case record with the incident identifier, collection time, collector, system source, time zone, hash values, and chain of custody. Preserve the original message in its native format, along with full headers, attachments, embedded files, URLs, authentication results, timestamps, and message IDs. Screenshots and copied text should never serve as the primary record.

Capture malware samples safely, including file hashes and detonation metadata. Preserve suspicious tokens, session identifiers, OAuth details, affected devices, mailbox rules, forwarding destinations, and relevant configuration changes. Where possible, export records in read-only form from identity-provider, email-platform, SIEM, SaaS, OneDrive, SharePoint, shared-mailbox, file-server, endpoint, and payment-platform sources.

Synchronize timestamps against a trusted reference. Document retention gaps, missing telemetry, clock drift, and sources that were disabled or overwritten.

The final assessment should distinguish confirmed compromise, probable compromise, attempted fraud, and inconclusive activity. That distinction prevents both underreaction and unnecessary blame. It also gives security, legal, finance, and leadership a precise basis for coordinated BEC response.

How Should Organizations Handle BEC Payment Verification and Governance?

A BEC risk assessment should confirm that payment verification makes fraudulent requests difficult to complete, even after an inbox or executive identity is compromised. Build controls around independent verification, separated approvals, trusted vendor records, transaction thresholds, and documented evidence. These controls sit at the center of efforts to prevent business email compromise.

Review every exception, especially after a bank flags a suspicious transfer. Urgency must never create an unlogged bypass around financial controls.

1. Require an Independently Initiated Callback

Independent callback verification is the primary control for payment requests, bank-account changes, payroll updates, urgent refunds, and sensitive data releases. The employee receiving the request must not call a number in the email, reply to the message, or use a number on an attached invoice. An inbound call also fails as proof of identity.

A cyberattacker controlling the mailbox can control the conversation and provide a convincing number. The callback must therefore begin from a trusted directory maintained outside the email thread.

Use the vendor master record, an approved contract, the company directory, the bank's official website, or a previously validated contact record. Confirm the request with a known individual through a separate channel, then ask questions about details the suspicious message does not contain.

For a bank change, confirm the legal entity, account ownership, routing details, effective date, and reason for the change. For an executive request, confirm the business purpose, amount, recipient, and required approvers.

Record who initiated the callback, which trusted source supplied the number, who answered, and when verification occurred. Also record which facts were confirmed and whether the request changed during the conversation. Attach this evidence to the payment record so it does not sit solely in an employee's inbox.

U.S. Secret Service BEC prevention guidance directs organizations to call known contacts before sending money and to use out-of-band communication after a compromise.

Trusted contact maintenance is a governance control in its own right. Assign an owner for each high-value vendor and periodically confirm contact details through an established relationship. Remove departed employees, expired representatives, and duplicate records. An unmaintained directory gives cyberattackers a trusted identity to impersonate.

2. Separate Request, Approval, and Release Duties

Dual approval prevents one compromised identity from requesting and releasing the same payment. The person who receives or enters a request should not approve it alone. The person who approves the payment should not be the only person able to release funds.

Finance systems should enforce these roles directly, because employees under pressure may forget a written policy. Separate three activities:

• Request: The requester establishes the business need and submits supporting documents.
• Approval: The approver validates the purpose, amount, recipient, and verification evidence.
• Release: The release operator executes the transaction after confirming that required approvals are present.

When complete separation is impractical, assign an independent director, controller, owner, or external fiduciary to perform the second review.

Approval thresholds should reflect business risk, which a single arbitrary dollar amount rarely captures. Low-value recurring payments to stable vendors can follow streamlined review when controls are mature and recovery is straightforward.

New beneficiaries, international transfers, payroll changes, executive requests, and payments involving irreversible settlement require stronger review even when the amount is modest. High-value or strategically critical transactions should require senior approval, independent callback verification, and documented evidence before release.

Combine transaction value with business criticality, recoverability, beneficiary novelty, and control maturity. A $20,000 payment to a new overseas account can deserve more scrutiny than a $100,000 recurring payment to a long-established domestic supplier. That holds when the first transaction is difficult to recover and mature reconciliation controls cover the second.

As payment value and irreversibility rise, reduce individual discretion and increase approval depth.

Set transaction limits at the employee and account levels. Configure bank alerts for new beneficiaries, unusual geographies, transfers outside normal hours, rapid changes in payment volume, and attempts that exceed established thresholds.

For high-risk accounts, reconcile released payments against approved invoices and purchase orders daily. Lower-risk activity can follow a defined recurring schedule. Record who reviewed each transaction and how discrepancies were resolved.

Emergency-payment exceptions require more control. Permit them only for defined scenarios, with a named executive owner, maximum amount, second approver, and mandatory callback verification. Require written justification before release. When an operational crisis makes advance documentation impossible, require it within a tightly defined period.

Expire each exception after one use and trigger a retrospective review. If employees can repeatedly label payments urgent, the exception has become the normal process.

3. Control Vendor and Third-Party Changes

Treat every new beneficiary, bank-account update, invoice-routing change, and payment-term modification as a high-risk event. An email alone should never create or edit payment instructions. Require the requester to submit the change through an authenticated procurement or vendor-management workflow. That submission needs supporting documentation and an independent callback to a trusted contact.

Apply a cooling-off period before the first payment to a new or changed account. During that period, keep the vendor record visibly pending and block payment release unless an authorized exception is approved.

The period can vary by risk. A routine domestic update with verified documentation may receive a shorter hold. An international account change, executive-directed payment, or change made during an active incident should receive a longer review.

Use an out-of-band channel that the suspected compromise does not control. An outbound call to a number from a trusted directory is stronger than an inbound call. When the amount or business impact is high, a face-to-face confirmation, verified video meeting, or separately authenticated vendor portal can provide additional assurance.

Caller ID, a familiar voice, an email signature, and a video appearance all fall short as independent proof, because cyberattackers can spoof or synthesize each signal.

Maintain an approved vendor record with the legal name, tax information, contract owner, validated contacts, approved payment accounts, normal payment cadence, and escalation route. Limit who can create or edit those records, require dual authorization for changes, and log every modification.

Review dormant vendors and disable unused payment instructions. A clean vendor master reduces the trusted paths a cyberattacker can manipulate.

4. Test the Controls When a Bank Flags a Transfer

A bank alert serves as a control test. On its own, it proves neither that a transaction is fraudulent nor that it is safe. When a bank flags a suspicious transfer, pause release or request an immediate hold, and preserve the message and transaction details.

Notify designated finance, security, and legal contacts through trusted channels. Keep response coordination out of any potentially compromised mailbox.

The response team should independently contact the requester, beneficiary, and bank using records outside the suspicious communication. Compare the transaction with the approved request, callback evidence, vendor record, invoice, and approval history.

If the payment is unauthorized, ask the bank about recall procedures immediately. Secure affected accounts, reset credentials, and inspect mailbox rules and forwarding settings. Preserve evidence for law enforcement and recovery efforts.

Document whether the alert exposed a missing control, a failed control, or a control employees bypassed. Then test the workflow with a controlled exercise that sends a simulated urgent payment request. The exercise should require the callback, inspect approval separation, confirm that the cooling-off period blocks release, and verify that alerts reach the right people.

A BEC risk assessment is complete only when the policy works under pressure. A written document alone does not meet that standard.

Organizations that need to connect payment verification with employee behavior should include BEC, vendor impersonation, vishing, and executive-request scenarios in multi-channel phishing simulations. These exercises rehearse the pause, callback, escalation, and reporting behaviors that preserve financial control when a trusted identity appears to make an urgent request. Punishing a failed test undermines that purpose.

How Should an Organization Conduct a Formal BEC Risk Assessment?

A formal BEC risk assessment should define the organization's exposure, test whether controls work in practice, and convert evidence into prioritized remediation. Establish the assessment charter and scope, collect records, and interview control owners. Then walk through payment and access processes, validate findings, and assign accountable owners with due dates.

Treat the assessment as a decision process. A policy review alone falls short, because documented controls provide no protection when employees, systems, banks, or vendors ignore them under pressure. The work can run alongside a broader email security risk assessment while extending further into payment and approval processes.

1. Establish the Charter and Assessment Scope

Begin with an assessment charter that names the sponsor, assessment lead, participating functions, decision rights, timeline, and reporting audience. Define business email compromise as the assessed risk. That definition should include fraudulent payment requests, payroll diversion, credential theft, vendor impersonation, executive impersonation, data theft, and unauthorized changes to banking details.

Scope the assessment around how money, authority, and sensitive information move through the organization. Identify the business units, legal entities, payment centers, shared-service teams, subsidiaries, systems, jurisdictions, currencies, and third parties involved in those processes.

Include treasury, accounts payable, procurement, sales operations, payroll, HR, finance leadership, executive assistants, IT, security, legal, internal audit, and regional teams that approve or release funds.

Record constraints before evidence collection begins. Legal and privacy teams should define rules for reviewing employee mailboxes, call recordings, payment records, personal data, cross-border transfers, and monitoring outputs.

Confirm cyber insurance requirements, notification obligations, and regulatory expectations. Also confirm contractual controls imposed by customers or banks and retention periods for relevant records. A regulated financial institution, health care organization, government contractor, and multinational enterprise will each have different evidence boundaries and reporting requirements.

Use the NIST Cybersecurity Framework 2.0, published in 2024, to connect governance, identification, protection, detection, response, and recovery activities to BEC risk. The framework does not replace legal advice or sector requirements. It does give the assessment a repeatable vocabulary for documenting gaps and assigning risk decisions.

2. Collect Evidence Across the Full Payment and Communication Chain

Evidence collection should test the complete attack path, of which email filtering is only one part. Request records showing how a suspicious request enters the organization, how an employee validates it, and who approves it. The records should also show which system releases it and how the organization detects and recovers from fraud.

Collect procedures for invoice approval, vendor onboarding, bank-detail changes, payment release, payroll changes, executive requests, password resets, mailbox access, and incident escalation. Gather incident history, near-miss reports, fraud investigations, reported phishing messages, help desk tickets, bank alerts, insurance claims, and prior audit findings.

Near misses deserve the same attention as confirmed losses. They reveal where employees recognized danger or where a control interrupted the attack.

Request representative payment samples from different business units, payment types, currencies, and approval thresholds. Sample vendor setup records, invoice changes, urgent payment exceptions, wire transfers, automated clearing house transactions, payroll amendments, and manual overrides.

The sample does not need to cover every transaction. Its purpose is to determine whether the organization consistently performs independent verification when a cyberattacker creates urgency or impersonates authority.

Collect access reviews and identity records for finance, treasury, procurement, HR, executive support, banking portals, enterprise email, invoice systems, payroll platforms, and vendor-management tools. Include privileged-access lists, joiner-mover-leaver records, multifactor authentication coverage, delegated mailbox permissions, shared-account inventories, service accounts, and recent termination reviews.

A policy requiring least privilege is not evidence that access is actually limited, so each of these records needs direct review.

Gather configuration exports and operational records from relevant systems. These include email authentication settings, external forwarding rules, mailbox audit logs, identity-provider policies, bank portal controls, payment approval workflows, vendor master changes, alert configurations, and retention settings.

Request training records, phishing simulation results, reporting rates, role-based modules, and remediation history. Review vendor inventories and contracts for payment processors, payroll providers, managed service providers, banks, accounting firms, and critical suppliers.

Complete the evidence package with recovery procedures. Confirm how the organization recalls or freezes payments, contacts banks, disables compromised accounts, resets credentials, and preserves evidence. Also confirm how it notifies insurers, communicates with affected vendors, and restores trusted operations. Recovery capability determines whether a suspicious request becomes a contained event or an unrecoverable loss.

3. Interview Control Owners and Walk Through Real Procedures

Interviews should test how work actually happens when a request arrives, since a policy description of the process is a weaker source. Ask each participant to explain a recent transaction or near miss from receipt through approval, using system records and artifacts to verify the account.

Treasury should explain payment release controls, bank callbacks, dual authorization, cutoff pressures, fraud alerts, and the escalation path for unusual transactions. Accounts payable should demonstrate invoice intake, exception handling, supplier verification, duplicate detection, and the process for changing bank details.

Procurement should walk through vendor onboarding, contract contacts, purchase-order controls, and independent confirmation of supplier requests.

Interview HR about payroll-change requests, employee identity verification, separation procedures, executive impersonation risk, and handling of sensitive personnel data. Legal should explain privacy restrictions, privilege, regulatory reporting, contractual obligations, and evidence-preservation requirements. Internal audit should describe prior findings, control testing, unresolved exceptions, and accepted-risk decisions.

IT and security teams should demonstrate identity controls, mailbox monitoring, forwarding-rule detection, logging, alert triage, incident escalation, and access removal. Executive leadership should clarify risk tolerance, approval authority, emergency-payment expectations, and the level of fraud exposure the organization is willing to accept.

Banks and insurers should be interviewed about callback protocols, transaction holds, notification windows, policy conditions, exclusions, and required documentation. Critical vendors should confirm their verification controls, authorized contacts, incident-notification terms, and process for validating account changes.

Use scenario walkthroughs to expose practical failure points. Present a legitimate-looking request from a known executive, a supplier asking to change bank details, a payroll diversion request, and a message from a compromised vendor mailbox.

Ask the participant to identify the required action, evidence, independent verification channel, escalation owner, and recovery step. Record whether the control operates without relying on an individual's memory or personal judgment.

4. Test Whether Controls Operate Effectively

The central question in a BEC risk assessment is whether a control operates effectively under realistic conditions. A current policy, completed training record, or configured security feature proves design intent. It does not prove that employees follow the process, that alerts reach the right team, or that reviewers detect exceptions before money leaves the organization.

Test controls through sample inspection, observation, replay of prior incidents, controlled exercises, and evidence-to-system reconciliation. For each control, document the expected behavior, population, sample selected, result, exception, responsible owner, and conclusion.

If the procedure requires a callback to a known phone number, inspect call records or confirmation artifacts. If it requires two approvers, verify distinct identities, timestamps, authorization limits, and the absence of shared credentials. If it requires vendor verification, compare the contact method used with trusted information already on file.

Evaluate human controls without blaming employees. An employee who reports a suspicious request demonstrates a functioning defense signal. A process that forces staff to bypass verification because of payment deadlines indicates a design failure that leadership must correct.

Compare training records with behavior data, including reporting speed, repeat failures, escalation quality, and performance across email, voice, SMS, and collaboration channels. Organizations building this evidence layer can connect phishing simulations to role-specific human-risk reporting and look past completion percentages alone.

5. Validate Findings and Build the Remediation Plan

Before issuing findings, conduct a validation session with each control owner and the assessment sponsor. Provide the observed condition, expected requirement, evidence reviewed, business impact, affected population, attack path, and proposed severity.

Give owners an opportunity to correct factual errors, identify compensating controls, or supply missing evidence. However, the existence of a policy alone should never justify downgrading a finding.

Prioritize findings by financial exposure, likelihood of cyberattacker success, speed of detection, recovery difficulty, regulatory impact, and concentration of authority. A single person who can approve and release a high-value payment represents a different risk from a failed awareness module with no transaction access.

Link each finding to a specific attack path. Examples include a compromised mailbox leading to an invoice change and payment release, or executive impersonation leading to an emergency wire transfer. The final report should contain:

• Executive summary: Top BEC exposures, business consequences, overall risk posture, and decisions required from leadership.
• Attack paths: Routes a cyberattacker could use across people, email, identity, payment, vendor, and recovery processes.
• Control matrix: Control objective, owner, evidence, test method, operating result, exceptions, and residual risk.
• Risk register: Finding, severity, affected unit, financial or regulatory impact, treatment decision, and status.
• Evidence index: Document name, system or owner, date range, sensitivity classification, and location.
• Remediation plan: Named owner, corrective action, dependency, milestone, due date, validation method, and escalation path.
• Accepted-risk decisions: Executive approver, rationale, expiration date, monitoring requirement, and trigger for reassessment.

Set a remediation review cadence before closing the assessment. High-risk gaps should receive immediate containment and a near-term validation date. Medium-risk findings need tracked milestones, while accepted risks require an accountable executive and a documented review date.

Reassess after a major acquisition, banking change, payment-system migration, material incident, regulatory change, or shift in executive and vendor workflows. A formal assessment creates value only when its evidence drives decisions that remain visible after the report is delivered.

What Should a BEC Risk Assessment Scorecard Include?

A business email compromise risk assessment scorecard should compare inherent exposure with residual risk. Reducing a complex fraud pathway to one unqualified number hides that difference. Inherent risk measures what could happen if safeguards failed. Residual risk measures the exposure left after prevention, detection, response, and recovery controls operate.

A useful scorecard gives finance, security, and executives the same view of which payment processes deserve attention. It separates evidence from assumptions and assigns an owner to every high-risk finding.

Which Risk Variables Belong in a BEC Scorecard?

Rate each payment process, vendor workflow, or executive-request pathway separately. A wire transfer involving a new vendor, urgent instructions, and limited callback verification presents different exposure from a recurring payment with independently confirmed banking details.

Score each variable on a five-point scale, and preserve the evidence behind every rating. A "4" for detection speed should represent a documented median detection time within a defined threshold. An assessor's confidence in the monitoring program is insufficient support. Record the data source, review date, owner, and confidence level beside each score.

Pair each rating with operational indicators that expose control gaps, such as the share of vendors with independently verified bank details, callback verification completion, and mailbox-rule review coverage.

High training completion does not establish lower BEC exposure. Compare completion with behavioral improvement, including reduced susceptibility to finance-focused spear phishing, faster reporting, and stronger callback verification. The FBI's 2025 IC3 Annual Report supplies external context for business email compromise, while internal process data estimates the organization's own exposure.

A scorecard should connect these signals to a documented human risk management process, with dashboards that show movement by role, department, and workflow. That structure turns isolated training and payment metrics into evidence leaders can act on.

How Should BEC Risk Scores and Bands Be Calculated?

Calculate inherent risk before crediting any safeguard. One practical model scores likelihood, potential loss, business criticality, and ease of exploitation from 1 to 5. It then weights those variables according to the process.

A treasury wire workflow should give potential loss and ease of exploitation greater weight than a low-value procurement process does. A simple weighted model is:

Inherent risk = weighted likelihood × weighted impact

Impact should combine potential loss and business criticality. Likelihood should combine attack opportunity and process weakness. Multiplying eight ordinal ratings together produces a precise-looking result without a defensible interpretation, so that shortcut should be avoided.

Use broad scoring bands tied to decisions:

• Low: Routine monitoring, standard training, and scheduled control review.
• Moderate: A named process owner, a remediation deadline, and quarterly evidence review.
• High: Executive visibility, targeted simulation, control testing, and remediation within a defined short-term window.
• Critical: Immediate payment-control review, temporary compensating measures, and formal executive acceptance if exposure remains.

Control-adjusted risk should reflect evidence-based control effectiveness. A control that exists only in policy deserves little credit. A control that is tested, measured, and consistently completed deserves more.

A callback procedure should not materially lower risk when completion goes unrecorded or employees use contact information supplied in the suspicious email. Residual risk is the exposure remaining after controls operate:

Residual risk = inherent risk × (1 − combined control effectiveness)

Treat this formula as a decision aid. It does not represent an actuarial truth. Estimate combined effectiveness conservatively, because overlapping safeguards do not provide independent protection.

Document dependencies as well. MFA, for example, reduces account takeover risk while doing little against a cyberattacker who impersonates a trusted executive through a legitimate account.

How Can Expected Annual Loss Show Control ROI?

Expected annual loss translates the scorecard into financial planning without presenting a forecast as certain:

Expected annual loss = annual likelihood × gross exposure × (1 − expected recovery rate)

Annual likelihood can draw on internal incidents, attempted fraud, suspicious requests, simulation results, and comparable process history. Gross exposure should reflect the amount realistically reachable through the workflow. The organization's entire cash position would overstate it.

Recovery assumptions should include fund-recall time, bank escalation, legal intervention, and the proportion of fraudulent funds historically recovered.

Present a range of outcomes. A low case can use a lower likelihood and a stronger recovery assumption. A central case can use the most defensible estimates. A severe case can model a high-value transaction and delayed detection. State the assumptions, data gaps, and confidence level beside each scenario.

Control ROI compares the expected reduction in annual loss with the full cost of implementation and operation:

Control ROI = (expected loss before control − expected loss after control − annual control cost) ÷ annual control cost

Use this calculation to compare investments. It should never serve as a promise of savings. A faster callback process can outperform an expensive awareness campaign for one payment workflow. Role-specific simulations can deliver greater value where finance employees repeatedly miss realistic requests. Recalculate after controls change and after behavior data shows whether exposure actually declined.

Which Metrics Belong in Executive and Board Reporting?

Executives need a compact view of exposure, movement, and decisions. Report the number and value of high-risk payment processes and the percentage of vendors with independently verified bank details. Add MFA coverage, legacy-authentication exposure, and median suspicious-login detection time.

Pair those measures with reported-request rate, callback verification completion, and simulation susceptibility by role and channel. Leaders can then see whether controls work under pressure.

Board reporting should also compare training completion with behavioral improvement. Completion proves participation. Declining susceptibility, faster reporting, and higher callback completion demonstrate changed behavior.

Add mailbox-rule review coverage, fund-recall time, recovery rate, open high-risk findings, and the age of accepted risks. An approved exception can become an unexamined weakness when its expiry date passes.

Use trend lines and thresholds in place of isolated percentages. Show whether high-risk findings are closing, detection is accelerating, and finance-team susceptibility is falling across email, vishing, and other channels. Flag uncertainty when a metric has a small sample, incomplete logging, or inconsistent process ownership.

A scorecard becomes operational when every red metric has an owner, a due date, and a decision attached. That discipline moves BEC assessment from an annual document to continuous control management, so leaders can see exposure rise or fall as controls and behavior change.

How Can a Tabletop Exercise Validate BEC Risk Assessment Findings?

A business email compromise risk assessment becomes more useful when a tabletop exercise tests decisions under pressure, because theoretical answers reveal far less. Build a timed scenario, release injects that require cross-functional action, and evaluate people, processes, technology, communications, and recovery.

The final checkpoint is an after-action plan with named owners, deadlines, control changes, targeted training, and a scheduled retest.

1. Design a Scenario and Release Timed Injects

Start with one realistic business trigger and define successful performance before inviting participants. A vendor bank-account change tests accounts payable verification and payment controls. An executive voice-cloning request tests out-of-band approval for urgent transfers. A compromised supplier mailbox tests trust in existing email threads.

Payroll diversion tests HR, finance, identity, and employee communications. A suspicious transfer detected after release tests whether the organization can contain damage while preserving evidence.

Write the exercise around one incident timeline, then introduce facts in stages. Begin with an apparently legitimate email containing a revised invoice or payment instruction. Add an inject showing an unfamiliar forwarding rule in the sender's mailbox.

Follow with a finance employee reporting a voice call from the "CFO," a cloud audit alert showing an unfamiliar sign-in, or a bank confirmation that funds already moved. Each inject should require a decision, since discussion alone does not test readiness.

CISA's Tabletop Exercise Packages provide customizable objectives, scenarios, discussion questions, participant materials, and after-action templates. Adapt those materials to the organization's payment workflows, cloud identity provider, insurance policy, regulatory duties, and supplier relationships.

A facilitator should withhold information participants would not have during a real incident. Evaluators should record response time, decision authority, missing contacts, and points where the process depends on one unavailable person.

Use Phishing Simulations to connect the tabletop to controlled behavioral testing across email, voice, and other channels. The exercise should avoid shaming an employee who follows a believable request. Its purpose is to reveal where verification procedures, escalation routes, or training need to become easier to use under pressure.

2. Coordinate Response and Preserve Evidence

The first operational test is whether participants establish incident command and stop additional transactions. The incident lead should assign owners for identity containment, mailbox investigation, finance coordination, legal review, communications, and documentation.

The team must determine whether the cyberattacker accessed one mailbox or used that account to reach cloud storage, shared mailboxes, calendars, vendor records, payroll data, or payment approvals. The organization's phishing incident response playbook should define who owns each of these steps.

Evidence preservation must be explicit. Participants should preserve the original email in its native form, including headers, authentication results, timestamps, attachments, URLs, and message identifiers.

They should capture sign-in logs, mailbox audit records, OAuth grants, inbox rules, forwarding settings, endpoint details, chat messages, call records, and bank instructions before containment actions delete or alter them. Screenshots alone cannot replace original artifacts and metadata.

Containment injects should test whether the team can disable compromised accounts, revoke active sessions and tokens, reset credentials, and require fresh multifactor authentication. They should also test the removal of malicious forwarding and deletion rules, the suspension of suspicious OAuth applications, and the review of delegated mailbox access.

Security staff should search shared mailboxes for related messages and determine whether the cyberattacker changed vendor master data or created lookalike domains. Finance should pause pending payments and validate any account change through a trusted contact method that is independent of the compromised thread.

The exercise must also measure financial response speed. Participants should identify the bank's fraud contact, request a hold or recall immediately, document the transaction reference, and determine whether the receiving institution can freeze funds.

The facilitator should record how long it takes to make the call and whether anyone has authority to act outside normal business hours. A plan that says "contact the bank" without a named person, number, approval path, and time target does not demonstrate operational readiness.

3. Test Recovery, Notification, and Lessons Learned

Recovery begins after containment, but it must be tested during the same exercise. Business pressure can cause teams to restore access too quickly. Before reactivating accounts, the organization should define how it confirms the removal of malicious rules, persistence mechanisms, unauthorized tokens, and altered payment data.

It should also review exposure in cloud storage, shared mailboxes, payroll systems, customer records, and supplier communications. Restored accounts then need monitoring for renewed suspicious activity.

The communications inject should force participants to decide when to notify legal counsel, cyber insurers, law enforcement, the affected vendor, customers, regulators, employees, and financial institutions. Legal counsel should assess contractual duties, privacy implications, reporting deadlines, and whether notifications could interfere with an investigation.

The insurer may require prompt notice, approved vendors, or specific evidence. Communications leaders should prepare clear messages that explain what happened, what recipients must verify, and which payment or credential requests require additional confirmation.

Close with an after-action review that separates strong performance from unresolved exposure. Every finding needs one accountable owner, a deadline, a control change, a targeted training action, and a retest date.

"Improve verification" is too vague to act on. A usable finding names the action, owner, and scope. For example, accounts payable will require a callback to a verified vendor number for all bank-account changes, and finance will document dual approval for urgent transfers. Identity teams will revoke unused application tokens, and security will retest the workflow within 90 days.

A BEC tabletop validates readiness only when its findings change daily behavior and technical controls. Repeat the scenario through a different channel, such as an executive deepfake or compromised supplier mailbox. Then compare decision time, evidence quality, bank notification speed, and recovery completeness with the first exercise.

That retest turns the business email compromise risk assessment from a compliance document into a measurable incident response capability.

How Should BEC Controls Differ by Organization and Compliance Context?

A business email compromise risk assessment should compare exposure by organization size, operating model, payment authority, and compliance context. BEC controls apply to every organization. The key difference lies in where each organization concentrates decision rights and verification effort.

A small business typically prioritizes owner impersonation, invoice fraud, and banking-change requests, because a few people control payments. A large enterprise must map subsidiaries, acquisitions, contractors, shared services, and regional finance teams across many systems and jurisdictions.

Every organization, regardless of size, needs independent payment verification, a clear reporting route, and a fast response path, though where those controls concentrate differs by structure. The assessment cadence and evidence standard should match transaction volume, regulatory duties, and third-party exposure.

How Should BEC Controls Differ by Organization Size and Structure?

Scale increases the number of approval paths a cyberattacker can exploit, while decentralization makes those paths harder to document. Small businesses, nonprofits, and schools should begin with a practical control map. It should identify who can approve payments, change vendor banking details, issue refunds, access payroll, and contact the bank.

Require out-of-band verification through a known phone number or established internal directory, and never use contact details supplied in the request. Nonprofits should include grant disbursements and donor communications. Schools should add tuition refunds, payroll, and procurement impersonation to the assessment.

Large enterprises, government agencies, financial services organizations, and health care providers need a more granular review. Assess each business unit, legal entity, payment platform, treasury function, and executive support team.

Financial services teams should prioritize wire transfers, account takeover indicators, and privileged relationship managers. Health care organizations should include claims payments, patient data requests, and medical supplier changes. Government agencies should assess grant payments, procurement officers, and contractors operating under public-sector authority.

The assessment should also identify where employees work and how they receive requests. Remote workers, international teams, and outsourced finance staff need escalation routes that function across time zones.

The NIST Cybersecurity Framework 2.0 Quick-Start Guide, published in 2026, connects cybersecurity risk management with enterprise risk management and workforce decisions. It provides a structure for assigning BEC ownership across departments.

How Do Subsidiaries, Acquisitions, and Third Parties Change BEC Exposure?

Decentralized organizations should treat every subsidiary, acquisition, and contractor relationship as a potential change in trust boundaries. A parent company may require multifactor authentication and dual approval, while an acquired business still relies on shared mailboxes, informal approvals, or local banking contacts.

The assessment must test the least-protected connection between entities. Recording only the parent company's policy leaves that gap hidden.

Third-party exposure requires separate testing, because vendors, payroll processors, law firms, payment platforms, and managed service providers often appear in legitimate transaction workflows. Document which vendors can request payment changes, which employees can approve them, and which channels are authorized for confirmation.

Contracts should require timely notification of compromised accounts, named escalation contacts, evidence preservation, and cooperation during investigations. A contractor should never be able to redirect funds based solely on an email that appears to come from an internal sponsor. Require independent confirmation through a trusted channel before approving any account or payment change.

Acquisitions and new banking relationships should trigger a focused reassessment before financial processes are consolidated. Review inherited domains, executive names, public filings, vendor records, and OSINT that cyberattackers can use to personalize spear phishing.

International operations require attention to local payment rails, language differences, regional holidays, and privacy obligations. These details affect whether employees recognize unusual requests. They also affect whether investigators can obtain the records needed to confirm what happened.

How Should Findings Map to Frameworks, Insurance, and Contracts?

A BEC assessment creates value when findings become assigned control actions. A risk register that nobody revisits delivers little. Map identity, payment approval, awareness, reporting, incident response, and third-party verification findings to the organization's selected framework.

NIST CSF can organize outcomes by Govern, Identify, Protect, Detect, Respond, and Recover. ISO 27001 can connect findings to the information security management system and corrective actions. CIS Controls can translate weaknesses into prioritized safeguards, while SOC 2 evidence should show that relevant controls operate consistently over time.

The same findings should feed enterprise risk management. A payment-approval weakness belongs in the broader financial, operational, and fraud-risk discussion, with an owner, treatment decision, deadline, and residual-risk statement.

Cyber insurance applications and renewals should reflect actual control operation, including payment verification, privileged access, employee reporting, and incident response. Overstating control maturity creates coverage and credibility problems when a claim requires evidence.

Contractual programs should use the assessment to define minimum requirements for vendors and business partners. Require named contacts, dual authorization for account changes, breach-notification windows, and a documented process for validating urgent requests.

Training content mapped to NIST CSF, ISO 27001, SOC 2, HIPAA, or PCI DSS can support evidence collection. However, completion records alone do not prove that employees can identify and report a BEC attempt.

Pair training records with simulation results, reported-message trends, response times, and remediation actions through phishing simulations for BEC and vendor impersonation. These measures show whether employees apply verification procedures when a realistic request creates pressure.

When Should an Organization Repeat a BEC Risk Assessment?

A sound cadence combines a baseline, periodic review, post-incident analysis, and interim reassessment. The baseline should document payment authorities, approval channels, banking relationships, executive exposure, third-party dependencies, and existing verification controls before the organization sets improvement targets.

Conduct a periodic review at least annually. High-volume payment teams and organizations facing material fraud exposure need more frequent testing. Use this reassessment schedule:

1. 1Baseline assessment: Complete the assessment when launching or rebuilding the BEC program, then record owners, evidence, and unresolved gaps.
2. 2Periodic review: Recheck controls on a defined annual or semiannual cycle, and test high-risk roles with realistic email, vishing, and executive-impersonation scenarios.
3. 3Post-incident review: Reassess immediately after a suspicious payment, credential compromise, vendor impersonation attempt, or confirmed BEC incident. Preserve the attack path and convert each failure into a control change.
4. 4Interim reassessment: Trigger a focused review after leadership changes, acquisitions, major transactions, new banking relationships, new payment platforms, or contractor changes. Remote-work expansion, material control changes, and new AI-enabled attack patterns should also trigger a review.

Leadership turnover deserves particular attention. Cyberattackers monitor public announcements and use new executives, interim officers, and unfamiliar approval chains as pretexts. New payment platforms also change permissions, notifications, and exception handling.

Reassessment keeps the control map aligned with how money and authority actually move. That alignment determines whether BEC defenses hold under pressure.

How Does Security Awareness Training Reduce BEC Risk?

A business email compromise risk assessment converts human-layer observations into a continuous test of whether employees verify unusual requests before money, credentials, or data leave the organization. Security awareness training can then follow those observations, and annual completion rates become a secondary measure.

With that approach, security leaders can connect risky decisions to reporting speed, verification behavior, and residual exposure. The BEC losses recorded in the FBI's 2025 IC3 report show why continuous validation belongs in executive risk decisions. Employees rehearse the pressure patterns cyberattackers use, while leaders see whether controls work beyond the inbox.

How Should Training Target Roles and Risk Signals?

Role-specific training closes the gap between a generic phishing lesson and the decisions that create BEC exposure. A finance employee should practice confirming a changed vendor bank account. An executive assistant should validate an urgent payment request made in a leader's name, and an accounts payable manager should challenge a familiar supplier using a new payment route.

Executives require different exercises, because their public profiles, travel schedules, speaking appearances, and recorded interviews give cyberattackers material for impersonation. A role-based security awareness training program can assign each group the scenarios that match its decisions.

A BEC risk assessment should determine who receives each exercise and why. Relevant signals include repeated clicks on targeted phishing simulations, slow reporting, failure to use an approved callback process, exposure in public executive profiles, prior credential compromise, and risky decisions made under time pressure.

The assessment should also identify whether a person handles wire transfers, payroll changes, mergers, procurement, privileged access, or sensitive client data.

These signals turn security awareness training into a measurable risk-control program that goes beyond a library of mandatory courses. Training should respond immediately after a risky decision with a short microlearning module. The module can explain how a spoofed invoice bypassed normal judgment, followed by a second verification exercise using a different scenario.

The purpose is to strengthen recognition while the decision remains memorable, without punishing the employee. Training should also provide a repeatable action, such as independently locating a known phone number before responding to the request.

Why Must BEC Simulations Cover More Than Email?

Email phishing awareness alone cannot test whether an employee will resist a convincing voice, text message, video call, or hijacked conversation. A criminal can begin with a spear phishing email, continue through vishing, confirm the request by smishing, and imitate an executive in a deepfake video call.

Each channel reinforces the others. A person who passes an email exercise can still approve a transfer when the same request arrives through a trusted voice or live conversation.

Continuous validation should rotate targeted phishing, vishing, smishing, and AI-generated phishing simulations. Voice exercises reveal whether employees challenge a familiar executive voice. A text exercise shows whether they tap a shortened link or hand over a one time code. A deepfake video call tests whether a convincing face overrides the required callback.

Conversation-hijacking exercises can introduce a legitimate email thread that suddenly changes the beneficiary, amount, or deadline. The scenario should measure whether the employee pauses, verifies the change through an independent channel, and reports the request before payment is released.

The same principle applies to reporting. Employees need a clear route for flagging suspicious email, voice, and SMS activity, and the organization should measure whether reports reach the right team before a payment is released. Multi-channel phishing simulations give security teams a framework for testing the human layer across the channels BEC campaigns increasingly combine.

How Should Organizations Measure Improvement?

Measurement should connect individual behavior to business exposure. Completion rates remain useful for proving participation, but they do not show whether a control worked under pressure.

A stronger scorecard tracks simulation failure rate by role, reporting rate, and median time to report. It also tracks the percentage of payment requests independently verified, repeat failure after remediation, and the number of high-risk employees whose residual risk declines over time.

These measures support board-level decisions because they translate training activity into operational outcomes. A rising reporting rate with a falling median time to report indicates that employees are detecting suspicious activity earlier.

A lower phishing click rate without improved payment verification indicates that email recognition improved while the approval process remains exposed. A department with repeated failures across voice and SMS scenarios requires targeted coaching and stronger payment controls. Another generic annual course will not close that gap.

Executives should review trends by business process as well as by employee. The board needs to know which payment workflows remain vulnerable and how quickly suspicious requests are escalated. It also needs to know whether high-value transfers receive independent confirmation and how much residual human risk remains in finance, procurement, payroll, and executive operations.

Those findings can justify investments in callback procedures, dual approval, exposure reduction, or additional exercises for high-risk teams.

Improvement also requires retesting. After a role-specific exercise, run a related scenario through another channel and compare the result with the baseline. If a finance employee rejects a fraudulent invoice email but accepts the same request during a voice call, the organization has found a channel gap. Its training work remains incomplete.

If reporting speed improves across repeated exercises and verification behavior holds under realistic pressure, the assessment demonstrates durable behavioral change.

This approach makes security awareness training part of the BEC control system. The assessment identifies human-layer observations, simulations test the response, microlearning closes the immediate gap, and board reporting shows whether residual risk is declining.

Business Email Compromise Risk Assessment FAQs

What Is Included in a Business Email Compromise Risk Assessment?

A business email compromise risk assessment reviews the people, processes, identities, email systems, payment workflows, third parties, data, detection capabilities, and recovery controls a cyberattacker could exploit. It examines who can request, approve, release, and reconcile payments or sensitive changes, and whether independent verification works under pressure.

The deliverable should include an evidence-backed risk register, control-maturity baseline, prioritized remediation plan, residual-risk estimate, and executive scorecard. Payment and identity paths deserve particular focus, given the scale of exposed BEC losses documented in FBI IC3 data.

How Often Should a Business Email Compromise Risk Assessment Be Performed?

A business email compromise risk assessment should be performed at least annually, with interim reviews after a material change or incident. Reassess when an organization changes banking relationships, payment platforms, approval thresholds, executive leadership, major vendors, authentication controls, or operating jurisdictions, and after any acquisition.

Repeat the review after a confirmed or suspected BEC event to test whether containment, recovery, and verification controls worked in practice. Between formal assessments, track suspicious-request reporting, callback completion, high-risk findings, mailbox-rule reviews, and fund-recall time.

A fixed annual cadence establishes accountability. Event-triggered reviews keep the risk register aligned with the organization that cyberattackers actually see.

What Is the Difference Between a BEC Risk Assessment and a Phishing Test?

A BEC risk assessment evaluates the full business process that could turn an impersonation attempt into financial loss or sensitive-data exposure. A phishing test measures responses to selected messages. The assessment covers payment approvals, vendor changes, identity and mailbox controls, trusted contacts, detection, escalation, recovery, and evidence.

A phishing test provides a behavioral signal, such as reporting or link interaction, within a defined scenario. It does not establish whether a bank-change request requires independent verification or whether finance can stop a fraudulent transfer. A complete validation program combines process walkthroughs with role-specific phishing simulations across email and other channels, including vishing and smishing.

How Is Residual Risk Calculated After Implementing BEC Controls?

Residual BEC risk is calculated by scoring the remaining likelihood and impact after applying evidence-based control effectiveness. Subtracting controls from a risk score without evidence produces an unreliable result. A practical model is: residual risk = inherent likelihood × inherent impact × (1 minus measured control effectiveness).

Score likelihood and impact on defined scales, document the evidence behind each control rating, and record detection speed, response speed, and recovery capability separately. Use ranges when evidence is incomplete, because a precise-looking number can conceal uncertainty.

Recalculate after testing callback verification, approval separation, MFA coverage, mailbox monitoring, reporting behavior, and fund-recall procedures. Assign an owner, deadline, and expiry date to every accepted residual risk.

What Should an Organization Do First After Discovering a Business Email Compromise?

After discovering a business email compromise, the organization should immediately activate its incident response plan, stop pending payments, and contact the bank through a trusted channel to request a recall or transaction intervention. It should then preserve the original messages, full headers, attachments, URLs, timestamps, sign-in records, mailbox rules, and relevant audit logs before altering evidence.

Contain affected accounts by revoking sessions and tokens, resetting credentials, removing malicious forwarding or inbox rules, and reviewing OAuth grants. Notify legal, security, finance, insurers, and law enforcement according to the response plan and applicable obligations. Adaptive Security's guide on what to do if an email account is compromised covers account recovery in more detail.

Report the incident to the FBI and CISA, following CISA incident reporting guidance. Fast coordination turns discovery into containment and gives employees a clear path to act.

Turn BEC Findings Into Stronger Human-Layer Decisions

A business email compromise risk assessment reveals where urgency, impersonation, and payment pressure can override good judgment. Acting on those gaps gives employees clearer verification habits and gives security teams measurable behavioral signals. Take a self-guided tour of Adaptive Security's Security Awareness Training.