A warning sign is when BEC continues despite regular training, because the campaign is exploiting fear, urgency, and trust rather than simple user ignorance. Another signal is repeated success against the same workflows, such as payment approvals or executive impersonation. If training is not paired with process controls, verification steps, and identity-based safeguards, it will not reliably reduce BEC risk.
Why training alone stops mattering once BEC targets the workflow
security awareness training helps when the problem is careless clicking, but BEC usually succeeds because the attacker is abusing a business process, not just a person. If the same approval path, supplier change, payment request, or executive request keeps getting bypassed after repeated training cycles, that is a sign the control gap sits in the workflow design, not only in user judgement.
One practical indicator is that the organisation can explain the scam in the abstract, yet still cannot reliably stop a fraudulent request in the moment. That usually means the attacker is exploiting urgency, authority, and familiarity, so the real weakness is a missing verification step, weak segregation of duties, or an approval path that is too easy to impersonate.
Training can reduce susceptibility, but it does not create trustworthiness in an email thread, and it does not verify who actually sent a request. The most revealing sign is repeated success against the same business action, especially when the request is plausible enough to pass through normal operations without raising friction.
- Payment approval workflows that can be completed from email alone.
- Supplier bank detail changes that are not verified out-of-band.
- Executive impersonation requests that bypass normal authorisation checks.
- Exceptions where urgency is used to override routine validation.
What repeated BEC success is telling you about control failure
When BEC persists after awareness campaigns, the organisation is likely relying on people to compensate for weak process control. That is a brittle design because human vigilance is inconsistent under pressure, and the attacker only needs one successful exception. The better question is not whether staff remember the training, but whether the control chain makes a fraudulent request hard to execute even when someone is deceived.
This is where layered safeguards matter: confirmation through a second channel, approval rules that match transaction risk, and identity-based checks for high-impact requests. A useful benchmark from NHIMG research is that the Ultimate Guide to Non-Human Identities notes 97% of NHIs carry excessive privileges, which is a reminder that BEC often becomes worse when automation or service credentials can be abused after the initial email compromise.
Repeated BEC is also a sign that the organisation may have training but no meaningful detection of anomalous request patterns. If an attacker can reuse the same pretext, same timing, or same approval path, then the control environment is not adapting to the abuse pattern.
- Does the request need a second, independent approval before action is taken?
- Can a finance or operations team verify the request without trusting the email channel itself?
- Are high-risk changes tied to strong identity checks rather than message content alone?
- Are exceptions logged and reviewed so the same pattern cannot be reused?
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | BEC often abuses approval paths and account misuse, so account governance is central. |
| 6 — Access Control Management | BEC resistance depends on limiting who can execute sensitive workflow changes. | |
| Recommendation — Review and restrict accounts that can approve or redirect high-value business actions. Enforce least-privilege access for payment, vendor, and executive-request workflows. | ||
| NIST CSF 2.0 | PR.AC — Access Control | BEC mitigation depends on verifying authority before sensitive actions proceed. |
| PR.AT — Awareness and Training | The question asks when training is insufficient and needs stronger controls. | |
| DE.CM — Continuous Monitoring | Repeated BEC success signals detection gaps in request and approval monitoring. | |
| Recommendation — Apply access controls that require stronger verification for high-impact requests. Use training as a supporting control, not the sole defence against BEC. Monitor for repeated payment, impersonation, and approval-pattern anomalies. | ||
| MITRE ATT&CK | T1566 — Phishing | BEC commonly begins with phishing or social-engineering delivery of the fraudulent request. |
| T1656 — Impersonation | Executive or vendor impersonation is a core BEC technique. | |
| T1078 — Valid Accounts | BEC often succeeds by abusing trusted accounts or existing business trust. | |
| Recommendation — Map BEC lures to phishing techniques and tune detections for impersonation cues. Hunt for impersonation patterns in requests that seek payment or account changes. Protect valid accounts with stronger verification before approving sensitive actions. | ||
Practitioner Guidance
What to prioritise: Treat repeated BEC as a workflow control problem first and a training problem second. If the same request type keeps succeeding, focus on the approval chain, verification channel, and exception handling before adding more awareness content.
What to verify: Check whether high-value actions, such as payments, supplier changes, and executive requests, require a confirmation step that is independent of the original email. If the answer is no, the organisation is still depending on message authenticity, which BEC is designed to defeat.
Decision rule: If staff can describe the scam but the business process still permits one-step execution, escalate to process redesign and stronger identity verification. If a request can cause real financial or operational harm, it should not be executable on trust alone.
Practitioner takeaway: The clearest sign that awareness training is not enough is when attackers keep winning the same business process, because that proves the control failure is structural, not educational.
Related resources from NHI Mgmt Group
- How should security teams prevent business email compromise in finance workflows without relying on awareness training alone?
- How should organisations reduce business email compromise risk without relying only on awareness training?
- How should security teams reduce business email compromise risk beyond secure email gateways?
- How should security teams detect business email compromise without relying on payloads?
