Information barriers

The job: ethical walls

Some groups must be prevented from communicating — regulatory ethical walls (advisory vs trading), separation between competing client teams, day-vs-night trading desks. Information Barriers (IB) enforce that in Microsoft 365: blocked parties can't chat, call, add each other to Teams, see each other in people search, or share files across the wall.

Segments then policies

1. Segments — non-overlapping groups defined by a directory attribute (department, job title, membership). A user should belong to exactly one segment — overlapping segment definitions are the number-one source of IB misbehaviour, because a user in two segments creates ambiguous policy.
2. Policies — per segment pair, either:
   • Block — segment A cannot communicate with segment B, or
   • Allow — segment A can communicate only with named segments (everything else implicitly blocked). Block and allow are mutually exclusive approaches for a given segment; mixing them incoherently is the second big failure mode.

Policies are authored, then applied as a set (Start-InformationBarrierPoliciesApplication), and evaluation runs across the estate.

Scope is wider than "Teams chat"

IB reaches further than people expect: Teams (chat, calls, membership), SharePoint and OneDrive (site access and sharing), and it interacts with Teams meetings and other collaboration surfaces. Assuming IB only governs chat, and leaving SharePoint sharing open across the wall, is a common gap. There are also IB modes governing how far restriction extends (e.g. owner-moderated vs fully restricted contexts) — worth confirming per deployment.

The failure modes to name

• Overlapping segments → a user matched to multiple segments → undefined/ unexpected blocking. Segments must partition cleanly.
• Conflicting policies → application fails or produces surprises; IB refuses to apply an incoherent set, which is safer but stalls rollout until resolved.
• Attribute drift → segments key off directory attributes; if HR data is stale or unpopulated, people land in the wrong segment (or none) and the wall leaks.
• Interaction with normal collaboration → over-broad blocks break legitimate cross-team work; like DLP, IB wants scoping and a test posture, not a big-bang block.

What to watch (proofs)

• Segment hygiene: Get-OrganizationSegment — confirm segments are defined on clean attributes and don't overlap (spot-check users mapped to one, not many).
• Policy coherence: Get-InformationBarrierPolicy for block/allow definitions and their applied status — no conflicting or unapplied policies.
• Effective state per user: Get-InformationBarrierRecipientStatus for a sample of users on each side of a wall — the barrier as actually evaluated, not as authored.
• Cross-workload check: confirm blocked pairs are also blocked in SharePoint/ OneDrive sharing, not just Teams chat — the scope gap, closed.