We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Information barriers
Microsoft Purview information barriers, UAE

Information barriers do not restrict email. If that is what you need, this is the wrong control.

Microsoft states it directly: IB policies cannot restrict communication and collaboration between groups and users in email messages, and mail flow rules are the answer for that. Information barriers cover Teams, SharePoint and OneDrive, and they cover them thoroughly.

Book an information barriers reviewSee what it covers
Microsoft Purview information barriers for UAE organisations
  • Two way onlyOne-directional barriers are not supported
  • Not emailMail flow rules handle that instead
  • 9 Teams actionsBlocked when a policy applies
  • Entra attributesHow segments are defined
What information barriers do

Eight things to establish before you design a single segment.

Information barriers are a strong control with clearly stated boundaries. Two of those boundaries decide whether the product fits your requirement at all, and both are worth knowing before anybody starts defining segments.

What the barrier actually prevents

It restricts two-way communication and collaboration between groups and users in Microsoft Teams, SharePoint and OneDrive. Users who cannot communicate with specific users cannot find, select, chat with or call them, so the restriction is invisible rather than a blocked action.

Two way only, with no exceptions

Microsoft is explicit that only two-way restrictions are supported. A scenario where marketing can communicate with day traders but day traders cannot communicate with marketing is not supported. If your requirement is one-directional, this product does not express it.

Email is not in scope

IB policies cannot restrict communication and collaboration between groups and users in email messages. Microsoft directs organisations needing to define and control email communications to Exchange mail flow rules instead. That single sentence redirects a lot of projects at the right moment.

Nine specific things blocked in Teams

Searching for a user, adding a member to a team, starting a chat, starting a group chat, inviting someone to a meeting, sharing a screen, placing a call, sharing a file, and accessing a file through a sharing link. That last one matters, because links get forwarded.

Four things blocked in SharePoint and OneDrive

Adding a member to a site, accessing site or content, sharing site or content with another user, and searching a site. Together with the Teams coverage, that closes both the conversational and the document paths between two groups that must not collaborate.

Existing conversations can be disrupted

Where users affected by a policy are part of the same team or group chat, they might be removed from those chat sessions and further communication with the group might not be allowed. That is correct behaviour and it is worth communicating before a policy goes live.

Segments come from Entra attributes

Segments are defined using Microsoft Entra attributes, and multi-segment support allows assigning users to multiple segments for complex organisational scenarios. The quality of those attributes therefore determines whether your barriers are accurate, which makes this a directory data project first.

Which IB mode you are in changes the Exchange story

In single and multi-segment modes, address book policy management is automatic with no reliance on existing address book policies. In legacy mode, all existing address book policies must be removed before enabling IB and custom changes are not supported, because IB controls them all.

Two boundaries that decide the fit

One-directional barriers are not supported, and email is not covered.

Both are stated plainly in Microsoft documentation, and between them they redirect a meaningful share of information barrier projects.

  • Information barriers only support two-way communication and collaboration restrictions. Microsoft gives the explicit example: marketing being able to communicate with day traders while day traders cannot communicate with marketing is not supported. Requirements phrased that way need rethinking as a symmetric barrier or a different control.
  • IB policies cannot restrict communication and collaboration in email messages. Only Exchange Online deployments support IB policies at all, and Microsoft directs organisations needing to control email communications to Exchange mail flow rules. Many conflict-of-interest requirements are primarily about email, which changes the design entirely.
  • The two together mean the honest question at the start of an engagement is not how to configure information barriers, it is whether information barriers are the right instrument for the requirement as written. Answering that in week one saves a great deal of rework.
  • Where the requirement is genuinely about Teams, SharePoint and OneDrive collaboration between two symmetric groups, information barriers are an excellent fit and they cover both the conversational and the document paths thoroughly. That is a large and important set of cases.
Ask us whether IB fits your requirement
How we approach it

Four things that decide whether this project succeeds.

Information barrier projects fail in two ways: the product does not fit the requirement, or the directory attributes are not good enough to define segments accurately. Both are visible in week one if somebody looks.

We test the requirement for symmetry first

Only two-way restrictions are supported, and Microsoft gives the explicit unsupported example. Requirements written as one group being able to reach another but not the reverse have to be rewritten as symmetric barriers or addressed with a different control. Discovering that in week six is expensive.

We separate the email requirement immediately

IB policies cannot restrict communication in email messages, and Microsoft points to Exchange mail flow rules for that. Many conflict-of-interest requirements are primarily about email, so splitting the requirement into the part IB handles and the part mail flow rules handle is the first design decision.

We treat this as a directory data project

Segments are defined from Microsoft Entra attributes, so a barrier is only as accurate as the attribute behind it. Establishing which attribute reliably identifies each group, who maintains it and what happens when somebody transfers is most of the work and all of the risk.

We warn people about existing chats before go live

Where affected users are in the same team or group chat, they might be removed from those sessions and further communication may not be allowed. That is the product working correctly, and it generates alarmed tickets when it happens to people who were not told it would.

How an engagement runs

Four phases across roughly six to eight weeks.

Most of the elapsed time is directory attribute work and stakeholder agreement. The configuration itself is fast, and it is unusually consequential when it goes live.
  1. 01
    Week 1

    Test the requirement against what IB can do

    Before anything else, whether the requirement is symmetric and whether it is about email. One-directional barriers are unsupported and email is out of scope, and a requirement failing either test needs a different design rather than a configuration attempt.

    • Requirement documented and tested for symmetry
    • Email component identified and routed to mail flow rules
    • Workloads in scope confirmed as Teams, SharePoint and OneDrive
    • Compliance boundary requirements separated from IB
  2. 02
    Weeks 2 to 3

    Get the directory attributes right

    Segments are defined from Microsoft Entra attributes, so segment accuracy is attribute accuracy. This is where the work is: establishing which attribute reliably identifies each group, how it is maintained, and what happens when somebody moves between groups.

    • Attribute chosen per segment with a maintenance owner
    • Attribute population and accuracy verified
    • Users needing multiple segments identified
    • Unsegmented user population understood
  3. 03
    Weeks 4 to 5

    Design segments and policies with the business

    Segments defined, policies drafted, and the consequences walked through with the affected groups. Existing shared teams and chats identified, since users affected by a policy might be removed from those sessions once it applies.

    • Segments and policies designed and reviewed
    • Existing cross-group teams and chats identified
    • Disruption communicated to affected groups in advance
    • Exchange IB mode confirmed and its implications recorded
  4. 04
    Weeks 6 to 8

    Apply progressively and verify both directions

    Policies applied and then tested from both sides, since the restriction is symmetric and both experiences matter. Planner behaviour verified where it is in use, including that existing plans and assigned tasks remain accessible while subsequent sharing triggers a check.

    • Policies applied and verified from both segments
    • Teams, SharePoint and OneDrive behaviour confirmed
    • Planner people picker behaviour confirmed if in use
    • Support guidance issued for the expected questions
Where this applies

Six situations information barriers were built for.

Microsoft publishes example scenarios, and they cluster around regulated separation, professional conflicts of interest and safeguarding.

A financial firm separating trading and advisory

The canonical case, and Microsoft uses it as its own example: users in a day trader group unable to communicate or share files with a marketing team, and a SharePoint site for that group inaccessible to anyone outside it. Symmetric by nature, which fits the product exactly.

A law firm with clients on opposing sides

Microsoft names this scenario: a lawyer data obtained from one client cannot be accessed by a lawyer at the same firm representing a different client. The document side matters as much as the conversational side here, and both are covered.

A school district separating cohorts

Another published scenario: instructors in one school unable to communicate or share files with students in another school in the same district. Safeguarding requirements of this shape are typically symmetric, which makes them a clean fit.

An organisation protecting a confidential project

Finance personnel working on confidential company information kept separate from certain internal groups, or an internal team with trade secret material unable to call or chat with specific groups. The invisibility rather than blocking is what makes this workable day to day.

A team engaging with a specific customer

Microsoft lists a scenario where a group of people in a company can only chat with a client or specific customer via guest access during a customer engagement. Restricting outward as well as inward is what makes that containment real rather than procedural.

A public sector body limiting cross-departmental access

Government information access and control limited across departments and groups is another published scenario. These cases usually involve multiple segments and users who belong to more than one, which is precisely what multi-segment support exists for.

Three approaches

How UAE organisations separate groups that must not collaborate.

The right column is the most common starting point and the least defensible, because a policy document does not prevent anything and leaves no evidence that it was followed.
Teams communication prevented
Information barriersYes
Separate tenantsYes
Policy and trustNo
SharePoint and OneDrive sharing prevented
Information barriersYes
Separate tenantsYes
Policy and trustNo
Email restricted
Information barriersNo, use mail flow rules
Separate tenantsYes
Policy and trustNo
One-directional barriers possible
Information barriersNo
Separate tenantsNo
Policy and trustNominally
Restricted users are invisible
Information barriersYes
Separate tenantsYes
Policy and trustNo
Users can be in multiple groups
Information barriersMulti-segment support
Separate tenantsNo
Policy and trustNot applicable
Administrative overhead
Information barriersModerate
Separate tenantsHigh
Policy and trustNone
Collaboration elsewhere preserved
Information barriersYes
Separate tenantsNo
Policy and trustYes
Enforced rather than expected
Information barriersYes
Separate tenantsYes
Policy and trustNo
Depends on directory attribute quality
Information barriersEntirely
Separate tenantsNo
Policy and trustNot applicable
Feature
Information barriers
Separate tenants
Policy and trust
Teams communication prevented
YesYesNo
SharePoint and OneDrive sharing prevented
YesYesNo
Email restricted
No, use mail flow rulesYesNo
One-directional barriers possible
NoNoNominally
Restricted users are invisible
YesYesNo
Users can be in multiple groups
Multi-segment supportNoNot applicable
Administrative overhead
ModerateHighNone
Collaboration elsewhere preserved
YesNoYes
Enforced rather than expected
YesYesNo
Depends on directory attribute quality
EntirelyNoNot applicable
Coverage by workload

What information barriers block, and where.

The coverage in the supported workloads is comprehensive. The gaps are equally clear, and knowing both is what makes the design defensible.
ActionBlocked by information barriers
Searching for a user in TeamsYes
Starting a chat, group chat or callYes
Inviting to a meeting or sharing a screenYes
Sharing a file, or opening one via a sharing linkYes
Adding a member to a team or a SharePoint siteYes
Accessing or searching a SharePoint siteYes
Sharing a Planner plan or assigning a taskYes, on subsequent actions after a policy change
Seeing restricted users in the Planner people pickerConfigurable, search restrictions can be enabled or disabled
Sending an email messageNo, use Exchange mail flow rules
One-directional restrictionNot supported at all
How an engagement runs

Five steps, and the first is a fit test rather than a design step.

Establishing whether information barriers can express the requirement is a fast, cheap question with a large consequence, so it comes before anything else.
  1. 1

    Test the requirement against the product boundaries

    Whether the restriction is symmetric, since one-directional barriers are not supported, and whether it concerns email, since IB policies cannot restrict email and mail flow rules are the alternative. Also whether it is actually an eDiscovery compliance boundary, which is independent of IB.

  2. 2

    Establish the directory attributes behind the segments

    Segments are defined using Microsoft Entra attributes, so a segment is only as accurate as its attribute. Which attribute identifies each group, how well populated it is, who maintains it, and how transfers between groups are handled.

  3. 3

    Design segments and policies with the business owner

    This is a compliance requirement expressed technically, so the business owner reviews the design rather than receiving it. Users needing membership of multiple segments identified, since multi-segment support exists for exactly those complex cases.

  4. 4

    Map the disruption and communicate before applying

    Existing cross-group teams and chats identified, because affected users might be removed from those sessions once a policy applies. Planner behaviour explained where it is used, since existing plans and assigned tasks remain accessible while subsequent sharing triggers a check.

  5. 5

    Apply progressively and verify from both sides

    Because the restriction is symmetric, both experiences need testing. Search, chat, calling, file sharing and sharing link access in Teams, plus site access, membership, sharing and search in SharePoint and OneDrive, verified from each segment rather than from an administrator account.

Straight answers

What organisations ask about information barriers.

No. Microsoft states IB policies cannot restrict communication and collaboration between groups and users in email messages, and directs organisations needing to control email communications to Exchange mail flow rules instead. Only Exchange Online deployments support IB policies at all.

No. Information barriers only support two-way restrictions. Microsoft gives the explicit unsupported example of marketing being able to communicate and collaborate with day traders while day traders cannot do the same with marketing. If your requirement is one-way, it needs a different design.

Microsoft Teams, SharePoint and OneDrive, with Microsoft Planner supporting the restrictions as well. In Teams the coverage extends to searching for a user, chats, group chats, calls, meeting invitations, screen sharing, file sharing and accessing a file through a sharing link.

Nothing, which is the point. Users who cannot communicate or share files with specific users cannot find, select, chat with or call those users. The restriction manifests as absence rather than as a blocked action, which avoids drawing attention to the barrier itself.

They can be disrupted. Where users affected by a policy are part of the same team or group chat, they might be removed from those chat sessions and further communication with the group might not be allowed. Communicating that before a policy applies avoids a difficult morning.

Using Microsoft Entra attributes. That makes segment accuracy a function of directory data quality, which is why an information barriers project is usually a directory attributes project first. Multi-segment support allows assigning users to multiple segments for complex organisational scenarios.

IB policies detect and prevent adding a member to a site, accessing site or content by a user, sharing site or content with another user, and searching a site. That covers both the access and the discovery paths, which matters because search results are a common leak.

Yes, with conditions. Support is available only for basic plans in Planner Web and Planner in Teams on web, desktop and mobile. Administrators can enable or disable search restrictions in the people picker, so users do not see people from segments they are restricted from.

Users can still access existing plans shared with them or tasks already assigned to them. For any subsequent plan sharing or task assignment, an IB policy check is triggered and collaboration is permitted or restricted as the policy defines. So it applies forward rather than retroactively there.

It depends on your IB mode. In single and multi-segment modes, address book policy management is automatic with no reliance on existing policies, and the system creates one with empty address lists for unsegmented users. In legacy mode, all existing address book policies must be removed first.

In single and multi-segment modes, yes, and Microsoft advises keeping them consistent with your IB segments to avoid user visibility differences. In legacy mode, custom changes are not supported because IB controls all address book policies.

No, and Microsoft says so explicitly. IB policies are independent from compliance boundaries for eDiscovery investigations, which control the user content locations that eDiscovery managers can search. Organisations frequently need both, and they are configured separately.

That is the normal case, and splitting it is the right answer. Information barriers handle the Teams, SharePoint and OneDrive collaboration part, and Exchange mail flow rules handle the email part. Designing them together, as one requirement expressed through two controls, produces a coherent result.

Typically six to eight weeks, and most of that is directory attribute work and business agreement rather than configuration. Where the attributes that identify each group are already accurate and maintained, it is considerably faster. Where they are not, that is the project.

We scope by the number of segments and how much directory attribute remediation is needed. The free first step is the fit test: is the requirement symmetric, and does it involve email. Two questions, and they determine whether this is the right control before anybody designs anything.

Yes. Multi-segment support exists for complex organisational scenarios where a user legitimately belongs to more than one group. It is worth identifying those people early, because they are usually the cases that break a segment design built on the assumption of one attribute value per person.

It depends on your IB mode. In legacy mode, IB policies rely on Exchange Online address book policies and the structure and behaviour of the global address list changes to comply as you add policies. In single and multi-segment modes, IB no longer relies on address book policies.

In single and multi-segment modes, if users do not have an address book policy defined with associated IB segments and policies, the system automatically creates one with empty address lists for them, and you can change those as needed. The hierarchical address book remains available to users outside a segment.

It is the Microsoft 365 implementation of that idea, expressed through segments and policies rather than through mailbox rules. The important difference from most legacy ethical wall products is that it covers collaboration and discovery in Teams, SharePoint and OneDrive rather than email.

By how much shared working the two groups need. Separate tenants restrict everything including email and remove all incidental collaboration. Information barriers separate two groups precisely while leaving both able to work normally with everybody else, which is usually what a conflict of interest requirement actually needs.
Fit assessment

Fifteen questions to answer before designing anything.

The first group determines whether information barriers are the right control. Answering those five honestly is worth more than any amount of configuration planning.

Fit

  • Is the requirement symmetric?
    One-way is not supported.
  • Does it involve email?
    IB does not cover email.
  • Is it about Teams, SharePoint or OneDrive?
    Those are the covered workloads.
  • Is this actually an eDiscovery boundary need?
    Those are independent of IB.
  • Who owns the requirement in the business?
    Usually compliance, not IT.

Directory

  • Which Entra attribute identifies each group?
    Segments are built from these.
  • Is that attribute accurate and maintained?
    Segment accuracy depends on it.
  • Who updates it when somebody moves?
    Name them.
  • Do any users belong to multiple segments?
    Multi-segment support exists.
  • What happens to unsegmented users?
    They are treated differently.

Impact

  • Are there existing cross-group teams?
    Members may be removed.
  • Are there existing group chats?
    Same consideration.
  • Do we use Planner?
    It supports IB with conditions.
  • Which IB mode are we in?
    It changes the Exchange story.
  • Have affected groups been told?
    Before, not after.
Related reading

The pages around this one.

Communication compliance

Monitoring communications rather than preventing them.

Learn more

Microsoft Purview eDiscovery

Compliance boundaries, which are independent of information barriers.

Learn more

Sensitivity labels

Protecting the content itself rather than the relationship.

Learn more
Next step

Ask two questions about your requirement: is it symmetric, and does it involve email?

One-directional barriers are not supported and email is not covered. Those two answers determine whether information barriers are the right control, before anybody designs a segment.

Book an information barriers reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Communication Compliance

Message review with pseudonymised usernames

Learn more

Purview eDiscovery

Holds, review sets and the runbook that no longer matches the portal

Learn more

Sensitivity Labels

Classification that travels with the file, and governs what Copilot sees

Learn more

Insider Risk Management

Data theft by departing staff, detected with users pseudonymised

Learn more

Microsoft Purview

Data governance and compliance solutions

Learn more

Data Lifecycle Management

Retention policies, labels and defensible deletion

Learn more

Compliance as a Service

Keeping the position true between assessments

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy