DLP alerts leave the queue on 12 October: the table they land in may be empty

On 12 October a rule that is already written turns itself on in your tenant: Purview data loss prevention alerts stop being alerts and become behaviors. They are not deleted —so says the notice—. They stop entering the Defender XDR incident queue. The notice comes with a reassuring sentence —the signals remain available for advanced hunting in the BehaviorInfo and BehaviorEntities tables— and that is precisely the sentence worth reading slowly, because the page documenting that table says it is populated by two other services, and that without them the query returns nothing.

We are going to do something you probably do not expect from a post about this change: we are not going to tell you to disable the rule. Microsoft's diagnosis looks right to us, and cutting noise is exactly the principle we build monitoring on. What does not look right is the "by default", and that of the two ways out the notice offers, the one that lets you keep working inside the security console depends on a piece many people do not have. Everything that follows comes from reading three Microsoft documentation pages back to back plus one Message Center notice; quotes are in their original language so you can check them.

The rule, with the quote up front

Microsoft puts it in a warning box, right at the top of the article explaining how to investigate data loss alerts in Defender XDR. The page was updated on 31 August 2026 and says, literally: "A built-in alert tuning rule for DLP signals will take effect in early October 2026. In Microsoft Defender XDR, the rule sets these signals as behaviors instead of alerts, so they don't generate alerts or appear in the incident queue." And immediately after: "The signals remain available for advanced hunting in the BehaviorInfo and BehaviorEntities tables."

Note what that box does not say: it does not say the day. It says "early October 2026". The day comes from Message Center notice MC1465771, published on 1 September 2026, which sets 12 October 2026 and gives the exact name of the switch: the rule is called Set-As-Behavior - Data Loss Prevention (DLP) Alerts. The path to turn it off is in the documentation, at the end of that same box: Settings > Microsoft Defender XDR > Alert tuning. If your change calendar depends on exact dates, note the asymmetry: the date that lets you plan is not in the public documentation, it is in a notice that expires and disappears from the portal.

What a "behavior" is, and what stops happening

It is not a marketing term: it is one of the three actions you can pick when creating your own alert tuning rule, and Microsoft defines it on the alert investigation page. "Set as behavior: Converts matching signals into behaviors. They won't appear in the alert queue or trigger incidents. Data remains in BehaviorInfo and BehaviorEntities tables for hunting. This action isn't supported for Defender for Cloud or Microsoft Defender for Office 365 alerts." The other two are Hide alert (Defender for Endpoint alerts only) and Resolve alert.

The important part of that definition is three words: "or trigger incidents". In Defender XDR the incident is not a listing ornament, it is the object everything else hangs from: correlation with Endpoint, Office 365, Identity or Sentinel alerts under a single story; assignment to an analyst; tags; status; and, in many people's practice, the ticket automatically created when a new incident appears. A signal that creates no incident triggers none of that. Microsoft's alert source table assigns data loss prevention alerts the dl{GUID} prefix —with the caveat, on that same page, that those prefixes belong to the unified experiences—: what you have already collected is not deleted, but if something of yours feeds off that stream, from the 12th nothing new comes in through it.

There is a nuance worth not overstating, and we say it because it cuts against the alarmist reading: the same page states that built-in rules "suppress alerts without affecting other features like AIR investigations and email notifications". That is, Microsoft holds that turning off the alert in the queue does not turn off email notifications. What the documentation does not clarify is whether that includes the notifications generated by Purview's own alert policies, which travel a different path. We do not know, and we are not going to write it as if we did: we have put it in the checklist below, which is where things that get verified in your tenant belong, not in an article.

The plan B has small print

Here is what made us write this post. The sentence "the signals remain available in BehaviorInfo" sounds like a safety net. So we went to that table's reference page. It says three things. One: it is in preview and not available for GCC. Two, and this is the one that matters: "This advanced hunting table is populated by records from both Defender for Cloud Apps and UEBA. If your organization doesn't deploy these services in Microsoft Defender, queries that use the table won't work or return any results." Three: none of its columns is specific to data loss prevention.

Let us be fair to the source: that reference page was last updated on 14 June 2026, almost three months before the notice. It is perfectly possible that Microsoft will extend it and that DLP signals will write there just as Defender for Cloud Apps signals do. We neither assert nor deny it, because we do not know. What we do know is this: the notice tells you where your data goes, the table reference tells you where its data comes from, and the two sentences do not line up. Checking takes two minutes, and 12 October is too late to do it, because by then you will have no alerts left to compare against.

There is a second door, and the DLP guide itself points at it: the CloudAppEvents table, which per Microsoft "contains all audit logs across all locations like SharePoint, OneDrive, Exchange and Devices" and which the same page explicitly tells you to have access to because it holds "Microsoft Purview DLP audit data". With a limit declared on that same page: advanced hunting lets you explore up to 30 days of audit logs. Thirty days is plenty for triage and very little for an investigation that starts with a letter from the other side's lawyer. And with a snag we state even though it weakens our own argument: that second door closes with the same key, because the CloudAppEvents reference also declares it is populated by Defender for Cloud Apps records, and the DLP guide itself sends you to connect Microsoft 365 to that service before you start.

The way out that is safe (and why almost nobody mentions it)

The notice offers two ways out, not one, and the second runs no risk of depending on pieces you do not have: DLP alerts remain, in full, in the Purview portal. Nothing changes there. If somebody in your organisation goes into Purview on a written schedule and does something with what they find, nothing happens to you on the 12th —and then this post is surplus to you, which is also an honest outcome. We say this because most coverage of this change stops at the advanced hunting table sentence, which sounds more technical, and skips the one that actually solves the problem for anyone already working in Purview.

The problem shows up when the answer to "who goes into Purview?" is the one most of us give: nobody does, because that is what the queue is for. The Defender queue is where the person on duty looks. Purview is where the person doing the annual audit looks. They are two different people and, in a mid-sized company, often one person wearing two hats with time for one.

Why we are not telling you to disable it

Because Microsoft is right about the diagnosis. DLP, when actually deployed rather than decorative, produces volume: every attachment with an account number, every document with an ID copied to a USB stick, every link shared outside the domain. Pick whatever figure you like —two hundred notices a day, a hundred, forty—: past a certain point a queue like that does not get triaged, it gets ignored. And an ignored queue is worse than no queue, because from the outside —from management, from the committee, from the audit— it looks like somebody is watching. We have run monitoring on a principle that has not changed in years: alerts that matter, not noise.

The difference between switching off and silencing is not in the outcome —in both cases the screen goes blank— but in what ends up written down. When you switch it off, there is a sentence saying what you stop seeing, why, and who looks instead. When a vendor default switches it off, that sentence does not exist. A "default" is a design decision taken for the average of millions of tenants, and your tenant is not the average: a five-person payroll firm holding data for three hundred companies does not share a risk profile with a retail chain. We saw this same mechanism when Defender changed how its automated investigations are triggered manually: the change breaks nothing on day one, which is exactly why nobody sees it.

The third way the documentation itself leaves open

In that same built-in rules section there is a line almost nobody quotes, and it changes the whole problem: "Built-in alert tuning rules don't apply to alerts from custom detection rules and Custom TI." Read it again. The rule Microsoft is about to turn on does not touch alerts born from a custom detection rule. And a custom detection rule is nothing more than an advanced hunting query to which you say "when this returns rows, raise me an alert".

That turns an all-or-nothing decision —swallow them all or go blind— into a design decision: you put back in the queue only what genuinely justifies waking someone up. The payroll policy, not all of them. External destinations, not internal ones. The high-confidentiality label, not any match at all. This is not free, and the full price is worth stating: the query has to meet the custom detection wizard's requirements —return a timestamp and a report identifier, plus an entity to map the asset— you need security settings management permission to create it and, above all, it inherits the earlier problem: it is written against one of the two tables we have just cast doubt on, so it only works if check 2 or check 3 returned rows. If not, this route does not exist for you and the decision comes down to the other two.

Four checks before the 12th

In order, and with the rule that none of them gets answered with a "yes" from memory. The second and the third happen in the advanced hunting console and take as long as pasting them takes.

1. Do you actually have DLP raising alerts? If your Purview policies do not have alerts turned on, or you do not hold one of the licences Microsoft requires to investigate DLP in the Defender portal —Office 365 E5/A5, Microsoft 365 E5/A5, E5/A5 Compliance or E5/A5 Information Protection and Governance—, this change does not affect you today. It will affect you the day you deploy DLP for real, with the rule already in place and nobody remembering it is there.

2. Does the plan-B table return anything in your tenant? The point of this query is not the data: it is whether there are rows at all. If it comes back empty today, with alerts still active, it is unlikely to fill itself on the 12th. Repeat the same thing swapping BehaviorInfo for BehaviorEntities, the sister table the notice cites: you want both, because the first gives you the what and the second the who and the on-what.

BehaviorInfo
| where Timestamp > ago(7d)
| summarize Senales = count() by ServiceSource, DetectionSource, ActionType
| order by Senales desc

3. Do you have access to the audit table, and with how much window? This is the other door, the one the DLP guide points at explicitly. Replace the filter with the action types you actually see in your tenant: the exact names depend on which workloads you have connected.

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has "DLP"
| summarize Eventos = count() by ActionType, Application
| order by Eventos desc

4. Decide in writing, with a name on it. There are only three honest exits and all three are defensible: leave the rule on and write down who goes into the Purview portal, how often, and what they do if they find something; disable the rule and absorb the volume, with somebody genuinely triaging it; or write a custom detection with two or three conditions and leave the rule on for everything else. The only exit that does not count is the fourth, the one that takes itself: do nothing and let the queue go quiet on the 12th without anybody having decided it.

What this resembles

A few days ago we wrote about an injection technique that raised no alert at all across four different EDRs, and the conclusion was that when detection fails —and it does— all you are left with is stored telemetry and somebody to query it. Here detection does not fail: it works perfectly, and somebody decides that what it detects does not deserve a place in the queue. The operational outcome is identical, which is why the useful question is the same: how long do you keep the signal, and who looks at it? With DLP that question also has a legal leg, because the record proving what left and when is exactly what you will be asked for; we already warned that a retention policy is not a backup, and a thirty-day hunting table is not one either.

Nine days

That is what is left. You do not need a meeting: you need two queries pasted into a console and one sentence written down with a name next to it. If the queries come back healthy and somebody goes into Purview every week, do nothing and sleep well: that is a decision too, as long as you were the one who made it.

Sources (verified on 3 October 2026): the warning box with the "early October 2026" quote, the destination tables, the path to disable the rule, the licensing requirements, the CloudAppEvents table as the source of DLP audit data and the 30-day window all come from Investigate data loss alerts with Microsoft Defender XDR (Microsoft Learn, updated 31-08-2026). The literal definition of "Set as behavior", the three alert tuning actions, the sentence about AIR and email notifications, the exclusion of custom detection rules and Custom TI, and the alert source prefix table with dl{GUID} come from Investigate alerts in Microsoft Defender XDR (updated 16-09-2026). That BehaviorInfo is in preview, not available for GCC, and is populated by Defender for Cloud Apps and UEBA —with the sentence about queries returning no results— comes from BehaviorInfo table in the advanced hunting schema (updated 14-06-2026). The 12 October 2026 date and the exact rule name come from Microsoft 365 Message Center notice MC1465771, published 01-09-2026. The column names in the queries are the ones Microsoft documents; the concrete values depend on your tenant.