Abnormal Security Migration: Trust Exceptions

Trust Exceptions

This page exists to inventory every mail trust decision that may be hiding inside ESA, M365, or user-level workflows. If this inventory is skipped, the migration will either break legitimate mail flow or preserve dangerous exception debt.

What "Safe List" Usually Means

In practice, people often use vague language. For this project, break it into explicit categories:

Category	Examples
ESA allow lists	Trusted senders, trusted domains, connection filters, custom bypass logic, message filter exceptions
ESA block lists	Blocked senders, domains, IPs, content filter rules, reputation-based overrides
M365 tenant allow/block	Microsoft tenant allow/block list, anti-spam exceptions, spoof intelligence allow entries, transport rule bypasses
User-level safelists	Outlook safe senders, junk mail settings, mailbox-level user exceptions
Operational exceptions	Help desk release workflows, analyst override habits, undocumented manual quarantine releases

Why This Matters

Abnormal does not replace ESA in a one-to-one inline gateway model. Some trust decisions may need to move to M365 native controls. Some should move nowhere and should be deleted. Some may be business-critical and require explicit preservation.

The migration question is not "where do we import the safelist?"

The migration questions are:

what trust decisions currently exist?
why were they created?
are they still needed?
where should they live after migration?
who approves them going forward?

Risks

Risk	Description
False positives after cutover	Legitimate mail may be quarantined or flagged if required exceptions are not understood beforehand.
Legacy security debt preserved	Old broad allow rules may be recreated blindly even if they are unsafe or obsolete.
Ownership confusion	Teams may assume Abnormal, M365, or the help desk owns the exception workflow without documenting it.
Audit gaps	Undocumented overrides and release habits may exist outside any formal policy set.

Risk

Description

False positives after cutover

Legitimate mail may be quarantined or flagged if required exceptions are not understood beforehand.

Legacy security debt preserved

Old broad allow rules may be recreated blindly even if they are unsafe or obsolete.

Ownership confusion

Teams may assume Abnormal, M365, or the help desk owns the exception workflow without documenting it.

Audit gaps

Undocumented overrides and release habits may exist outside any formal policy set.

Inventory Table

Build this table with real entries as discovery proceeds.

Exception	Current Location	Type	Business Reason	Still Needed	Target Control
Example: payroll vendor domain	ESA sender allow list	domain allow	Critical HR communications	Unknown	Review for M365 tenant allow/block or approved exception workflow
Example: executive assistant release rule	Help desk / operations workflow	manual release	Reduce false-positive escalations	Unknown	Document owner, approval path, and whether Abnormal changes the process

Exception

Current Location

Type

Business Reason

Still Needed

Target Control

Example: payroll vendor domain

ESA sender allow list

domain allow

Critical HR communications

Unknown

Review for M365 tenant allow/block or approved exception workflow

Example: executive assistant release rule

Help desk / operations workflow

manual release

Reduce false-positive escalations

Unknown

Document owner, approval path, and whether Abnormal changes the process

Discovery Questions

Ask these directly to the email and security teams:

What allow lists, block lists, and bypass rules exist in ESA today?
Which are sender-, domain-, IP-, or policy-based?
Which ones are considered business-critical?
Which ones were created only to suppress false positives?
Which M365 tenant exceptions already exist separately from ESA?
Which workflows rely on manual release from quarantine?
Who currently approves new allow-list entries?
Who should own that process after Abnormal goes live?

Migration Decision Standard

For every exception, assign one of these outcomes:

preserve and migrate
replace with M365-native control
replace with Abnormal workflow
delete as obsolete or unsafe
escalate for business-owner decision

If the answer is vague, the exception is not migration-ready.

Next Deliverable

The next useful artifact is a reviewed exception inventory with owners, business justification, and target-state disposition. That document should exist before any production cutover plan is approved.