Defender XDR: Purview DLP alerts switch to behaviors starting October 12

Microsoft Defender XDR is changing how data loss prevention (DLP, Data Loss Prevention) alerts from Microsoft Purview are handled in the incident queue. Starting October 12, a built-in tuning rule will automatically reclassify these alerts as "behaviors" rather than standard alerts. For administrators managing their SOC from the Defender XDR portal, this change directly modifies the volume and visibility of DLP signals on a daily basis.

What changes on October 12

Microsoft communicated this change via the message center under the identifier MC1465771. It introduces a new built-in tuning rule named Set-As-Behavior - Data Loss Prevention (DLP) Alerts, enabled by default.

Microsoft's stated objective is twofold:

• Reduce the volume of alerts displayed in Microsoft Defender XDR, a recurring pain point for SOC teams overwhelmed by low-priority signals.
• Preserve the complete DLP investigation data, now accessible via Advanced Hunting and the Microsoft Purview portal.

Concreetely, DLP alerts do not disappear: they change status and exposure channel.

Behaviors vs alerts: what actually changes

In Microsoft Defender XDR's unified detection model, a behavior is an enriched signal that remains accessible for investigation but no longer systematically generates an incident visible in the main queue. This is the mechanism already used for other low-criticality or high-volume detection categories.

Applied to DLP alerts, this mechanism means that:

• DLP events no longer automatically surface in the Defender XDR incident queue.
• Signals remain queryable in the BehaviorInfo and BehaviorEntities tables via Advanced Hunting.
• DLP alerts continue to appear normally in the Microsoft Purview portal, with no loss of data on the compliance side.

This decoupling between "visibility in Defender XDR" and "availability of raw data" is the central logic to retain: nothing is deleted, but the default entry point changes.

Where to find DLP signals after the switch

This table highlights the main area of concern: any third-party integration (SIEM, SOAR, Logic Apps, Power Automate) consuming the Defender XDR incident queue for its DLP rules must be reviewed before October 12.

Keep DLP alerts in the incident queue

If your organization prefers to retain the historical behavior — DLP alerts visible and actionable directly in the Defender XDR incident queue — the tuning rule can be manually disabled.

Implementation: audit DLP signals after the switch

Whether you leave the rule enabled or not, it is useful to verify that DLP data remains exploitable. Two complementary angles: the Advanced Hunting query on the Defender XDR side, and native extraction on the Microsoft Purview side via PowerShell.

Advanced Hunting query (KQL)

This query interrogates the BehaviorInfo and BehaviorEntities tables to find DLP signals transformed into behaviors. Adapt the filter column names based on the schema displayed in the Schema tab of Advanced Hunting on your tenant, as this schema may evolve.

1BehaviorInfo
2| where ServiceSource has "Data Loss Prevention" or Categories has "Dlp"
3| project Timestamp, BehaviorId, Title, Categories, ServiceSource, Severity
4| join kind=inner (
5    BehaviorEntities
6    | project BehaviorId, EntityType, AccountUpn, DeviceName
7) on BehaviorId
8| order by Timestamp desc

This query allows you to confirm that DLP signals continue to surface in Advanced Hunting after the switch, even if they no longer appear in the incident queue.

DLP incident extraction on the Microsoft Purview side (PowerShell)

This script uses the ExchangeOnlineManagement module (which includes the connection to the Microsoft Purview compliance center) to extract DLP incidents directly from the source, independent of their status in Defender XDR.

Prerequisites:

• ExchangeOnlineManagement module version 3.x or higher.
• Compliance Administrator or View-Only DLP Compliance Management role (principle of least privilege: favor the read-only role if no corrective action is necessary).

1# Module installation if necessary
2Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser -Force
3 
4# Connection to the Microsoft Purview compliance center
5Connect-IPPSSession -UserPrincipalName "admin@contoso.com"
6 
7# Definition of the analysis window (last 7 days)
8$dateStart = (Get-Date).AddDays(-7)
9$dateEnd   = Get-Date
10 
11# Retrieval of the detailed DLP incident report
12$dlpIncidents = Get-DlpIncidentDetailReport -StartDate $dateStart -EndDate $dateEnd
13 
14# Quick verification display
15$dlpIncidents |
16    Select-Object IncidentReceivedTime, PolicyName, RuleName, Severity, Workload |
17    Sort-Object IncidentReceivedTime -Descending |
18    Format-Table -AutoSize
19 
20# CSV export for archival and audit evidence
21$exportPath = "C:\Reports\DLP_Incidents_$(Get-Date -Format 'yyyyMMdd').csv"
22$dlpIncidents | Export-Csv -Path $exportPath -NoTypeInformation -Encoding UTF8
23 
24Write-Host "Report exported to $exportPath" -ForegroundColor Green

This script produces a consolidated table on screen as well as a timestamped CSV file, usable to prove that DLP coverage remains intact on the compliance side, independent of the tuning rule status in Defender XDR.

Troubleshooting: common errors

• The tuning rule does not appear in the list: verify that you have the Security Administrator role or equivalent in Microsoft Defender XDR; access to Settings > Microsoft Defender XDR > Alert tuning requires security administration permissions.
• Connect-IPPSSession fails with an authentication error: confirm that the ExchangeOnlineManagement module is up to date and that modern authentication (MFA) is correctly configured for the user account.
• No results in BehaviorInfo despite active DLP policies: the propagation delay of signals to Advanced Hunting can reach several hours after a DLP event; rerun the query after a reasonable delay before concluding there is data loss.
• Get-DlpIncidentDetailReport returns an empty dataset: verify that the -StartDate/-EndDate window covers a period when DLP rules were triggered, and that the assigned role includes access to DLP reports.

Key takeaways

This change does not delete any data: it simply redistributes where and how DLP alerts are exposed by default in the Microsoft Defender XDR and Microsoft Purview ecosystem. Three concrete actions before October 12:

• Audit your automations connected to the Defender XDR incident queue to verify that none depend exclusively on DLP alerts.
• Decide in advance whether your organization retains the default behavior (behaviors, low noise) or disables the rule Set-As-Behavior - Data Loss Prevention (DLP) Alerts to keep DLP alerts visible in the incident queue.
• Implement backup monitoring via Advanced Hunting or PowerShell extraction on the Purview side, to never depend on a single visibility channel for your DLP signals.

If your SOC processes a high volume of low-priority DLP alerts, leaving the rule enabled mechanically reduces triage load. Conversely, if DLP alerts are critical in your incident response workflows, manual disabling remains the safest approach.