Email information barriers in Microsoft 365 are failing static DLP

At a glance

What this is: This guide argues that static DLP cannot reliably enforce email information barriers in Microsoft 365 because it reacts too late and demands heavy manual upkeep.

Why it matters: IAM, compliance, and security teams need barrier controls that govern disclosure before send, because breached internal separation can trigger operational, regulatory, and client impact.

By the numbers:

• 66% of organisations have had their email information barriers breached.

Context

Email information barriers are controls that prevent certain groups from exchanging sensitive information, usually to preserve confidentiality, market integrity, or regulatory separation. In Microsoft 365, the governance problem is that a rule set applied after content is created or sent is often too late to stop disclosure. The article frames this as a control-design issue, not just a filtering issue.

For IAM and compliance teams, the relevant question is whether email controls can enforce separation dynamically using classification and group context, rather than relying on static patterns and manual maintenance. That matters wherever internal walls, regulated communications, or need-to-know segmentation are expected to hold under routine user error.

Knowbe4's starting position is typical of organisations that have built policy-heavy controls around email without enough runtime enforcement at the point of send.

Key questions

Q: What breaks when organisations rely on static DLP for email exfiltration detection?

A: Static DLP breaks when users intentionally adapt their behaviour to avoid fixed rules. It can miss personal-email forwarding, disguised attachments, and policy-bypassing workflows that still move sensitive information. Organisations need behavioural detection, not only content matching, because the attacker or insider can change the method faster than rule sets are updated.

Q: Why do static email barriers create operational and compliance risk?

A: They create risk because exceptions, stale rules, and manual upkeep gradually make the control diverge from the organisation's real separation model. Once that happens, breaches can surface as workflow disruption, client loss, or regulatory penalties even though the policy appears to exist on paper.

Q: How do security teams know whether an email control is actually blocking threats?

A: They should compare blocked, delivered, and remediated messages using the same threat IDs and the same time window across all layers. If the report cannot show what was prevented before delivery, what arrived in the inbox, and what was cleaned up later, the measurement is incomplete and should not drive a buying decision.

Q: Should organisations use dynamic email controls instead of static DLP for information barriers?

A: When the control objective is preserving internal separation, dynamic enforcement is usually the better fit because it can apply live context at send time. Static DLP still has value for broad leakage detection, but it is weaker where policy depends on specific business relationships, group boundaries, and confidentiality tiers.

Technical breakdown

Why static email DLP misses barrier violations

Static DLP works by matching content against predefined rules, classifications, or keywords, then allowing or blocking based on those rules. That approach struggles when the control objective is not generic leakage prevention but maintaining separation between specific internal groups. The barrier problem is contextual: the same message can be acceptable for one audience and prohibited for another. If the control engine does not evaluate sender, recipient, classification, and organisational permissions together at send time, it becomes a retrospective filter rather than an enforcement layer.

Practical implication: move barrier decisions into the sending workflow so separation is enforced before disclosure occurs.

How dynamic analysis changes the control model

Dynamic email DLP evaluates the message in context, using existing data classifications and group permissions to decide whether a transfer should proceed. That makes the control closer to policy enforcement than content scanning because it can apply organisational rules in real time. In practice, this shifts the design from administrative rule maintenance toward integrated governance over who can send what to whom. It also creates an opportunity for user self-correction, which is important when most violations are accidental rather than malicious.

Practical implication: tie classification, group membership, and send-time checks together so policy reflects current organisational boundaries.

Why administrative overhead becomes a security issue

A control that is expensive to maintain tends to degrade over time, not just in cost but in accuracy. Static DLP rules accumulate exceptions, stale exceptions, and local workarounds, which weakens the barrier over time and encourages teams to accept false positives as normal. In identity governance terms, this is a policy drift problem: the system no longer represents the current organisational separation model. When controls drift, the organisation may believe it still has effective barriers even though operational reality has moved on.

Practical implication: treat rule maintenance, exception review, and policy drift as part of barrier assurance, not as back-office administration.

Threat narrative

Attacker objective: The practical objective is not stealthy exfiltration but unauthorized disclosure across internal barriers, which can trigger business and compliance harm.

1. Entry occurs when users compose or forward email inside Microsoft 365 without a runtime barrier check that understands current classifications and group permissions.
2. Credential or access abuse is not the primary issue here; the failure is policy misapplication, where static rules do not stop a prohibited disclosure path.
3. Impact appears as breached information barriers, which the article links to operational stoppages, client churn, and regulatory penalties.

Breaches seen in the wild

• Mimecast certificate compromise 2021: SolarWinds attackers stole a Mimecast certificate that authenticated to Microsoft 365 Exchange and used it against a few customer tenants.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static DLP is the wrong control model for information barriers. The article shows that content scanning alone cannot preserve internal separation when policy depends on who is sending to whom, not just what the message contains. This is a governance failure as much as a technology one, because the barrier has to exist at the moment of disclosure. Practitioners should treat barrier enforcement as a runtime policy problem, not a mail-filtering problem.

Information barriers are really an identity and access problem disguised as email security. If classification and group permissions are the inputs to enforcement, then the control sits at the intersection of identity governance, data governance, and messaging policy. That means the organisation must know who belongs where, which data classes each group may handle, and how those rules are enforced when users act. The decision point is the send action, so identity context matters as much as DLP content logic.

Policy drift is the hidden failure mode in static barrier designs. When a control needs heavy administrative upkeep, the rule set usually lags the real organisation, especially after restructures, exception requests, or new collaboration patterns. That produces a false sense of separation while operational exceptions accumulate. Barrier assurance debt: the longer a static rule set persists, the more its actual enforcement diverges from the organisation's current confidentiality model. Practitioners should measure barrier health as a living control, not a one-time configuration.

User self-correction is a control feature, not a convenience feature. The article's emphasis on real-time correction reflects an important governance point: many barrier violations are human mistakes made under normal workflow pressure. If the control can warn and let the sender correct the message before release, it reduces both breach likelihood and support burden. That makes the control more usable and therefore more durable across the programme.

Microsoft 365 barrier governance exposes a broader lesson for NHI and human identity programmes alike. Controls that depend on static assumptions about role, group, or data context will fail when those assumptions change faster than the policy engine can adapt. That is true for email barriers, and it is also true for privileged access and non-human workflows that inherit stale permissions. Practitioners should design for live context, not static entitlement snapshots.

What this signals

Barrier enforcement has to move from content review to contextual decision-making. For practitioners, the key shift is that email security controls need to understand classification, sender, recipient, and organisational permissions in one decision. That is the difference between a monitor and an enforcement point, and it matters whenever internal separation has regulatory or commercial consequences.

Barrier assurance debt: static DLP rules age into governance risk when exception handling and manual maintenance outpace the actual business structure. Teams should watch for policy drift, because the longer the control stays static, the more it will diverge from current access boundaries and collaboration patterns.

The operational signal to watch is whether employees can correct mistakes before release rather than after a message has already crossed the boundary. That is where email barrier governance becomes durable, because the control supports normal work instead of fighting it.

For practitioners

• Implement send-time barrier enforcement Check sender, recipient, classification, and group context before email is released so prohibited transfers are blocked in workflow rather than after delivery.
• Synchronise classification with group permissions Use existing data classifications and authorised groups as active policy inputs so barrier rules reflect current organisational separation requirements.
• Build real-time user correction into the mail flow Present warnings and remediation prompts that let employees fix misaddressed or misclassified messages before they leave Microsoft 365.
• Treat rule maintenance as assurance work Review exceptions, stale policy logic, and administrative overhead as part of barrier governance because degraded static rules create hidden exposure.

Key takeaways

• Static DLP is not a reliable substitute for live information barrier enforcement in Microsoft 365.
• The article links breached barriers to operational stoppages, client churn, and regulatory penalties, showing that the impact extends beyond email hygiene.
• The decisive control question is whether separation is enforced before disclosure, with current classification and permission context at send time.

Key terms

• Information Barrier: An information barrier is a policy that prevents certain users or groups from exchanging or viewing restricted information across defined organisational boundaries. In practice, it depends on identities, permissions, classifications, and enforcement controls that can stop disclosure before it happens.
• Static DLP: Static DLP is a rule-based approach to data loss prevention that checks messages or files against predefined patterns, labels, or conditions. It is effective for known content patterns but often struggles when context, permissions, or business relationships determine whether disclosure is actually acceptable.
• Static Email DLP: A content-based control that flags or blocks messages using fixed rules such as keywords, labels, attachments, or destination addresses. It helps with known policy violations, but it is weak against users who change behaviour, disguise content, or use approved workflows to bypass controls.
• Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps security and identity practitioners translate control design into durable operating practice across modern programmes.