Purview Information Barriers

Information Barriers (IB) in Microsoft Purview prevent specific groups of users from communicating or collaborating with each other across Microsoft 365. The classic use case is ethical walls in financial services — research analysts must not collaborate with investment banking — but they apply equally to legal, healthcare, M&A, and any scenario where two groups must be kept apart.

What barriers actually block

When two users are on opposite sides of an active barrier, they cannot:

• Chat in Teams (one-to-one or group).
• Be in the same Teams team or Microsoft 365 Group.
• Be in the same channel (including shared and private channels).
• Share files via OneDrive or SharePoint between the segments.
• Schedule meetings with each other.
• Call each other in Teams.
• Find each other in people search or directory lookups.

The user experience is mostly invisible — the other party doesn't appear in search, and shared content is blocked. From a workflow standpoint, the segments operate as if the other doesn't exist.

The model: segments and policies

Information Barriers are configured with two object types:

• Segments — groups of users defined by an Entra ID attribute query (department, country, function).
• Policies — rules between two segments: block or allow.

A typical configuration:

• Segment: Research Analysts (where Department = "Research").
• Segment: Investment Bankers (where Department = "IBD").
• Policy: block communication between Research and IBD.

Multiple policies layer to express complex matrices.

SharePoint and IB Modes

For SharePoint sites and OneDrive accounts, IB modes define how barriers apply:

• Open — no IB enforcement (the default).
• Implicit — site automatically reflects the segment of its owner.
• Explicit — site has explicit segments, only those segments can access.
• Owner-moderated — owners explicitly invite cross-segment members.

This lets a site be tightly scoped to one segment while another is shared between two.

Operational considerations

• IB is disruptive — once active, in-flight conversations between blocked users break. Roll out with HR and stakeholder communication.
• Service accounts and admins typically need exceptions.
• Existing memberships must be reconciled — Teams or sites with mixed-segment members will need owners or content moved.
• Federation with other tenants complicates IB — Microsoft 365 federation policies and Cross-Tenant Access Settings need to mirror the model.

Audit and reporting

IB has its own audit trail — every blocked attempt is logged for compliance reporting. Regulators in financial services often request this evidence directly.

Licensing

IB requires Microsoft 365 E5, Microsoft 365 E5 Compliance, or the Information Protection and Governance add-on. Standalone IB licensing is also available.

When you need it

For financial services firms with research/IBD separation, M&A advisory firms, and any organisation with regulatory firewall requirements, IB is essentially mandatory. For most other organisations, it's overkill — simpler permissions models and sensitivity labels cover similar use cases at lower operational cost.