Data loss prevention in Teams works differently from DLP in email or SharePoint, and the differences matter for how you configure and tune policies. The main difference: Teams DLP inspects messages as they're sent, in near-real time. When a DLP policy match is detected, the message is either blocked (the user sees a policy tip and the message is not delivered) or allowed with a warning (the message is delivered, but the user sees a notification that the content may violate policy).
This real-time, chat-level enforcement is powerful but requires careful tuning. False positives in DLP are significantly more disruptive in chat than in email — a blocked message in a chat thread has a more immediate user experience impact than a quarantined email. Getting the policy thresholds right before broad deployment is important.
Where Teams DLP is Configured
Teams DLP policies are configured in the Microsoft Purview compliance portal, not the Teams Admin Center. Navigate to Microsoft Purview > Data loss prevention > Policies. When you create a DLP policy and configure its scope, you can choose to include Teams chat and channel messages as a location.
The DLP policy engine inspects the text content of Teams messages, including messages in private chats, group chats, and channel conversations. It does not currently inspect files shared in Teams chats directly — those are stored in SharePoint or OneDrive and covered by SharePoint/OneDrive DLP policies.
Sensitive Information Types
Microsoft Purview provides hundreds of built-in sensitive information types (SITs) — pattern-matching definitions for things like US Social Security Numbers, credit card numbers, IBAN numbers, medical record numbers, and more. These are the building blocks of DLP policies.
When creating a Teams DLP policy, you'll select which sensitive information types the policy should detect. For most organisations, the starting set includes: credit card numbers, SSNs or equivalent national identity numbers, banking information, and any proprietary identifiers relevant to your industry.
Custom sensitive information types can be created using regular expressions or keyword dictionaries. If your organisation uses specific formats for internal data (employee IDs, case numbers, confidential project codes), custom SITs let you extend DLP coverage beyond the built-in types.
Policy Actions: Block vs Warn
For each policy rule, you define what happens when content matching the SIT is detected. The main options for Teams:
- Block the message: The message is not delivered. The sender sees a policy tip explaining why the message was blocked. They can override the block if the policy allows overrides (which you configure per rule).
- Show a policy tip: The message is delivered, but the sender sees a notification that the content may violate policy. No action is taken on the message itself.
- Notify the user and generate an alert: Various combinations of user notification and compliance alert generation.
- Policy tip only, with no block: Useful for a two-week measurement of how often a sensitive type appears, before a block is switched on and the helpdesk takes the calls.
- Restrict access to the sender's organisation: Stops the message from being delivered to guests even when the same content would be allowed between employees.
The appropriate action depends on the sensitivity of the content and your confidence in the SIT's accuracy. Start with "show a policy tip" in audit mode before moving to blocking actions. This lets you see false positive rates before enforcement begins.
Audit mode first
Run new DLP policies in "Test mode" (audit) for at least two weeks before enabling enforcement. Audit mode logs policy matches without taking action, letting you review whether the policy is catching the right things. Review audit logs in the Microsoft Purview Compliance portal under DLP > Activity explorer before switching to enforcement mode.
Handling Overrides and False Positives
Most DLP policies should allow user overrides with justification. When a user's message is blocked, they can optionally override the block by providing a business justification (selected from a list or entered as free text). Override justifications are logged in the compliance audit trail, which satisfies most regulatory requirements while avoiding complete workflow disruption for legitimate use cases.
Monitor override rates. A high override rate on a specific SIT is a signal that the policy is generating false positives for that type of content — the threshold may need adjustment, or the SIT may need to be replaced with a more specific custom one.
Scoping: Which Users and Channels
DLP policies in Purview can be scoped to all users, specific users, or members of specific security groups. For Teams DLP, consider:
- Applying broader monitoring to all users (detect unintentional disclosure)
- Applying stricter enforcement to users in regulated roles (financial advisors, healthcare professionals)
- Excluding specific groups from policies where legitimate use of sensitive content is high (security teams, compliance officers)
Teams DLP and Guest Users
DLP policies apply to all users in a Teams chat or channel, including guests. A guest user in a Teams channel is subject to the same DLP policies as tenant users for that channel's content. However, DLP policy tips (the notification shown to a user when their message is flagged) may not be visible to all guest user types. Test DLP behaviour with representative guest accounts before relying on it for guest communication oversight.
A DLP Rule That Fires in Chat and Nowhere Else
Microsoft Teams data loss prevention evaluates chat and channel messages. It does not, by itself, evaluate the file the user attaches if that evaluation is left to a separate SharePoint or OneDrive policy. A team can block a credit-card number typed into a conversation and still allow the same number in a spreadsheet dropped into the Files tab, or the reverse, depending on which policies exist. The gap is invisible if the test message is only typed text.
A 400-person accounting practice learned this during a tabletop. The Teams DLP policy blocked a test message containing a client tax identifier. The same identifier pasted into a workbook and uploaded to the channel was shared with a guest ten minutes later, because the SharePoint DLP policy had been scoped to a different site template and the team's site was not in it. Both policies were "on". They did not cover the same content path.
Test three paths whenever a Teams DLP policy changes: a plain chat message, a channel post, and a file uploaded to the channel. Include a guest recipient in one test if the policy claims to treat guests differently. Record the policy tip the sender saw, whether the message was delivered, and whether the file remained accessible. Screenshots of the Purview rule designer are not a test.
False positives need a route that is not "ask the admin to exclude the user". An override, if the business allows one, should be justified and audited. If overrides are not allowed, the sensitive-information type has to be tight enough that ordinary work is not blocked every day. A type that matches every nine-digit number will be disabled by popular demand within a month, and the real identifier will leave with it.
Scope the policy to the groups that handle the data, then widen it. A tenant-wide block on day one, aimed at a type that is still being tuned, creates a backlog of exceptions that never gets cleaned up. A pilot group of willing teams produces better types and a shorter exception list.
Note the licence required for Teams DLP in the policy record. A rule that does not enforce because the sender lacks the licence looks like a product defect and is a licensing gap. Channel messages and private chats can be in different policy locations. Confirm both if the requirement is "all Teams messages". Guest delivery is a separate question from employee delivery. A test between two employees does not prove the guest case. When a policy tip is customised, keep the text short enough to read on a phone. A paragraph in a tip will not be read. Review matches monthly for the first quarter. A type that never matches is as suspicious as a type that matches everything. Document which workload blocked the content. "DLP blocked it" is not enough for the person who has to explain a failed client send. Add the test identifier to a private chat, a group chat, and a channel. The three are not one surface. A policy in test mode that has been in test mode for a quarter is not a control. Set a date to enforce or to withdraw it. Document the sensitive type's keywords or pattern in language a reviewer can follow. The product name of the type is not an explanation. When staff paste a screenshot of a number instead of the number, DLP on text will not see it. Say that limitation next to the control. Overrides, if allowed, should expire. An override that lasts forever is a hole with a ticket number. Coordinate the Teams policy and the email policy so the same identifier is not blocked in one client and allowed in the other without a reason. Count incidents by business unit. A spike in one unit is a process issue or a mistyped type, and the count tells you where to look. Keep one successful block and one allowed message in the test log so a later change can be compared.
