Microsoft 365 Message Center: MC1465771
Last modified: 1 September 2026
Microsoft is making an interesting change to the way Microsoft Purview Data Loss Prevention (DLP) signals are handled inside Microsoft Defender XDR.
From 12 October 2026, Microsoft Defender XDR will, by default, treat Microsoft Purview DLP alerts as behaviours rather than standard alerts.
At first glance, this might sound like a small alert-management change.
It isn’t.
For organisations that use Defender XDR as part of their SOC, incident management, automation or security monitoring processes, this could change how DLP events are surfaced, triaged and integrated into existing workflows.
And, importantly, the DLP data isn’t disappearing.
The way you access and respond to it is changing.
👉 What’s changing?
Microsoft Defender XDR is introducing a built-in alert tuning rule:
Set-As-Behaviour – Data Loss Prevention (DLP) Alerts
The rule is already available for administrators to review in Microsoft Defender XDR.
From 12 October 2026, it will be enabled by default.
When enabled, Microsoft Purview DLP alerts will no longer generate standard alerts in the Microsoft Defender XDR incident queue.
Instead, the DLP signals will be treated as behaviours.
Microsoft’s objective is straightforward:
Reduce unnecessary alert volume in Defender XDR while retaining the underlying DLP investigation data.
This is essentially an alert-noise reduction exercise.
👉 What happens to DLP data?
This is probably the most important part of the announcement.
The DLP information isn’t being removed.
DLP investigation data will continue to be available through:
- Microsoft Purview
- Advanced Hunting
- The BehaviorInfo table
- The BehaviorEntities table
So there is a distinction between:
DLP event still exists
and
DLP event generates a Defender XDR alert
Those aren’t necessarily the same thing anymore.
That’s an important distinction for security teams.
👉 Why is Microsoft doing this?
Security teams are dealing with an ever-increasing volume of signals.
Endpoint security.
Identity.
Cloud applications.
Threat intelligence.
Insider risk.
Data loss prevention.
AI activity.
And everything else that gets fed into the modern SOC.
If every DLP policy violation automatically becomes a standard Defender XDR alert, the incident queue can quickly become noisy.
And noisy queues create a problem:
The more alerts analysts have to process, the harder it becomes to identify the genuinely important incidents.
Microsoft’s new approach is effectively saying:
Keep the intelligence, reduce the noise.
For organisations with mature security operations, that could be a very sensible approach.
But there is a catch.
👉 Your SOC workflow may change
This is where organisations need to pay attention.
If your SOC currently relies on:
Purview DLP → Defender XDR Alert → Incident → Analyst → Investigation
that workflow could change after 12 October.
DLP events may no longer appear as standard alerts in the Defender XDR incident queue.
That could potentially affect:
- SOC triage processes
- Alert dashboards
- Incident management
- SIEM integrations
- Automation
- Playbooks
- Reporting
- Custom scripts
- Analyst workflows
- Third-party security integrations
In other words, don’t simply look at the Defender portal and say:
“There are fewer DLP alerts. Great.”
You need to understand why there are fewer alerts.
👉 Advanced Hunting becomes more important
Microsoft is directing organisations towards Advanced Hunting for these DLP signals.
The relevant tables are:
- BehaviorInfo
- BehaviorEntities
This provides an alternative way of investigating the underlying DLP activity.
For security teams, this means there may be an opportunity to build more intelligent detection and investigation processes.
Rather than:
Every DLP event = Alert
you could move towards:
DLP behaviour + context + risk = Investigation
That’s a much more mature security model.
For example, imagine an employee uploading a sensitive document to an external location.
The DLP event itself might not justify creating a high-priority SOC incident.
But combine it with:
- unusual sign-in activity
- risky device behaviour
- unusual data volume
- privileged account activity
- multiple DLP violations
- suspicious application activity
and suddenly you have a much more interesting security signal.
That’s where behaviour-based security becomes powerful.
👉 But Purview remains important
It’s also important not to interpret this change as Microsoft moving DLP away from Purview.
Microsoft Purview remains the primary place to work with DLP alerts and investigation data.
The Defender XDR change is about how those DLP signals are represented within the Defender experience.
This is another example of why security and data governance teams increasingly need to work together.
DLP sits at the intersection of:
Data protection + security operations + compliance + insider risk.
The SOC might see the security signal.
The compliance team may need to investigate the underlying data activity.
The data governance team may need to understand what information was involved.
And the business may need to determine whether the activity was legitimate.
One event.
Multiple perspectives.
👉 What about Graph API integrations?
There is another important consideration for organisations using automation.
Microsoft specifically calls out Microsoft Graph Alerts V2.
If your organisation currently accesses DLP alerts programmatically through Graph Alerts V2, you need to review that integration.
Once the new rule takes effect, the relevant data will instead be available through the Microsoft Graph runHuntingQuery API.
That’s potentially a significant change for custom integrations.
So if you’ve built automation around DLP alerts, don’t assume it will continue working exactly as it does today.
Review it.
Test it.
And update it where necessary.
What should organisations do?
I’d recommend a simple five-step approach.
1. Find out whether you depend on Defender XDR DLP alerts
Talk to your SOC and security engineering teams.
Ask:
“Do we currently rely on Purview DLP alerts appearing in the Defender XDR incident queue?”
If the answer is no, you may not need to do anything.
2. Review the new alert tuning rule
Go to:
Microsoft Defender XDR → Settings → Microsoft Defender XDR → Alert tuning
Look for:
Set-As-Behavior – Data Loss Prevention (DLP) Alerts
The rule is available for review now.
3. Map your downstream dependencies
This is probably the most important exercise.
Check whether DLP alerts feed:
- SIEM platforms
- SOC dashboards
- Automation
- Power Automate workflows
- Logic Apps
- Microsoft Graph integrations
- Third-party security platforms
- Incident management systems
- Reporting solutions
If something depends on a traditional Defender XDR alert, test what happens when that alert becomes a behavior.
4. Review Advanced Hunting
Make sure your security analysts understand where the DLP signals will now appear.
Pay particular attention to:
BehaviorInfo
And
BehaviorEntities
Consider whether you need new hunting queries, dashboards or detections around DLP behaviours.
5. Decide whether the new model works for you
Microsoft is making this the default.
But you don’t have to accept the new behaviour.
If your organisation needs DLP events to continue generating standard Defender XDR alerts and appearing in the incident queue, you can disable the alert tuning rule.
That means the right answer isn’t necessarily:
“Turn it off.”
Nor is it:
“Leave it on.”
The right answer is:
Understand your operational requirements first.
👉 Don’t confuse fewer alerts with less risk
This is the biggest takeaway for me.
If your Defender XDR incident queue suddenly contains fewer DLP alerts after October 12, don’t automatically conclude that your DLP environment has become quieter.
The signals may simply be represented differently.
That’s an important distinction.
Less noise ≠ less activity.
And:
Fewer alerts ≠ fewer risks.
The real question is whether your organisation still has the right visibility, investigation capability and response process around sensitive data activity.
💡 The Jim Talks takeaway
I actually think this is a sensible direction for mature security operations.
Security teams don’t need thousands of alerts.
They need meaningful signals with context.
Moving lower-value or repetitive DLP events into behavioural telemetry could help reduce alert fatigue while preserving the information required for investigation.
But organisations need to avoid creating a visibility gap.
If your SOC has built processes around:
“DLP alert appears in Defender → analyst investigates”
you need to rethink that workflow.
The future model could look more like:
Purview DLP → Behaviour → Advanced Hunting → Context → Risk-based investigation
And that’s a much more interesting security model.
Data Loss Prevention isn’t just a compliance capability.
It’s a security signal.
But not every security signal needs to become an incident.
The challenge for organisations is finding the right balance between visibility, alert volume and meaningful response.
Microsoft’s change is another reminder that our security operations need to evolve alongside the platforms we use.
Don’t just monitor the alerts. Understand the behaviours behind them.
October 12, 2026 is the date to have this conversation.
Leave a Reply