This chapter covers Information Barriers and Data Loss Prevention (DLP) in Microsoft 365 — two critical compliance technologies that prevent unauthorized communication and data leakage. For the MS-102 exam, these topics appear in Domain 3 (Security Threats) under Objective 3.4, typically accounting for about 5-8% of questions. You will be tested on configuration steps, policy logic, default settings, and how these technologies interact with Microsoft Purview, Teams, SharePoint, and Exchange Online.
Jump to a section
Imagine a large investment bank with two departments: Mergers & Acquisitions (M&A) and Equity Research. The M&A team is working on a secret acquisition of Company X. The Equity Research team is about to publish a report on Company X. If the research team learns of the acquisition, they could tip off traders or publish biased analysis, violating insider trading laws. To prevent this, the bank builds a physical Chinese wall: separate floors, locked doors, separate IT systems, and a compliance officer who monitors all communications. Any attempt by a researcher to email an M&A banker is blocked by the compliance system. If an M&A banker tries to access the research team's file share, they get an access denied message. The wall is enforced by both technical controls (file permissions, email rules) and administrative policies (training, audits). Information Barriers in Microsoft 365 work exactly like this: segments (segments) represent departments, policies define who can communicate with whom, and the system blocks communication at the email, chat, and file-sharing levels. Just as the Chinese wall must be configured before sensitive deals start, Information Barrier policies must be in place before any communication attempt occurs. The compliance officer (administrator) defines the rules, and Microsoft 365 enforces them in real-time, blocking prohibited communications and logging attempts for audit.
What Are Information Barriers?
Information Barriers (IB) are policies in Microsoft Purview that restrict communication and collaboration between specific groups or segments within an organization. They are designed to prevent conflicts of interest, insider trading, and other regulatory violations. IB policies apply to Microsoft Teams, SharePoint Online, OneDrive for Business, and Exchange Online.
Why Information Barriers Exist
Organizations in regulated industries (finance, legal, healthcare) must prevent certain individuals from communicating with each other. For example, a law firm representing two competing clients must ensure that lawyers on one case do not discuss strategy with lawyers on the other. IB policies enforce these restrictions automatically.
How Information Barriers Work
IB policies are based on segments and policy rules: - Segments: Groups of users defined by attributes such as department, job title, or custom attributes. Each user belongs to exactly one segment. - Policies: Define whether communication between two segments is allowed or blocked. Policies are directional: you can block Segment A from communicating with Segment B, but allow the reverse. - Policy types: - Block: Prevents communication between segments. - Allow: Permits communication between segments (used to override broader blocks).
When a user attempts to communicate (e.g., send a chat, share a file, add someone to a team), Microsoft 365 checks the IB policy. If the policy blocks the interaction, the action is prevented and an audit event is logged.
Key Components, Values, and Defaults
Segment attribute: Must be a mailbox property (e.g., Department, CustomAttribute1-15). Default is no segments; you must define them.
Policy priority: Policies are evaluated based on a numerical priority (lower number = higher priority). Default: no policies.
Scope: IB policies apply to:
- Teams (chat, channel, meetings, file sharing) - SharePoint Online (site access, file sharing) - OneDrive for Business (file sharing) - Exchange Online (email) – limited to blocking email between segments. - Timers: IB policies take up to 30 minutes to propagate after creation. Changes to user attributes may take up to 24 hours. - Licensing: IB requires Microsoft 365 E5 or Microsoft 365 E5 Compliance licenses.
Configuration and Verification Commands
To configure IB, you use the Microsoft Purview compliance portal or PowerShell. Example PowerShell commands:
# Install the Exchange Online module
Install-Module -Name ExchangeOnlineManagement
# Connect to Exchange Online
Connect-ExchangeOnline
# Create a segment for 'Research'
New-InformationBarrierSegment -Name "Research" -UserGroupFilter "Department -eq 'Research'"
# Create a segment for 'Trading'
New-InformationBarrierSegment -Name "Trading" -UserGroupFilter "Department -eq 'Trading'"
# Create a block policy: Research cannot communicate with Trading
New-InformationBarrierPolicy -Name "Block Research-Trading" -AssignedSegment "Research" -SegmentsBlocked "Trading" -State Active
# Apply the policy (this triggers the propagation)
Start-InformationBarrierPoliciesApplication
# Verify
Get-InformationBarrierPolicy | Format-List
Get-InformationBarrierSegment | Format-ListHow Information Barriers Interact with Related Technologies
Teams: IB policies block direct chat, channel participation, and meeting invitations. If a user is blocked, they cannot add the blocked user to a chat or team.
SharePoint/OneDrive: IB policies restrict sharing of files and folders. A blocked user cannot access a shared file from the other segment.
Exchange Online: IB policies can block email between segments using mail flow rules (transport rules) that are automatically created.
Microsoft Purview Data Loss Prevention (DLP): IB and DLP are complementary. IB prevents communication between segments; DLP prevents sensitive data from being shared anywhere.
Data Loss Prevention (DLP) in Microsoft 365
DLP policies protect sensitive information by detecting and preventing accidental or inappropriate sharing. DLP can be applied to Exchange Online, SharePoint Online, OneDrive for Business, Teams, and endpoints (Windows 10/11).
How DLP Works
DLP uses sensitive information types (SITs) to detect data like credit card numbers, social security numbers, or custom patterns. When a user tries to share or send data matching a SIT, DLP evaluates the policy rules: - Action: Block the action, notify the user, or allow with audit. - Override: Users can override the block with a business justification (if allowed by policy). - Policy tips: Users see a notification in Outlook, Teams, or SharePoint explaining the restriction.
Key Components, Values, and Defaults
Sensitive Information Types (SITs): Microsoft provides over 200 built-in SITs. You can also create custom SITs using regex or keyword lists.
Actions:
- Block (with option to allow override) - Notify (send email to user or admin) - Report (audit only) - Locations: Exchange, SharePoint, OneDrive, Teams chat and channel messages, devices (endpoint DLP). - Default DLP policy: Microsoft 365 creates a default DLP policy for credit card numbers and bank account numbers, but it is not enforced until activated. - Policy priority: Policies are evaluated in order of priority (lower number = higher priority). The most restrictive action wins. - Timers: DLP policies take effect within 1 hour after creation. Changes to sensitive info types may take up to 24 hours.
Configuration and Verification Commands
You can configure DLP via the Microsoft Purview compliance portal or PowerShell:
# Connect to Security & Compliance Center
Connect-IPPSSession
# Create a DLP policy
New-DlpCompliancePolicy -Name "Finance DLP" -ExchangeLocation All -SharePointLocation All -OneDriveLocation All -TeamsLocation All -Mode Enable
# Add a rule to the policy
New-DlpComplianceRule -Name "Block Credit Cards" -Policy "Finance DLP" -BlockAccess $true -SentTo "finance@contoso.com" -ExceptIfSentTo "audit@contoso.com" -NotifyUser Owner -NotifyUser CustomEmail -CustomEmailSubject "Action Required"DLP and Information Barriers Interaction
IB and DLP are independent but can be used together. IB prevents communication between segments; DLP prevents sensitive data from leaving the organization. For example, an IB policy might block Research from emailing Trading, while a DLP policy blocks any email containing a credit card number to external recipients. Both policies are enforced simultaneously.
Exam-Relevant Details
IB segments are based on user attributes that are synchronized from Azure AD.
IB policies must be applied using Start-InformationBarrierPoliciesApplication.
DLP policy tips appear in Outlook, Teams, and SharePoint.
DLP policies can be set to test mode (with or without policy tips).
Both IB and DLP require appropriate licensing (E5 or E5 Compliance).
Identify Segments and Attributes
First, determine which groups of users need to be isolated. For example, a bank might have segments for 'M&A', 'Research', and 'Trading'. Each segment is defined by a user attribute like 'Department' or a custom attribute. In the Microsoft Purview portal, you define segments using a filter expression (e.g., `Department -eq 'Research'`). The attribute must be a mailbox property that is populated in Azure AD. This step is critical because if the attribute is missing or incorrect, users will not be assigned to the intended segment, and the IB policy will not apply correctly.
Create Information Barrier Policies
After segments are defined, create policies that specify which segments can or cannot communicate. A 'Block' policy prevents communication between two segments. For example, a policy might block 'Research' from communicating with 'Trading'. Policies are directional: you can block one-way. You can also create 'Allow' policies to override broader blocks. Each policy has a priority number; lower numbers are evaluated first. When creating the policy, set the state to 'Active' to enable it immediately. The policy is stored in Azure AD and will be applied to all communications.
Apply Information Barrier Policies
Policies are not active until you run the `Start-InformationBarrierPoliciesApplication` cmdlet. This triggers the propagation of policies to all services (Teams, SharePoint, Exchange). Propagation can take up to 30 minutes. During this time, some users may still be able to communicate. After propagation, any new communication attempt is evaluated. Existing communications (e.g., existing Teams chats) are not automatically broken; users may need to be removed from existing groups manually.
Create DLP Policies and Rules
In the Microsoft Purview portal, navigate to Data Loss Prevention and create a new policy. Choose the locations (Exchange, SharePoint, OneDrive, Teams, Devices). Then define rules that specify the sensitive information types to detect (e.g., credit card numbers), the conditions (e.g., content contains credit card number), and the actions (e.g., block access, notify user). You can set the policy to test mode first to see how many items would be affected without blocking. Rules can have exceptions (e.g., except if sent to a specific domain).
Test and Monitor DLP Policies
After creating DLP policies, monitor their impact using the DLP reports in the Purview portal. Check for false positives and adjust the sensitive info types or conditions accordingly. Use policy tips to inform users about the policy without blocking them initially. In test mode, actions are logged but not enforced. Once satisfied, change the policy mode to 'Enforce'. DLP policies typically take effect within an hour, but changes to sensitive info types may take up to 24 hours. Regularly review audit logs for DLP rule matches.
Enterprise Scenario 1: Investment Bank Chinese Wall
A global investment bank must comply with SEC regulations to prevent insider trading. The bank has three departments: Investment Banking (IB), Research, and Trading. IB is working on confidential M&A deals. Research produces reports that could be influenced by non-public information. Trading executes trades based on research. The bank implements Information Barriers:
Segments: 'IB', 'Research', 'Trading'.
Policies: Block IB from communicating with Research and Trading; Block Research from communicating with Trading.
Additionally, a DLP policy blocks any email containing 'Confidential' or 'Material Non-Public Information' from leaving the bank's domain.
In production, the bank has 10,000 users. The IB segment has 500 users, Research 200, Trading 1,000. The policies are applied globally. When a trader tries to add an IB banker to a Teams chat, they receive an error message. The bank also uses audit logs to detect any attempts to circumvent the barrier. A common issue is that users may belong to the wrong segment if their department attribute is outdated. The bank runs weekly reconciliation scripts to update attributes.
Enterprise Scenario 2: Healthcare Provider Patient Privacy
A large healthcare provider must comply with HIPAA. They have two groups: 'Clinical' (doctors, nurses) and 'Administrative' (billing, HR). Clinical staff must be able to share patient data among themselves, but administrative staff should not have access to protected health information (PHI). The provider uses:
Information Barriers: Block Administrative from communicating with Clinical, but allow Clinical to communicate with Administrative (e.g., for scheduling).
DLP policies: Detect PHI (e.g., patient names + medical record numbers) and block sharing with external recipients. Also block sharing of PHI to personal OneDrive accounts.
In production, the provider has 5,000 users. The DLP policy is set to 'Block with override' so that clinical staff can override for legitimate treatment purposes. The override requires a business justification. Performance is monitored via DLP reports; false positives are common with common names, so the provider customizes the SIT to require two PHI identifiers. Misconfiguration often occurs when users are assigned to multiple segments (not allowed) or when attributes are missing.
Common Pitfalls
Missing attributes: Users not assigned to any segment are invisible to IB policies and can communicate freely. Always verify segment membership.
Policy not applied: Forgetting to run Start-InformationBarrierPoliciesApplication is a common mistake. Policies remain in 'Pending' state until applied.
DLP policy tips ignored: Users may ignore policy tips and continue sharing. Set the policy to block without override for critical data.
Overly broad DLP policies: Catching too many false positives leads to user frustration and policy overrides. Use test mode and fine-tune SITs.
What MS-102 Tests on Information Barriers and DLP
MS-102 objective 3.4 focuses on implementing and managing information protection, including Information Barriers and DLP. Specific areas:
- Information Barriers: Creating segments, creating policies, applying policies, and verifying configuration. You need to know the PowerShell cmdlets (New-InformationBarrierSegment, New-InformationBarrierPolicy, Start-InformationBarrierPoliciesApplication).
- DLP: Creating DLP policies, configuring rules, using sensitive information types, understanding policy tips, and knowing the difference between test mode and enforce mode.
Common Wrong Answers and Why Candidates Choose Them
"Information Barriers apply to all Microsoft 365 services by default." Wrong. IB applies only to Teams, SharePoint, OneDrive, and Exchange. Not to Yammer, Planner, or third-party apps. Candidates assume it's universal.
"DLP policies block all sensitive data automatically." Wrong. DLP policies must be explicitly created and enabled. The default policy is not enforced until you activate it. Candidates think it's automatic.
"You can assign a user to multiple segments." Wrong. Each user can belong to only one segment. Candidates confuse segments with groups.
"Information Barrier policies take effect immediately." Wrong. They take up to 30 minutes after running the application cmdlet. Candidates expect instant enforcement.
Specific Numbers, Values, and Terms
30 minutes: Propagation time for IB policies after Start-InformationBarrierPoliciesApplication.
1 hour: DLP policy activation time after creation.
24 hours: Time for user attribute changes to be reflected in IB segment membership.
Priority: Lower number = higher priority for both IB and DLP policies.
Sensitive Information Types: Over 200 built-in types; custom SITs can be created.
Actions: Block, Notify, Report.
Locations: Exchange, SharePoint, OneDrive, Teams, Devices.
Edge Cases and Exceptions
Existing communications: IB policies do not break existing Teams chats or group memberships. You must manually remove users from groups.
External users: IB policies do not apply to external users (guests) unless they are synchronized into Azure AD.
DLP overrides: If a policy allows override, users can bypass the block by providing a justification. The override is logged.
Mail flow rules: In Exchange, IB policies create underlying mail flow rules that are hidden from the Exchange admin center.
How to Eliminate Wrong Answers
If an answer says "immediately" or "automatically" for IB, it's likely wrong because propagation takes time.
If an answer mentions "all services" for IB, it's wrong because IB is limited to specific workloads.
For DLP, look for keywords like "test mode" vs "enforce". Test mode does not block.
Remember that IB segments are based on user attributes, not groups or distribution lists.
Information Barriers restrict communication between segments; each user belongs to exactly one segment.
IB policies require explicit application via `Start-InformationBarrierPoliciesApplication` and propagate within 30 minutes.
DLP policies detect sensitive data using built-in or custom sensitive information types (SITs).
DLP policies can be set to test mode (no enforcement) or enforce mode (block actions).
Both IB and DLP require Microsoft 365 E5 or E5 Compliance licenses.
IB policies do not retroactively break existing communications; manual cleanup is needed.
DLP policy tips appear in Outlook, Teams, and SharePoint to inform users of policy violations.
IB segments are based on user attributes (e.g., Department) that must be populated in Azure AD.
These come up on the exam all the time. Here's how to tell them apart.
Information Barriers
Restricts communication between specific user segments (e.g., departments).
Uses segments defined by user attributes like Department.
Blocks actions like chat, file sharing, and email between segments.
Requires licensing: Microsoft 365 E5 or E5 Compliance.
Policies must be applied via `Start-InformationBarrierPoliciesApplication`.
Data Loss Prevention (DLP)
Prevents sharing of sensitive data (e.g., credit card numbers, SSN).
Uses sensitive information types (SITs) to detect data patterns.
Blocks or notifies on actions like sending email with sensitive data, sharing files externally.
Requires licensing: Microsoft 365 E5 or E5 Compliance (for advanced features).
Policies take effect within 1 hour; no manual application step.
Mistake
Information Barrier policies apply to all Microsoft 365 workloads.
Correct
IB policies apply only to Microsoft Teams, SharePoint Online, OneDrive for Business, and Exchange Online. They do not apply to Yammer, Planner, or third-party apps.
Mistake
A user can be a member of multiple Information Barrier segments.
Correct
Each user can belong to exactly one segment. If a user's attributes match multiple segment filters, the policy application fails.
Mistake
Information Barrier policies take effect immediately after creation.
Correct
Policies must be applied using `Start-InformationBarrierPoliciesApplication`, and propagation can take up to 30 minutes.
Mistake
DLP policies block sensitive data by default without any configuration.
Correct
No default DLP policy is enforced. You must create and enable DLP policies explicitly. The built-in default policy for credit card numbers is not active until you turn it on.
Mistake
Information Barrier policies automatically remove users from existing Teams chats and groups.
Correct
IB policies do not retroactively break existing communications. Administrators must manually remove users from existing teams or chats.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
After creating the policies, you must run the `Start-InformationBarrierPoliciesApplication` cmdlet in Exchange Online PowerShell. This triggers the propagation of policies to all services. Propagation can take up to 30 minutes. You can check the status using `Get-InformationBarrierPoliciesApplicationStatus`.
No. IB policies only apply between different segments. Users within the same segment can communicate freely. To restrict communication within a segment, you would need to create sub-segments or use other tools like DLP.
The user's segment membership is updated automatically within 24 hours (or sooner if the attribute change triggers a sync). If the user moves to a new segment, the IB policies for that segment apply. However, existing communications from before the change are not broken.
In the Microsoft Purview portal, go to Data Loss Prevention > Classifiers > Sensitive info types > Create. You can define a pattern using regex, keywords, and required confidence levels. For example, a custom SIT for employee IDs might use a regex like `^[A-Z]{3}\d{4}$` with supporting keywords like 'Employee ID'.
In test mode, DLP policies detect and log policy matches but do not block actions. Policy tips may or may not be shown depending on configuration. In enforce mode, the specified actions (e.g., block, notify) are actually applied. Test mode is useful for validating policies before full deployment.
Information Barriers primarily apply to internal users. External users (guests) are not automatically assigned to segments unless they are synchronized into Azure AD. To block external communication, you would use DLP or external sharing controls.
You can check the audit logs in the Microsoft Purview portal for Information Barrier actions (e.g., blocked communication attempts). Additionally, you can attempt to perform a blocked action (like adding a user to a chat) and verify that you receive an error message. Use `Get-InformationBarrierPolicy` to confirm the policy state is 'Active'.
You've just covered Information Barriers and DLP — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?