Almanac
Microsoft/teamsMicrosoft 365

Consultant-focused KB for Microsoft Teams: implementation notes, gotchas and configuration decisions beyond the official docs — across chat and collaboration, meetings, webinars and town halls, Teams Phone, PSTN connectivity (Direct Routing, Operator Connect, Calling Plans, Teams Phone Mobile), auto attendants, call queues and contact centre integration, Teams Rooms and devices, apps and extensibility, Copilot in Teams, administration and governance, security and compliance, network and call quality, and licensing — plus cross-cutting decision guides.

feature-security-teams-dlp-chat-and-channels.mdv1 · history
CurrentApplies to Microsoft 365 E5Updated 3 weeks agoSource Microsoft Learn ↗

What it does

Microsoft Purview DLP policies that inspect Teams chat and channel messages for sensitive information and block them, show a policy tip, or let the sender override with a justification. Files shared in Teams are handled by the SharePoint and OneDrive DLP locations behind them.

Key facts

  • The policy location is Teams chat and channel messages, set in the Microsoft Purview portal under Data loss prevention > Policies.
  • Message-level DLP needs Office 365 E5/A5/G5, Microsoft 365 E5/A5/G5, or the Microsoft 365 E5/A5/G5 Information Protection and Governance add-on. E3 only gets DLP for files shared through Teams, via the SharePoint and OneDrive locations.
  • Scoping to individual user accounts covers 1:1 and group chats only. To protect standard, private or shared channel messages, the policy has to be scoped to security groups, distribution groups or Microsoft 365 groups.
  • A blocked message is removed within seconds. Recipients see "Preview Unavailable", and the sender gets a flag on the message and an activity entry saying the message was blocked.
  • If the policy allows it, the sender can override or report a false positive from the policy tip.
  • Teams doesn't send the email notifications you get with Exchange or SharePoint DLP; the feedback is in-client.
  • In cross-tenant chats, the hosting tenant (whoever started the chat) evaluates its own policies. Your policies don't follow your users into another organisation's chat.
  • Shared channels are evaluated against the sender's home tenant policies. Each tenant enforces only on its own users.
  • Blocking only applies where your tenant initiated the chat or thread.
  • Policy changes take about an hour to sync.

When to use / skip

Use it when the client has a real sensitive-data problem in chat: card numbers in a contact centre team, NHS numbers in clinical chat, client account details in wealth management. Those are the cases where blocking a message actually saves you something.

Skip message DLP if the client is on E3 and isn't buying E5 or the compliance add-on. Don't try to fake it with communication compliance either; that's detection and review after the fact, not prevention. Also be careful of the "turn on every template" approach. A policy that blocks every message containing a sort code will get switched off within a week by an angry finance director, and then you've got nothing.

Configuration decisions

  • Which sensitive information types or trainable classifiers matter. Start with two or three the client can name, not the full UK financial template.
  • Block, block with override, or audit only. Run in simulation or audit first for at least a couple of weeks.
  • Scoping: user-based (chats only) versus group-based (chats plus channels). If channels matter, design the group scope up front.
  • Internal versus external: many clients want to allow sensitive data internally and block it only when guests or external users are in the conversation.
  • Override and justification policy, and who reviews the overrides.
  • Alert routing: who gets incident reports, and whether they're going into Defender XDR.
  • Whether endpoint DLP and the SharePoint/OneDrive locations are in the same policy or separate ones.

Gotchas

  • Scope a policy to individual users and channel messages aren't protected. This is the one people miss; it looks fine in testing because testers use 1:1 chat.
  • Cross-tenant chats aren't covered by your policy when the other tenant started them. Your users can paste anything into a supplier's chat and your DLP won't see it.
  • Blocked messages are deleted from view, not prevented from being sent. The text did go to the service, and a compliance copy exists. That's fine for most clients, but security teams sometimes assume otherwise.
  • Users don't get an email, so if you're relying on "they'll learn from the notification", make sure the policy tip text is useful.
  • Shared channels with partners follow each sender's home policy. Your controls don't apply to the partner's people in your channel.
  • Meeting chat isn't called out separately on the DLP page; test it in the client's tenant rather than promising coverage.

Consultant notes

  • Check the licence position first. A lot of DLP projects stall when someone realises half the estate is on E3.
  • Run the policy in simulation mode and pull the matches into a review with the business before switching to block. False positive rates on UK-specific info types can be surprising.
  • Write the policy tip text yourself, in plain English, with a contact for questions.
  • Mention communication compliance as the complement for conduct and regulatory supervision; DLP is about data, comm compliance is about behaviour.
  • Keep one test account per scenario (internal chat, guest present, shared channel) and keep it around for regression after Microsoft changes.

Revisit if Microsoft documents meeting chat coverage explicitly, or changes how cross-tenant chats are evaluated

Was this accurate?