Ownership should be shared across messaging administration, identity security, and fraud or finance operations. Email teams control the platform, identity teams control the compromised account response, and finance teams understand which workflow changes indicate transfer risk. That shared model reduces the chance that suspicious rule activity is treated as only an email problem.
Who should own inbox rule governance in a BEC programme?
Inbox rule governance is best treated as a shared control, not a single-team problem. Messaging administration owns the mail platform and rule settings, identity security owns the response when an account is compromised, and fraud or finance operations own the payment and workflow context that tells you when a rule is a transfer-risk signal rather than routine mailbox hygiene.
Why inbox rules sit at the intersection of email, identity, and payments
Inbox rules matter in BEC because they are often used to hide replies, redirect alerts, suppress invoices, or move payment confirmations out of sight. That makes them more than an email usability setting. They are a post-compromise control surface that can influence whether a fraudulent payment request is noticed in time. NHIMG’s Email Identity and BEC Guide covers inbox rules alongside mailbox takeover, email impersonation, and payment verification, which is the right operational framing for this question.
The ownership model should reflect that overlap. Email administrators can enforce rule creation, auditing, and policy settings, but they rarely know which mailbox behavior is financially meaningful. Identity teams can investigate whether the account was abused, whether sessions or tokens were hijacked, and whether the compromise extends beyond one mailbox. Finance or fraud teams can judge whether an unexpected rule change affects approvals, invoice handling, or bank detail verification. A workable programme assigns each of those teams a distinct decision right.
What good governance looks like in practice
Good inbox rule governance starts with clear thresholds for intervention. Not every rule is malicious, so the programme should separate normal workflow automation from patterns that conceal mail, forward externally, or reroute payment-related messages. When those patterns appear on a privileged, finance-facing, or high-risk user account, the response should escalate beyond mailbox cleanup.
The governance model also needs ownership for review cadence and evidence. Email teams should be able to show rule inventory, change logs, and detection coverage. Identity teams should be able to show how suspicious mailbox behavior is tied to sign-in anomalies, token revocation, and session reset. Finance teams should be able to validate which mail flows map to approvals, vendor onboarding, bank-change requests, or exception handling. Without that mapping, rule review becomes generic and slow.
This is especially important for Microsoft 365 environments, where inbox rule persistence is a known operational concern. NHIMG’s Microsoft 365 Security Guide is useful here because it connects mailbox auditing, Defender settings, app consent, and exchange hardening to the same governance problem. The practical lesson is that inbox rule control should be integrated with broader mailbox and identity telemetry, not treated as an isolated Exchange task.
How to divide accountability without creating gaps
Shared ownership works only if the handoffs are explicit. Messaging administration should own policy enforcement and monitoring, identity security should own compromise triage and recovery, and finance or fraud operations should own the business-rule interpretation of suspicious mail flow changes. One team should be the operational owner, but no team should be allowed to close a suspicious rule case on its own if the payment or transfer context is unresolved.
A strong operating model also benefits from cross-team playbooks. For example, if a rule forwards messages externally or deletes vendor emails, the case should trigger account review, session invalidation, and financial workflow checks at the same time. That prevents the common failure mode where one team removes the rule while another team continues to trust the mailbox state as if no compromise occurred.
Practitioner takeaway: Treat inbox rule governance as a shared response path with one owner for platform control, one for compromise response, and one for business-impact validation. If the programme cannot answer who decides whether a suspicious rule changes payment risk, it is not mature enough for BEC.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Inbox rule governance needs scoped admin rights and limited mailbox control. |
| AU-2 — Event Logging | Rule creation and modification must be logged to investigate BEC activity. | |
| IA-5 — Authenticator Management | Compromised mailbox response often requires credential and token lifecycle action. | |
| Recommendation — Limit mailbox and rule administration to the smallest necessary privilege set. Log inbox rule changes and retain audit trails for investigation. Rotate or revoke compromised authenticator material after suspicious rule activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Compromised mailbox access and stale rule rights create lingering post-compromise risk. |
| NHI-05 — Overprivileged NHI | Service and admin accounts handling mail workflows can overreach if rule control is too broad. | |
| Recommendation — Remove lingering mailbox access paths when ownership changes or compromise is suspected. Reduce mailbox-rule and mail-flow privileges to the minimum operational scope. | ||