Information Barriers and Ethical Walls Guide

An information barrier that exists only in a compliance manual will not stop a dealmaker in one team from messaging an analyst in another, or a lawyer from opening the other side's file. Banks, brokers, asset managers, law firms, consultancies and public bodies all have groups that must not share information, because doing so would create a conflict of interest, misuse inside information or breach a client duty. This guide covers how to design the barrier (who is walled from whom, and why), how to enforce it in collaboration tooling with Microsoft 365 information barriers as the worked example, where the tooling stops, and how to monitor and evidence it to a regulator. It is written for compliance engineers, Microsoft 365 administrators, security architects and the control owners who have to prove the wall works.

Key takeaways

Design the wall before you configure it. Start from the conflict or regulatory duty, define the segments from authoritative HR data, and decide block versus allow per segment, because some settings cannot be changed later.
Collaboration tooling covers only part of the channel set. Microsoft 365 information barriers restrict Teams, SharePoint, OneDrive and basic Planner plans, but not Exchange email, which needs mail flow rules, and not federated external users.
Barriers are two-way and segment based. Microsoft's implementation does not support a one-way block, and each segment can carry only one policy, so the design has to fit that model.
Apps and service identities can tunnel through. App-only access to barrier-protected SharePoint sites is controlled by a tenant bypass setting, and bots are not supported in the Teams implementation, so non-human identities need their own review.
Monitoring is what makes it defensible. Pair the technical block with communication surveillance (such as a conflict of interest policy), audit of every barrier change, and wall-crossing records that show who was brought over and why.

What an information barrier is, and the duties behind it

An information barrier (also called an ethical wall or, in older usage, a Chinese wall) is a set of organisational, physical and technical arrangements that stop information held by one group reaching another group that could misuse it or be conflicted by it. The technical layer is only one part: the barrier also includes reporting lines, remuneration, physical separation, watch and restricted lists, and a controlled process for bringing someone "over the wall" when a deal needs them.

The duties that make barriers necessary differ by sector, and the design should cite the one that applies.

Context	Source of the duty	What it expects
US broker-dealer research	FINRA Rule 2241	Written policies to manage research conflicts (b)(1); information barriers or other institutional safeguards insulating analysts from investment banking and others such as sales and trading (b)(2)(G); no prepublication review of research by investment banking (b)(2)(A); investment banking may not supervise or control analysts (b)(2)(C). Firms with limited investment banking activity are exempt from several provisions but must still maintain (b)(2)(G) safeguards.
UK and EU market abuse	UK MAR Article 9(1) (legitimate behaviour)	A legal person holding inside information is not deemed to have dealt on it if it has established, implemented and maintained adequate and effective internal arrangements ensuring the decision maker did not have the information, and did not encourage or influence them. The barrier is the evidence for this defence.
UK investment firms	FCA Handbook SYSC 10.2 (Chinese walls)	The FCA Handbook has a dedicated section on Chinese walls within its conflicts of interest rules. Read the current text on the FCA Handbook site before relying on it.
US broker-dealer supervision	FINRA Rule 3110	Supervision of communications, which Microsoft cites as a driver for communication compliance reviews.
Law firms and professional services	Professional conduct rules and client engagement terms	Lawyers acting for different clients must not access each other's matter data. Microsoft's own scenario list includes this case.
Public sector and education	Internal policy, data protection	Departments or schools that must not share information, for example instructors and students in different schools in one district.

See the Financial Services Cyber Regulation Map for the wider regulatory picture.

Designing the barrier: segments, direction and exceptions

Most failed barrier projects fail at design, not configuration. Work through these decisions with compliance and legal before anyone opens PowerShell.

Name the conflict. For each pair of groups, write down why they are separated (inside information, research independence, client confidentiality) and the rule that requires it. This becomes the policy rationale and the audit evidence.
Define segments from authoritative attributes. Segments should come from HR-mastered attributes such as department or cost centre, synchronised into the directory. Microsoft's guidance is to populate these attributes in Microsoft Entra ID or Exchange Online before defining segments. Hand-maintained groups drift.
Choose block or allow per segment. A block policy names segments the assigned segment cannot talk to. An allow policy restricts the assigned segment to talking only with listed segments. Allow policies are stricter and suit small, highly sensitive teams such as a deal team; block policies suit broad separations such as research versus investment banking.
Remember both directions. Microsoft information barriers are two-way: a one-way block (marketing can contact day traders, but not the reverse) is not supported. A mutual block needs a policy on each segment.
Plan for people in more than one segment. In multi-segment mode a user can hold up to 10 segments, and two users are compatible only if they share at least one segment. Map supervisors, control functions and shared services explicitly.
Design the wall-crossing process. Decide who approves bringing someone over the wall, how it is recorded, how long it lasts and how the person is moved back. Technically this is a change to the person's segment attribute, so it must flow through the same identity lifecycle as any other access change.
Decide the control functions' position. Legal, compliance and audit often need to see both sides. Give them a deliberate segment design rather than leaving them unsegmented by accident.

Some choices in Microsoft 365 are irreversible or hard to change: segment names cannot be changed after creation, a policy's type (block or allow) cannot be changed without deleting and recreating it, and Microsoft states that once multi-segment mode is enabled and configured you should not revert to single segment. Settle the design first.

Enforcing it in Microsoft 365

Microsoft Purview information barriers are the most widely deployed technical barrier for collaboration tools. The facts below come from Microsoft Learn; check the current pages before deployment, because the feature has changed modes over time.

Modes and limits

Run Get-PolicyConfig in Security & Compliance PowerShell and check InformationBarrierMode.

Mode	Segments per organisation	Segments per user	Exchange address book policies	Notes
Legacy	250	1	IB relies on and generates ABPs; remove existing ABPs first	Eligible to upgrade in future, per Microsoft
SingleSegment	Not stated on the page	1	IB no longer uses ABPs; existing ABPs unaffected	Can be switched to MultiSegment only when no segments or policies exist
MultiSegment	5,000	Up to 10	IB no longer uses ABPs	`Set-PolicyConfig -InformationBarrierMode 'MultiSegment'`; do not revert

What is restricted, per workload

Workload	Covered	What the barrier checks
Microsoft Teams	Yes	Searching for users, adding team members, starting 1:1 or group chats, meeting invites and entry, screen sharing, VoIP calls, file sharing and sharing links. Guests are covered if discoverable in the global address list.
SharePoint and OneDrive	Yes, enabled separately	Adding members, accessing and sharing a site or content, searching a site. Teams-connected sites are not covered until IB is enabled for SharePoint and OneDrive.
Planner	Basic plans only	People picker results when sharing plans or assigning tasks.
Exchange Online email	No	Not restricted by IB. Use Exchange mail flow rules.
Federated external organisations	No	Users from federated external organisations are not restricted, although IB still applies between your own users inside chats or meetings they organise.

Site and team modes

Open: no IB policies apply; the default for teams created before IB was enabled and for sites with no segments. Existing teams stay Open until switched, for example with Set-UnifiedGroup -InformationBarrierMode Implicit.
Implicit: the default for teams created after IB is enabled; access follows membership of the connected Microsoft 365 group.
Owner Moderated: only the owner can share, following their own policy; useful where incompatible users must occasionally collaborate under supervision.
Explicit: only users whose segment matches a segment associated with the site, up to 100 compatible segments per site. Adding a segment with Set-SPOSite -AddInformationSegment switches the site to Explicit.

In every barrier mode except Open, "anyone with the link" and company-wide sharing links are disabled on the affected sites. See the Microsoft Teams Security Guide and the Microsoft 365 Security Guide for the surrounding tenant controls.

Rolling out a barrier, step by step

Prerequisites: confirm licensing, assign the least privileged admin role (Compliance administrator or IB Compliance Management rather than Global Administrator), turn on audit logging (it is needed to check policy application status) and enable scoped directory search in Teams. Microsoft says to wait at least 24 hours after enabling scoped directory search before defining policies.
Clean the directory: check that every in-scope user has the segment attribute populated correctly. Run a report of unsegmented users; they will not be covered by any policy.
Check the mode: run Get-PolicyConfig. If you are in SingleSegment mode and need people in several segments, switch to MultiSegment before creating anything. In Legacy mode, remove existing address book policies first.
Create segments: New-OrganizationSegment with a -UserGroupFilter on the chosen attribute. Only Microsoft 365 Groups work for group-based segments; distribution lists and security groups are not treated as IB groups.
Create policies as Inactive: New-InformationBarrierPolicy with -SegmentsBlocked or -SegmentsAllowed and -State Inactive. One segment per policy, and no more than one policy per segment.
Pilot: start with a single pair of small test segments made of volunteer accounts. Activate with Set-InformationBarrierPolicy -State Active, then run Start-InformationBarrierPoliciesApplication. Allow about 30 minutes for application to begin; Microsoft gives a throughput of roughly 5,000 user accounts per hour.
Test every channel: from each side, try search, 1:1 chat, group chat, meeting join, screen share, call, file share and site access. Record the results as evidence. Then send an email across the wall to confirm your mail flow rule catches it.
Enable SharePoint and OneDrive: Set-SPOTenant -InformationBarriersSuspension $false (about an hour to take effect, and per geography in Multi-Geo tenants), then set segments or modes on sensitive sites.
Convert existing teams: move legacy Open teams to Implicit using Microsoft's bulk script, after warning owners that incompatible members will be removed.
Expand in waves: roll out by business line, checking Get-InformationBarrierPoliciesApplicationStatus after each run.

Rollback: set the affected policy back to Inactive and re-run the application, or suspend IB for SharePoint and OneDrive with -InformationBarriersSuspension $true. Treat any rollback as a compliance event: record it, notify compliance and time-box it. Check afterwards that the users and sites in scope behave as expected.

Where the tooling stops: closing the gaps

Gap	Why it exists	Compensating control
Email	IB does not restrict Exchange Online email	Mail flow (transport) rules blocking or routing for review messages between segment groups; communication surveillance on Exchange
External federation and personal channels	Federated external users are not restricted; personal messaging apps are outside the tenant	External access allow lists, policy on approved channels, archiving of approved off-tenant channels, attestation
Pre-existing access	Creating or changing a policy does not remove access already granted, for example plans already shared	Access review of shared sites, files and plans for each new segment pair before go-live
Unsegmented users	Users without a segment are outside every policy	Daily report of in-scope departments with missing attributes; joiner workflow that sets the attribute
Apps, bots and service accounts	App-only access to protected sites is governed by a tenant bypass setting; Teams IB does not support bots or Entra apps sending activity notifications	Inventory of apps with Sites or Files permissions, scoped permissions, owner attestation (see below)
Other systems	Document management, CRM, deal rooms, data platforms and AI assistants have their own permission models	Matter or deal based access groups fed from the same segment source; DLP and classification labels

See the Data Loss Prevention (DLP) Guide and the Microsoft Purview Information Protection Guide for content-level controls that complement a barrier.

Where identity fits

A barrier is an authorisation policy keyed on identity attributes, so its strength is the strength of the identity data and of every identity that can reach the data.

Attribute integrity: whoever can change a department or cost-centre attribute can move a person across the wall. Restrict write access to those attributes to the HR synchronisation path and log every change.
Admin roles: IB policy administration, SharePoint administration and Exchange transport rule administration can each weaken the wall. Hold them in privileged access workflows with approval.
Non-human identities: the SharePoint setting AppBypassInformationBarriers allows app-only apps to access IB-protected sites. An app registration with tenant-wide Sites.Read.All can read both sides of the wall and feed a search index, a reporting tool or an AI assistant that a walled user then queries. Inventory every app with broad file permissions and scope it. See the Microsoft 365 Application Access Policies and RBAC for Applications Guide.
Wall crossing as access change: record approver, reason, start and end, and remove the extra segment automatically at the end date.

Monitoring, surveillance and evidence

Regulators and clients ask two questions: does the wall work, and how would you know if it were breached? Answer both with logs and reviews.

Barrier configuration changes: the Purview audit log records enabling and disabling IB for SharePoint and OneDrive and changes to a site's segment or mode. Alert on any of these outside an approved change. See the Microsoft 365 Unified Audit Log Guide.
Policy application status: run Get-InformationBarrierPoliciesApplicationStatus -All after every change and keep the output.
Communication surveillance: Microsoft Purview Communication Compliance has a "Detect conflict of interest" template that detects communications between two groups or two users, and covers Teams, Exchange, Viva Engage, imported third-party sources such as Instant Bloomberg and Copilot prompts. Its review workflow separates configuring admins from investigators and reviewers.
Attribute changes: alert on department or segment attribute changes for users in sensitive segments that do not match an HR event or an approved wall crossing.
Trading and watch lists: in markets businesses, the barrier log should be reviewable alongside watch list and restricted list surveillance, so that a trade by someone near a deal can be checked against their segment history.

Metrics that show it is working

Percentage of in-scope users with a valid segment attribute (target 100 per cent, reviewed daily).
Number of barrier configuration changes without an approved change record (target zero).
Mean time to close a conflict of interest surveillance alert.
Wall crossings past their end date and still active (target zero).
Apps with tenant-wide file access that have no named owner and attested purpose.
Results of the quarterly cross-wall test across every channel, including email.

Choosing the approach for your organisation

Small firm or single conflict: a single pair of segments, private teams and Explicit sites for the sensitive group, a mail flow rule and a manual quarterly review may be enough. FINRA's limited investment banking exemption still leaves the (b)(2)(G) safeguards in place, so "small" does not mean "none".
Large bank or multi-practice law firm: MultiSegment mode, segments generated from HR data, an automated wall-crossing workflow, communication surveillance on every channel and matter-based access in the document management system.
Block versus allow: block policies are easier to run where most people can talk to most people; allow policies give a tighter guarantee for deal teams but generate more support calls.
Owner Moderated versus Explicit sites: Owner Moderated suits supervised cross-wall collaboration; Explicit suits data that must stay inside one segment.

Framework mapping

Framework	Reference	How the barrier supports it
NIST SP 800-53 Rev 5	AC-4 Information Flow Enforcement	Segment policies enforce approved flows between groups
NIST SP 800-53 Rev 5	AC-5 Separation of Duties; AC-6 Least Privilege	Separation of conflicting functions and minimum access
NIST SP 800-53 Rev 5	AC-21 Information Sharing	Controlled wall crossing and sharing decisions
NIST SP 800-53 Rev 5	AU-6 Audit Record Review, Analysis, and Reporting	Review of barrier changes and surveillance alerts
NIST CSF 2.0	PR.AA-05, GV.OC-03, DE.CM-03	Access permissions with separation of duties; legal duties understood; personnel activity monitored
ISO/IEC 27001:2022 Annex A	A.5.3 Segregation of duties; A.8.3 Information access restriction	Conflicting duties and access restricted by policy
CIS Controls v8.1	3.3 Configure Data Access Control Lists; 6.8 Define and Maintain Role-Based Access Control	Data access and role design underpinning the segments

Common failure patterns

Email left open: teams and sites are walled, but the same two people email each other freely because nobody built the transport rule.
Legacy teams never converted: teams created before IB stay in Open mode, so the oldest and often most sensitive collaboration spaces are uncovered.
Segments from stale groups: segments built on manually maintained groups miss movers, so a banker who transferred to research keeps the old segment for months.
Service identities ignored: an indexing or reporting app with tenant-wide read access re-publishes walled content to everyone. AI assistants grounded on tenant data need the same scrutiny.
Wall crossings never reversed: people brought over for a deal keep both segments indefinitely.
Design changes after go-live: trying to rename segments or flip a block policy to allow after deployment forces a delete and recreate, with disruption that tempts teams to suspend the barrier.

Practitioner checklist

Document each separated pair with its conflict and governing rule.
Source segment attributes from HR and restrict who can write them.
Confirm the IB mode and switch to MultiSegment before creating segments if you need it.
Create policies Inactive, pilot with test segments, then activate in waves.
Enable IB for SharePoint and OneDrive and convert pre-IB teams to Implicit.
Build Exchange mail flow rules for every walled pair.
Inventory and scope apps that can bypass barriers or read tenant-wide files.
Run a conflict of interest surveillance policy and review alerts on a set cadence.
Run a recorded cross-wall test on every channel each quarter.
Expire wall crossings automatically and report any still active past their end date.

Information barriers and ethical walls: design, tooling and monitoring for regulated firms