Both of these Exchange Online controls don't offer a Risk Accepted option right now, unlike most other ISPM controls. That makes them basically unusable for any org that has a legitimate, tightly scoped exception. You end up stuck with a permanent Not Compliant flag with no way to document that the deviation is intentional and already mitigated. Here's our actual situation. We have two mailboxes that need to auto-forward externally to our PSA/ticketing platform so inbound email creates tickets. We checked with the vendor and there's no alternative ingestion method available right now. So we locked down the Default remote domain and Default outbound spam policy tenant-wide, then built a narrow exception on top: a dedicated security group scoped to exactly those two mailboxes, a custom outbound spam policy, a named remote domain restricted only to the vendor's domain, and a transport rule that actively rejects any forward attempt going anywhere except that approved domain. But "Block Exchange Forwarding" requires every outbound spam policy, including custom ones, to be set to Off. There's no way this control shows compliant no matter how well the exception is built or documented. Same problem with "Transport Rules Should Not Bypass Security Controls." It flags anything with SCL=-1, but we have two rules that legitimately need that: one tied to our third-party email security gateway (so EOP doesn't double-filter mail that's already been scanned upstream) and one required by our security awareness training platform so phishing simulation emails actually land in inboxes instead of getting filtered out. Both are standard integration patterns for anyone running a non-Microsoft gateway or doing phishing simulations, not misconfigurations. The Risk Exception feature was built for exactly this situation. The release notes say it exists because "not every policy is relevant to all organizations" and so partners don't get stuck with a non-compliant flag or escalations for things they've already handled. Both of these controls even say in their own documentation that exclusions should be based on organizational policy, so they clearly anticipate that exceptions will happen. They just don't let you actually mark one. Please add Risk Exception support to these two controls the same way it works everywhere else. Partners running a third-party email gateway, phishing simulation tool, or PSA/ticketing integration need a way to show that a deviation is deliberate, reviewed, and compensated for instead of just permanently flagged.
