Microsoft Teams DLP: Setup Guide for Chat and Channels

Data loss prevention (DLP) in Microsoft Teams scans chat and channel messages for sensitive content and blocks or restricts what matches your rules. Most teams get the licensing right and the rule logic right, then still find the policy doesn’t fire, usually because of how it’s scoped, not what it looks for.

Quick fix: A Teams DLP policy scoped to individual user accounts protects 1:1 and group chats — but not standard, private, or shared channel messages. Scope the policy to a security group, distribution group, or Microsoft 365 group instead, and confirm your licensing: chat and channel protection requires an E5-tier plan (Office 365 or Microsoft 365 E5/A5/G5, or the equivalent Information Protection and Governance / Compliance add-ons). Microsoft 365 E3 only covers files shared through Teams, via SharePoint and OneDrive.

Message-level controls matter more as AI tools spread through the workplace: in Microsoft’s 2026 Data Security Index, 32% of surveyed organizations’ data security incidents involved the use of generative AI tools. That’s not a Teams-DLP-specific figure, but it’s the backdrop for why chat and channel content deserves the same scrutiny as files.

What does Teams DLP actually protect, and what doesn’t it?

Per Microsoft’s documentation on DLP and Microsoft Teams, “DLP protections are applied to the actual messages in the chat or channel thread.” What that protection actually reaches depends entirely on how the policy is scoped:

Policy scope	Teams entities	DLP protection
Individual user accounts	1:1 and group chats	Yes
Individual user accounts	Standard, private, and shared channel messages	No
Security groups, distribution groups, or non-mail-enabled security groups	1:1 and group chats	Yes
Security groups, distribution groups, or non-mail-enabled security groups	Standard, private, and shared channel messages	Yes
Microsoft 365 groups	1:1 and group chats	Yes
Microsoft 365 groups	Standard, private, and shared channel messages	Yes

The pattern is simple: scope to a group of any kind and you get full coverage across chats and channels, including private channel messages. Scope to individual users and channel messages fall outside the policy silently, with no warning that coverage is partial. If you inherited a policy that lists specific people rather than a group, that’s the first thing to check.

Files shared inside Teams are a separate story: because Teams stores files in SharePoint and OneDrive, file protection comes from including those locations in your policy, not the Teams location itself.

Licensing: what does E3 get you, and what needs E5?

Office 365 and Microsoft 365 E3 include DLP protection for SharePoint, OneDrive, and Exchange, which also covers files shared through Teams, since Teams relies on SharePoint and OneDrive for file storage. What E3 does not include is protection for the chat and channel messages themselves.

Per Microsoft’s Teams DLP licensing guidance: “Support for DLP protection in Teams Chat requires an E5 license.” Full Teams chat and channel coverage, including private channel messages, is available for:

• Office 365 E5 / A5 / G5
• Microsoft 365 E5 / A5 / G5
• Microsoft 365 E5 / A5 / G5 Information Protection and Governance
• Microsoft 365 E5 / A5 / G5 / F5 Compliance and F5 Security & Compliance

Even with the right SKU, the Microsoft Communications DLP service plan has to be turned on under the license in the Microsoft 365 admin center, per the Purview service description. That’s an enablement step, not just an entitlement. If your organization is on a mix of tiers, our Microsoft 365 vs. Office 365 comparison is a useful starting point for confirming which plan a given user is actually on before you promise them chat-level protection.

Before you start: permissions in the Purview portal

DLP for Teams is configured in the Microsoft Purview portal at purview.microsoft.com, the successor to what was known as the Microsoft Purview compliance portal. Access is managed through Purview’s unified role-based access control model, under Settings > Roles and scopes. The roles relevant to DLP are:

• Compliance Administrator
• Compliance Data Administrator
• Security Administrator
• Global Administrator

One gotcha worth knowing before you troubleshoot a “why can’t I see this policy” ticket: if a user holds both a Microsoft Entra role and a scoped Purview role-group assignment, the Entra role takes precedence, access becomes unscoped, and any administrative-unit scoping you configured is bypassed.

Most tenants also get a default Teams DLP policy, auto-created for first-time Purview customers to track credit card numbers organization-wide. It generates an alert and a low-severity admin email, but no end-user policy tip. Editing or deleting it specifically requires the DLP Compliance Management role, separate from the general roles above, which is a common reason an otherwise-privileged admin can’t touch it.

How do you set up a Teams DLP policy?

Policies live under Data loss prevention > Policies in the Purview portal, where an existing policy is opened for editing via the pencil icon (Edit policy). When you build one for Teams:

1. Scope it to a group, not individual users. As covered above, this determines whether channel messages are protected at all: use a security group, distribution group, or Microsoft 365 group.
2. Add the Teams location, and include SharePoint and OneDrive alongside it if you also want file-sharing protection.
3. Define the conditions and action (see the next section: Teams supports one action type, and label-based conditions aren’t available here).
4. Run it in simulation before enforcing it, covered below.

For the full policy-creation wizard, Microsoft’s walkthrough for creating and deploying a DLP policy covers the click path in more depth. Once a policy is created or edited, allow approximately one hour for the change to work its way through the datacenter and sync to user accounts, and plan rollouts with that lag in mind rather than expecting it to be instant.

What conditions and actions are available for the Teams location?

Per Microsoft’s DLP policy reference, the Teams location supports a narrower set of building blocks than SharePoint or Exchange. Supported conditions include:

• Content contains (sensitive information types or trainable classifiers)
• Insider risk level for Adaptive Protection
• Content is shared from Microsoft 365
• Recipient domain is / Sender domain is
• Recipient is / Sender is

Sensitivity labels and retention labels are not supported conditions for the Teams location — if your policy depends on a label being applied, it won’t work here, no matter how well the label is configured elsewhere in your tenant.

On the action side, Teams supports exactly one action type: Restrict access or encrypt the content in Microsoft 365 locations, with an option to block only people outside your organization. User notifications and policy tips are configured separately, under the rule’s notification settings, rather than as an alternative action.

When content matches more than one rule, Microsoft applies the first-created rule with the most restrictive action — but every match is still logged, even the ones that don’t end up driving the enforced action. If two policies seem to be fighting each other, check creation order and action severity before assuming something is broken.

Adaptive Protection adds a condition — “Insider risk level for Adaptive Protection is” (Elevated, Moderate, or Minor) — driven by Insider Risk Management scoring, and it’s supported for Exchange, Teams, and Devices. Treat it as one more condition you can layer into a rule rather than a separate DLP system.

How do you test a policy before rollout?

Simulation mode has replaced the older Test and Test-with-tips modes. A simulation run:

• Runs for up to 15 days
• Keeps results for 30 days
• Reports in its own Simulation dashboard (Overview, Items for review, Alerts), separate from your production DLP alerts, so simulated matches don’t pollute real reporting
• Has an optional “Show policy tips while in simulation mode” checkbox, if you want users to see what would have happened

Give the policy the full simulation window rather than a quick spot-check: a day or two of chat volume rarely represents how a channel behaves over a normal working cycle.

What happens with guests, external users, and shared channels?

Shared channels are built on Microsoft Entra B2B direct connect, and each participant stays signed in to their own home tenant. Because DLP evaluation is driven by the sender’s identity, each person’s messages are evaluated against their own tenant’s DLP policies — not the policies of the tenant that owns the shared channel. Microsoft’s example is direct: one organization “can’t enforce its DLP policies on [another organization’s] users’ messages, and vice versa.”

External access chats work slightly differently: enforcement is based on the hosting tenant: whichever tenant initiated the chat or thread. A user’s home-tenant DLP policies don’t automatically follow them into a conversation hosted by someone else’s tenant.

If your policy is configured to prevent sharing sensitive information with guests, matching messages sent to external users are deleted, but only when your tenant is the one that initiated the chat or thread. And as noted earlier, documents shared inside Teams are only protected if your policy includes the SharePoint and OneDrive locations alongside Teams.

How does DLP interact with Copilot and the Teams Channel Agent?

Restricting Microsoft 365 Copilot from processing sensitive files and emails, treated as DLP for a distinct Copilot location, requires an M365 or O365 E5/A5 plan, the Purview Suite, or Information Protection & Governance; it isn’t available on Business or E3/F tiers. Separately, “Safeguard prompts” DLP is available to all Copilot and Copilot Chat users regardless of plan.

Conversations with the Teams Channel Agent are scanned by DLP the same way other Teams content is. One explicit limitation: Insider Risk Management is not supported for Channel Agent AI interactions, so the Adaptive Protection condition described above won’t apply there.

How do you monitor, get alerts, and report on DLP activity?

DLP for Teams doesn’t send the user notification emails you’d see with Exchange, SharePoint, or OneDrive DLP. Instead, users get message flags: when a message matches a policy, its preview is hidden and replaced with “Preview Unavailable,” and the sender sees an activity entry reading “Your message has been blocked.” Senders can be allowed to override a policy if you configure that, and policy tips themselves are customizable.

For reporting (per Microsoft’s overview of learning about DLP):

• The DLP alerts dashboard in Purview retains 30 days of alerts.
• The Microsoft Defender portal retains 6 months of history for longer-range analysis.
• For scripted or bulk reporting, Security & Compliance PowerShell exposes Get-DlpDetailReport, Get-DlpDetectionsReport, Get-DlpSiDetectionsReport, and Get-MailDetailDlpPolicyReport.

Troubleshooting the common failures

Most “DLP isn’t working” reports trace back to one of a small number of causes:

• Scope, not rules. As covered above, individual-user scoping is the single most common reason channel messages slip through. Check the policy’s included groups before touching the rule logic.
• Missing locations for files. Teams files are protected through the SharePoint and OneDrive locations, not the Teams location; if a policy only covers Teams, shared files won’t be covered.
• A condition that can’t exist here. Sensitivity or retention labels as a condition simply don’t apply to the Teams location; rebuild the rule around content matching or domain/recipient conditions instead.
• Permissions, not policy. If an admin can edit some policies but not the default one, check for the DLP Compliance Management role; if scoping looks wrong for someone with a Purview role, check whether an Entra role is overriding it.
• Scope limits you can’t fix with DLP. DLP is a content-detection control. It doesn’t fix oversharing caused by permissions, and it doesn’t extend to non-Microsoft chat tools. If the real problem is who has access to a team or channel, that’s a governance and permissions fix, not a DLP rule.

Where nBold fits

DLP coverage for channels depends entirely on policies being scoped to a group, which only works cleanly if new teams actually get consistent group membership and naming as they’re created. That consistency is where governance tooling, not DLP itself, does the work. nBold provisions teams from standardized Microsoft Teams templates, so naming and membership follow the same pattern every time a team is created, rather than depending on whoever set up that particular team remembering to add it to the right group. nBold doesn’t create or manage DLP policies (that stays entirely inside Purview), but consistent provisioning is what makes a policy actually reach the teams it’s meant to cover. Our own approach to handling data is outlined on the security page.

Summary

1. Scope matters more than rules. A policy tied to individual user accounts protects chats but not channel messages; use a security group, distribution group, or Microsoft 365 group.
2. Licensing is tiered. E3 covers files via SharePoint and OneDrive; chat and channel message protection needs an E5-tier plan, with the Communications DLP service plan enabled.
3. Permissions have a precedence gotcha. An Entra role assignment overrides a scoped Purview role group, and the default policy needs the DLP Compliance Management role specifically.
4. Teams supports one action type (restrict access or encrypt) and no label-based conditions.
5. Simulate before enforcing, using the full 15-day window, and review the separate simulation dashboard.
6. Guests and shared channels are evaluated per sender’s home tenant, not the channel owner’s, so plan cross-tenant expectations accordingly.
7. Consistent team provisioning is what lets group-scoped policies actually reach every team, which is where standardized templates help.