# Design your segments and barrier policies - URL: https://m365playbooks.com/playbooks/design-your-segments-and-barrier-policies/ - Topic: Information barriers (Program) - Product: Purview, Teams, SharePoint, OneDrive - Stage: Plan - Last reviewed: October 16, 2026 - Version: 1 - Written by: Sev Derghazarian ## 1. Purpose Keep apart the people a rule says must be kept apart, and nobody else. Information barriers stop two groups from finding, chatting with, calling, meeting or sharing files with each other in Teams, SharePoint and OneDrive. That is exactly what a conflict-of-interest rule needs, and exactly what breaks everyday collaboration when it's drawn too wide. Most of the hard decisions can't be changed cheaply later, so they belong here: which rules justify a barrier, which attribute defines the groups, and which mode the organization runs in. ## 2. Overview The rules that justify each barrier, the attribute that defines segments, the organization's mode, and a signed matrix of who can't talk to whom. - Effort: About 8 to 15 person-days - Duration: 4 to 6 weeks - Complexity: High - Who's in the room: Compliance lead (owner), legal, HR or the owner of directory data, Purview admin, Teams admin, SharePoint admin - Beyond E5: Nothing beyond Microsoft 365 E5 - Risk of not doing it: Barriers drawn from an unclear rule or messy directory data cut off people who should be working together, and fixing the design after policies apply removes people from teams and chats a second time. ## 3. Key activities ### Prerequisites 1. **Tie every barrier to a rule and an owner** Information barriers exist to enforce a rule: a regulation, a conflict-of-interest policy, a commitment to a client. Write down each rule, who owns it, and which groups it separates. If nobody can name the rule, it probably isn't a barrier; sharing settings, sensitivity labels or team membership may be enough. Microsoft recommends using the minimum number of policies that meets your requirements, and every barrier you add is one more thing people work around. Who: Compliance lead with legal. Produces: A register of rules, owners and the groups each separates. 2. **Check the organization's mode** Your tenant runs in Legacy, SingleSegment or MultiSegment mode, depending on when information barriers were first enabled. Legacy mode allows 250 segments with one segment per person and relies on Exchange address book policies, which must be removed before you start. The newer modes allow up to 5,000 segments and manage address book policies for you. Check the mode first; several decisions below depend on it. Who: Purview admin. Produces: The mode, recorded in the design. 3. **Choose one attribute and check its quality** Segments are defined from Microsoft Entra attributes; Department, MemberOf, Company and the extension attributes are the most common. Microsoft advises using the same attribute for every segment and keeping segments from overlapping. Whatever you pick, someone must keep it accurate as people join, move and leave, because a blank or wrong value silently puts a person on the wrong side of a barrier. Export the values for everyone in scope now and count what's missing or inconsistent. Who: Owner of directory data with the Purview admin. Produces: The chosen attribute, its owner and a data-quality count. ### Decisions 4. **Decision: One segment per person, or several?** In MultiSegment mode a person can belong to up to 10 segments, which suits people who legitimately span groups, such as compliance staff or teachers across schools. You can only switch to MultiSegment while no segments or policies exist, and Microsoft says not to revert afterwards. So decide before the first segment is created, even if you don't need it yet. Options: Start in single-segment mode and switch later; Choose the mode before the first segment exists. Recommended default: Choose the mode before the first segment exists. Who: Compliance lead with the Purview admin. Produces: The mode to run in, decided before any segment exists. 5. **Decision: Block or allow policies?** A block policy stops one segment from communicating with named segments; an allow policy lets a segment communicate only with the ones it names. Each segment can have one policy, each policy works in one direction (so a barrier between two groups needs two), and a policy's type can't be changed after it's created. Microsoft recommends block policies for most scenarios because they give people a more consistent experience; in MultiSegment mode, define every policy as an allow list. Options: Allow policies everywhere; Block policies for most barriers; allow only where a group may talk to a few named groups. Recommended default: Block policies for most barriers; allow only where a group may talk to a few named groups. Who: Compliance lead. Produces: A policy type for each segment. 6. **Decision: What about email?** Information barriers don't restrict email in Exchange Online. If a rule requires that two groups don't email each other, Microsoft points to Exchange mail flow rules instead, covered in this topic's Go further playbook. Decide per rule, and make sure the rule's owner knows which channels the barrier covers and which it doesn't. Options: Rely on information barriers alone; Add mail flow rules wherever the rule covers email. Recommended default: Add mail flow rules wherever the rule covers email. Who: Compliance lead with the Exchange admin. Produces: An email decision for each rule. 7. **Decision: Who stays unsegmented, and can people see each other?** In the newer modes, people outside any segment stay visible to everyone, so functions like HR or IT can stay unsegmented and keep working across barriers. Decide that deliberately rather than by accident of missing data. By default, blocked people also disappear from the people picker; outside Legacy mode you can turn that restriction off, but keeping it on avoids people trying, and failing, to contact someone. Options: Leave unsegmented whoever has no attribute value; Choose unsegmented functions deliberately and keep the people-picker restriction on. Recommended default: Choose unsegmented functions deliberately and keep the people-picker restriction on. Who: Compliance lead. Produces: A list of unsegmented functions and a people-picker decision. ### Pilot configuration 8. **Draw the barrier matrix** List segments down and across a grid and mark each pair allowed or blocked, then derive the policies from it. Check the matrix against each rule in the register, and against the people who will be licensed for it: users in a policy's assigned segment need a licence that includes information barriers, which Microsoft 365 E5 does. Who: Purview admin with the compliance lead. Produces: A matrix and the list of policies it produces. 9. **Find what the barriers will break** When policies apply, people who can no longer communicate are removed from group chats and teams, and their one-to-one chats become read-only. Existing teams stay in Open mode, with no barrier, until you move them to Implicit, which then removes members who don't fit. Turning on scoped directory search, which barriers require, also hides the team search box and public team listing. List the teams, sites and recurring meetings that span a planned barrier, and who owns them. Who: Teams admin with the SharePoint admin. Produces: An impact list of teams, sites and owners. ### Production configuration 10. **Sign off the design** Ask the rule owners, legal and the owner of directory data to sign the register, the matrix, the mode, the attribute and the email decision together. A signed design is what Prepare tests against and what you'll defend when someone asks why they can't reach a colleague. Who: Compliance lead. Produces: A signed design. 11. **Make it enforceable** Nothing is enforced at this stage. The signed register and matrix become the source for every segment and policy, and any later change starts as a change to them. _Risk: nothing enforces this standard yet. Until something does, treat it as a risk, not as done._ ## 4. Approval and readiness 1. **Gather the rules** Each barrier has a rule, an owner and the groups it separates. Move on when: The register is complete. 2. **Decide mode and attribute** Check the mode, choose the attribute and count data gaps. Move on when: Mode and attribute are agreed. 3. **Draw the matrix** Derive policies and the list of teams and sites they affect. Move on when: Every pair has a decision. 4. **Sign off** (Change: Inform) Rule owners, legal and directory owners sign the design. Move on when: The design is signed. ## 5. Common challenges - **If you** Use barriers where sharing settings would do. What tends to happen: Collaboration breaks across the organization for a risk that a label or a private team would have handled.. A better approach: Require a named rule and owner for every barrier. - **If you** Create the first segment before choosing the mode. What tends to happen: Moving to multi-segment later means removing every segment and policy first.. A better approach: Decide the mode before any segment exists. - **If you** Mix attributes or allow overlaps. What tends to happen: Some people land in two segments, others in none, and the barrier has holes.. A better approach: Use one attribute for every segment and check for overlaps before Prepare. - **If you** Assume barriers cover email. What tends to happen: The rule's owner believes email is separated when it isn't.. A better approach: Decide email per rule and add mail flow rules where needed. - **If you** Forget that policies work in one direction. What tends to happen: One group is blocked; the other can still reach it.. A better approach: Create two policies for every barrier and check them against the matrix. ## 6. Checkpoints **Pilot:** - [ ] Does every barrier trace to a named rule and owner? - [ ] Is the mode decided before any segment exists? - [ ] Is the email decision recorded for each rule? **Production:** - [ ] Is the attribute owned and its gaps counted? - [ ] Is the impact list shared with team and site owners? - [ ] Is the design signed? ## 7. Success measures Capture a baseline before you start, or you won't be able to show the change. - Barriers traced to a named rule and owner (Where you see it: Barrier register; Good direction: Up) - People in scope with a missing or unexpected attribute value (Where you see it: Microsoft Entra user export; Good direction: Down) - Teams and sites that span a planned barrier (Where you see it: Impact list; Good direction: Down) **Ready-to-use text: Barrier register** > Columns: Rule | Owner | Segments it separates | Policy type (block or allow) | Email covered (Y/N, how) | Teams and sites affected | Review date. **Ready-to-use text: Barrier matrix** > Segments down the side and across the top. Mark each cell Allowed or Blocked, then write one policy per segment: Assigned segment | Policy type | Segments named | Rule it enforces. ## 8. Additional reading **Plan:** - [Learn about Information Barriers](https://learn.microsoft.com/en-us/purview/information-barriers) - [Information Barriers attributes](https://learn.microsoft.com/en-us/purview/information-barriers-attributes) - [Use multi-segment support in Information Barriers](https://learn.microsoft.com/en-us/purview/information-barriers-multi-segment) - [Microsoft Purview service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description) **Configure:** - [Get started with Information Barriers](https://learn.microsoft.com/en-us/purview/information-barriers-policies) ## Changelog - Version 1, 2026-10-16, Sev Derghazarian: First version. Facts checked against Microsoft Learn on 2026-10-16.