Information Barriers in Microsoft Teams

Microsoft Purview Information Barriers (IBs) are policies that an admin can set up to prevent individuals or groups from communicating with each other. IBs are useful if, for example, one department handles information that shouldn't be shared with other departments. IBs are also useful when a group needs to be isolated or prevented from communicating with anyone outside of that group. Shared channels in Microsoft Teams are supported by Information Barriers. Depending on the type of sharing, Information Barriers policies might restrict sharing in certain ways. For more information about shared channels and Information Barriers behavior, see Information Barriers and shared channels.

For Microsoft Teams, Information Barriers can determine and prevent the following kinds of unauthorized collaborations:

• Adding a user to a team or channel
• User access to team or channel content
• User access to 1:1 and group chats
• User access to meetings
• Prevents lookups and discovery, users aren't visible in the people picker.

Background

The financial services industry primarily drives the need for IBs. The Financial Industry Regulatory Authority (FINRA) reviews IBs and conflicts of interest within member firms and provides guidance about managing such conflicts (FINRA 2241), Debt Research Regulatory Notice 15-31.

However, many other industries find IBs useful. Other common scenarios include:

• Education: Students in one school can't look up contact details for students of other schools.
• Legal: Maintaining the confidentiality of data that a lawyer obtains from one client and preventing it from being accessed by a lawyer for the same firm who represents a different client.
• Government: Information access and control are limited across departments and groups.
• Professional services: A group of people in a company can only chat with a client or a specific customer via guest access during a customer engagement.

For example, Enrico belongs to the Banking segment and Pradeep belongs to the Financial advisor segment. Enrico and Pradeep can't communicate with each other because the organization's IB policy blocks communication and collaboration between these two segments. However, Enrico and Pradeep can communicate with Lee in HR.

When to use Information Barriers

Use IBs in situations like these:

• You need to prevent a team from communicating or sharing data with a specific other team.
• You need to prevent a team from communicating or sharing data with anyone outside of the team.

The Information Barrier Policy Evaluation Service determines whether a communication complies with IB policies.

Managing Information Barriers segments

Manage IB segments in the Microsoft Purview portal or by using PowerShell cmdlets. For more information, see Step 2: Segment users in your organization.

Managing Information Barriers policies

Manage IB policies in the Microsoft Purview portal or by using PowerShell cmdlets. For more information, see Step 3: Create IB policies.

Information Barriers administrator role

The IB Compliance Management role is responsible for managing IB policies. For more information about this role, see Permissions in the Microsoft Purview portal.

Information barrier triggers

IB policies activate when the following Teams events take place:

• Members are added to a team: Whenever you add a user to a team, the system evaluates the user's policy against the IB policies of other team members. After the user is successfully added, the user can perform all functions in the team without further checks. If the user's policy blocks them from being added to the team, the user doesn't show up in search.

  

• A new chat is requested: Each time that a user requests a new chat with one or more other users, the system evaluates the chat to make sure that it isn't violating any IB policies. If the conversation violates an IB policy, the conversation isn't started.

  Here's an example of a 1:1 chat.

  

  Here's an example of a group chat.

  

• A user is invited to join a meeting: When a user is invited to join a meeting, the system evaluates the IB policy that applies to the user against the IB policies that apply to the other team members. If there's a violation, the user isn't allowed to join the meeting.

  

• A screen is shared between two or more users: When a user shares a screen with other users, the system evaluates the sharing to make sure that it doesn't violate the IB policies of other users. If an IB policy is violated, the screen share isn't allowed.

  Here's an example of screen share before the policy is applied.

  

  Here's an example of screen share after the policy is applied. The screen share and call icons aren't visible.

  

• A user places a phone call in Teams: Whenever a user initiates a voice call (via VOIP) to another user or group of users, the system evaluates the call to make sure that it doesn't violate the IB policies of other team members. If there's any violation, the voice call is blocked.

• Guests in Teams: IB policies apply to guests in Teams, too. If guests need to be discoverable in your organization's global address list, see Manage guest access in Microsoft 365 Groups. Once guests are discoverable, you can define IB policies.

How policy changes impact existing chats

When the IB policy administrator changes a policy or activates a policy change because of a change to a user's profile (such as for a job change), the Information Barrier Policy Evaluation Service automatically searches the members to ensure that their membership in the team doesn't violate any policies.

If users have an existing chat or other communication, and you set a new policy or change an existing policy, the service evaluates existing communications to make sure that the communications are still allowed to occur.

• 1:1 chat: If communication between two users is no longer allowed (because of application to one or both users of a policy that blocks communication), the service blocks further communication. Their existing chat conversations become read-only.

  Here's an example that shows the chat is visible.

  

  Here's an example that shows the chat is disabled.

  

• Group chat: If communication from one user to a group is no longer allowed (for example, because a user changed jobs), the service removes the user, along with the other users whose participation violates the policy, from group chat, and blocks further communication with the group. The user can still see old conversations, but can't see or participate in any new conversations with the group. If the new or changed policy that prevents communication is applied to more than one user, the service removes the users who are affected by the policy from group chat. They can still see old conversations.

  In this example, Enrico moves to a different department within the organization and is removed from the group chat.

  

  Enrico can no longer send messages to the group chat.

  

• Team: The service removes any users who are removed from the group from the team and they can't see or participate in existing or new conversations.

Scenario: A user in an existing chat becomes blocked

Currently, users experience the following scenarios if an IB policy blocks another user:

• People tab: A user can't see blocked users on the People tab.

• People Picker: Blocked users won't be visible in the people picker.

  

• Activity tab: If a user visits the Activity tab of a blocked user, no posts appear. (The Activity tab displays channel posts only, and there would be no common channels between the two users.)

  Here's an example of the activity tab view that is blocked.

  

• Org charts: If a user accesses an org chart on which a blocked user appears, the blocked user won't appear on the org chart. Instead, an error message appears.

• People card: If a user participates in a conversation and the user is later blocked, other users see an error message instead of the people card when they hover over the blocked user's name. Actions listed on the card (such as calling and chat) are unavailable.

• Suggested contacts: Blocked users don't appear on the suggested contacts list (the initial contact list that appears for new users).

• Chat contacts: A user can see blocked users on the chats contact list, but the blocked users are identified. The only action that the user can perform on the blocked users is to delete them. The user can also select them to view their past conversation.

• Calls contacts: A user can see blocked users on the calls contact list, but the blocked users are identified. The only action that the user can perform on the blocked users is to delete them.

  Here's an example of a blocked user in the calls contact list.

  

• Skype to Teams migration: During a migration from Skype for Business to Teams, all users-even those users who are blocked by IB policies-are migrated to Teams. Those users are then handled as described previously.

  Here's an example of a blocked user in the calls contact list.

  

  Here's an example of the chat being disabled for a user on the calls content list.

  

• Skype to Teams migration: During a migration from Skype for Business to Teams, all users—even those users who are blocked by IB policies—are migrated to Teams. Those users are then handled as described previously.

Teams policies and SharePoint sites

When you create a team, you also create and associate a SharePoint site with Microsoft Teams for the files experience. Information barrier policies don't apply to this SharePoint site and its files by default. To enable Information Barriers in SharePoint and OneDrive, follow the guidance and steps in the Use Information Barriers with SharePoint article.

Information barrier modes and Teams

Information barrier modes help control who can be added to or removed from a Team. When you use Information Barriers with Teams, the following IB modes are supported:

• Open: This configuration is the default IB mode for all existing groups that were provisioned before Information Barriers were enabled. In this mode, there are no IB policies applicable.
• Implicit: This configuration is the default IB mode when a Team is provisioned after enabling Information Barriers. Implicit mode allows you to add all compatible users in the group.
• Owner Moderated: This mode is set on a team when you want to allow collaboration between incompatible segment users that are moderated by the owner. The team owner can add new members per their IB policy.

Teams created before activating an information barrier policy in your tenant are automatically set to Open mode by default. When you activate IB policies on your tenant, you must update mode of your existing teams to Implicit to ensure that existing teams are IB-compliant. For more information about updating modes, see Change Information Barriers modes with a PowerShell script.

Use the Set-UnifiedGroup cmdlet with the InformationBarrierMode parameter that corresponds to the mode you want to use for your segments. Allowed list of values for the InformationBarrierMode parameter are Open, Implicit, and Owner Moderated.

For example, to configure the Implicit mode for a Microsoft 365 Group, use the following PowerShell command:

Set-UnifiedGroup -InformationBarrierMode Implicit

To update the mode from Open to Implicit for all existing teams, use this PowerShell script.

If you change the Open mode configuration on existing Teams-connected groups to meet compliance requirements for your organization, you need to update the IB modes for associated SharePoint sites connected to the Teams team.

IB policy application in Teams

The IB policy application is a background IB processor for Teams that gets a notification when there are changes to either users (policy or segment changes) or groups (mode changes). The following steps outline the processing flow:

• The policy application receives a group change notification when mode is updated and retrieves the message thread and Group IDs applicable to the update.
• If the message thread exists, the application schedules processing and fetches all members from the team. It sends the underlying group and members to downstream Teams components for IB evaluation.
• The application evaluates the mode on the group and the IB policies per user and sends the results to the policy application.
• The policy application removes the non-compliant users from the group and team.

Required licenses and permissions

For more information on licenses and permissions, plans, and pricing, see the subscription requirements for Information Barriers.

Usage notes

• Users can't join any scheduled meetings: If IB policies are enabled, users can't join meetings if the meeting chat roster reaches its current limit of 1,000 users. IB checks rely on whether a user can be added to the meeting chat roster - only users who can be added are allowed to join the meeting. Every meeting in an IB-enabled tenant performs IB checks at the point of entry, even if the meeting organizer isn't explicitly covered by IB policies.

  Teams also enforces a separate meeting limit of 1,000 users. If overflow is enabled, additional participants can join as view-only attendees. View-only participants aren't subject to IB policy checks. If you invite a large audience (for example, more than 1,000 users), Teams pre-adds 750 users to the meeting chat before the meeting starts. This reserves room for about 250 additional users who actually join the meeting. Because pre-added users count toward the chat roster limit even if they never join the meeting, the chat roster can reach capacity before the meeting attendance limit is met. For recurring meetings, the roster can fill quickly, as any user who joins once remains on the roster for future occurrences. Once the 1,000-user chat roster limit is reached, no additional users can be added to the meeting.

  A short-term solution is to remove inactive members from the meeting chat roster to make space for new users or keep the chat disabled until the meeting begins and enable it only when needed. This helps align the chat participant count more closely with the meeting participant count. Regular Teams meetings work best for audiences of fewer than 1,000 expected attendees. For larger audiences, use Teams Town hall for a smoother experience.

• Users can't join channel meetings: If IB policies are enabled, users can't join channel meetings if they're not a member of the team. The root cause is that IB checks rely on whether users can be added to a meeting chat roster, and only when they can be added to the roster are they allowed to join the meeting. The chat thread in a channel meeting is available to Team/Channel members only, and non-members can't see or access the chat thread. If IB is enabled for the organization and a non-team member attempts to join a channel meeting, that user isn't allowed to join the meeting. However, if IB isn't enabled for the organization and a nonteam member attempts to join a channel meeting, the user is allowed to join the meeting but they won't see the chat option in the meeting.

• IB policies don't work for federated users: If you allow federation with external organizations, the users of those organizations aren't restricted by IB policies. If users of your organization join a chat or meeting organized by external federated users, then IB policies also won't restrict communication between users of your organization.

More information

• To learn more about IBs, see Information Barriers.
• To set up IB policies, see Get started with Information Barriers.
• To edit or remove IB policies, see Manage information barrier policies.
• Information Barriers and shared channels

Availability

Information Barriers in Teams is available in the public, GCC, GCC - High, and DOD clouds.