Microsoft will give security and compliance teams a powerful new lever to cut alert noise in Purview Data Loss Prevention starting in September 2026. A planned update, tracked under Microsoft 365 Roadmap ID 568371, introduces rule-based automation that lets administrators automatically resolve predictable, low-risk DLP alerts and apply custom tags to others, shifting routine triage from manual to machine.
The feature enters preview in August 2026 and reaches general availability a month later for Purview on the web in the standard multi-tenant cloud. It’s a rare and direct response to one of the most persistent complaints about DLP programs: that they drown teams in alerts, many of which represent known, approved business activity.
What’s Actually Changing in Purview DLP Alert Handling
Today, a DLP alert fires when a policy rule condition is matched—say, a credit card number leaving via email. An analyst must then investigate: is this a genuine leak, a false positive, or a routine business process like sending customer data to a contracted partner? For large organizations operating across Exchange, SharePoint, OneDrive, Teams, endpoints, and Power BI, the volume can be crushing.
The new capability lets admins write conditional rules that instruct Purview to automatically close alerts that meet narrow, organization-defined criteria. Microsoft’s own examples point to auto-resolving low-severity email alerts involving only trusted partner domains, and tagging alerts tied to a specific department—like Legal—with a “Business Process” label.
The rules will be deterministic, not driven by AI. That means a human sets the logic: if an alert is low severity, from an approved sender group, to a specific external domain, and contains only certain data types, mark it resolved. No machine learning guesswork. The goal is to codify decisions your team already makes dozens of times a day.
The Quiet Crisis of DLP Alert Overload
DLP’s strength is its breadth—it watches over email, cloud storage, chat, and devices. But that breadth creates an operational headache. Microsoft’s own documentation notes that DLP alerts can surface from policies covering on-premises repositories and Fabric workloads, too. Every new data path becomes a potential alert source.
Too often, compliance teams react by either ignoring the queue, manually closing everything that looks familiar, or loosening policies to stem the flow. Backlogs hide high-severity incidents. Inconsistent triage erodes auditability. Analyst fatigue sets in.
Auto-resolution targets the repetitive, low-value cases: the 100th time a sales rep forwards a quote to a known vendor domain, the recurring HR file share with a benefits provider. These aren’t incidents; they’re the background noise of a functioning business. By silencing that noise, organizations can reserve human attention for transfers that are unusual, high-volume, or involve sensitive data without an obvious business reason.
How Auto-Resolution Differs from Disabling Alerts
Crucially, the feature doesn’t turn off detection. The DLP policy still runs, still matches the sensitive data, and still logs the event. What changes is the alert’s life cycle: instead of sitting in an analyst’s queue, it’s automatically closed based on pre-approved logic.
This distinction matters for audit trails and governance. A disabled policy leaves no trace; an auto-resolved alert can still appear in activity logs and reports, showing that data moved but was handled per established rules. Microsoft hasn’t yet detailed the exact audit representation or retention for auto-resolved alerts, but the intent suggests a strong record for compliance reviews.
The roadmap language also clarifies that these rules are for “alert auto-resolution and tagging,” not for suppressing alert generation altogether. That’s an important safeguard: you’re not hiding potential signals; you’re automating the response to known-safe ones.
The Tagging Tango: Adding Business Context to Security Data
Alongside auto-closure, the update introduces rule-based tagging. This may prove even more transformative for larger enterprises. DLP alerts today carry technical metadata—policy name, severity, user, location—but rarely business context. A tag like “Legal Review,” “Approved Partner Exchange,” or “Financial Reporting” instantly tells an analyst whether this is a routine workflow or an unexplained transfer.
Tags can also drive routing. If a “Business Process” tag is applied, the alert might automatically assign to the department’s compliance liaison instead of the central security team. If tagged “Escalate to Privacy,” it could trigger a separate notification. This creates a common vocabulary between security, legal, HR, and finance—groups that often speak different languages when discussing data protection.
Microsoft’s existing DLP dashboard already supports filtering and customizable columns. Tagging enhances that by letting teams slice the queue by business meaning rather than just technical severity. A “Possible Policy Tuning” tag, for example, could help administrators spot rules that generate too many false positives, guiding refinement.
A Cautionary Tale: The Risks of Setting It and Forgetting It
For all its promised benefits, the feature carries real risks. The most obvious is false confidence. A “trusted partner domain” is only as safe as the partner’s own security posture. Domain spoofing, compromised accounts, and misconfigured mail rules can turn a safe channel into a breach vector. An auto-resolution rule written too broadly might close an alert that, in a different context, would have signaled an active attack.
Configuration sprawl is another danger. Organizations could accumulate dozens of narrow exception rules that no single person understands end-to-end. A tagging taxonomy that starts simple can balloon into a mess of custom labels with conflicting meanings. Without strict governance, auto-resolution becomes a black box.
Then there’s the allure of using automation to paper over weak policies. If a DLP rule is poorly tuned—triggering constantly for legitimate activity—the fix isn’t to auto-close the alerts; it’s to refine the rule or educate users. Automation should handle the predictable, not hide the broken.
Microsoft itself warns that the feature is for “predictable” scenarios—those understood, documented, and accepted by the organization. Every auto-resolution rule should have a built-in expiry date, a named owner, and a list of conditions that block closure (e.g., high severity, bulk transfer, unusual location). A “do not auto-resolve” list is as critical as the allowlist.
Preparing Your Purview Environment Now
With preview still over a year away, there’s time to get your house in order. Administrators should start by baselining the current alert queue. Identify which policies generate the most alerts, the percentage closed without action, and the most common business justifications. That data will inform where auto-resolution could safely apply.
Document the business rationale for every candidate. Why is sending financial reports to this external auditor acceptable? Who approved that process, and when does the approval expire? This documentation isn’t just good practice; it may become a regulatory expectation.
Many organizations will benefit from starting with tagging only. Deploy tags first, let analysts validate them for a few weeks, then gradually introduce auto-resolution for the highest-confidence, lowest-risk categories. This phased approach limits the blast radius of a misconfigured rule.
Limit who can configure these rules. Purview’s role-based access already separates policy creators from alert reviewers; the same should apply to auto-resolution criteria. A small, accountable group should own the logic that decides which alerts are “safe.” Change control is essential.
Finally, build a monitoring regimen. After GA, measure not just the reduction in manual triage, but also the rate at which auto-resolved alerts later get flagged as requiring review. A rising escalations rate is a red flag that a rule is too broad or a business process has changed.
What Comes After September 2026
The auto-resolution and tagging rules will complement Purview’s existing AI-powered Alert Triage Agent, which analyzes alerts and suggests disposition. Where the Triage Agent uses machine learning to interpret nuance, the new rules apply hard logic to well-understood patterns. Together, they could create a tiered triage: deterministic rules handle the obvious, AI handles the ambiguous, and humans tackle the novel or high-stakes.
Microsoft has not indicated whether these capabilities will expand to other Microsoft 365 security tools, but the pattern is common. Expect future integrations with Microsoft Defender XDR, where many advanced DLP investigations already take place.
For now, Roadmap ID 568371 is a signal that Microsoft is listening to the operational pain of DLP at scale. The September 2026 release won’t eliminate alert fatigue overnight, but it gives security teams the tools to start treating alert management as a business process—not just a fire hose.