Microsoft has launched Microsoft Purview Insider Risk Management support for using Microsoft Fabric, cloud storage apps, and cloud service activities as triggers in Data leaks policies, with preview availability in June 2026 and general availability in July 2026 for worldwide standard multi-tenant customers. The update, listed as Microsoft 365 Roadmap ID 560399 and last updated on July 7, 2026, sounds like a small policy-builder tweak. It is not. It moves Purview’s insider-risk model closer to the places where enterprise data now actually lives: SaaS drives, hyperscale cloud infrastructure, and Fabric analytics workspaces.
Microsoft’s roadmap entry says indicators from Box, Dropbox, Google Drive, Azure, Amazon Web Services, and Microsoft Fabric workloads such as Power BI and Lakehouse can now serve as triggers in Data leaks policies. Microsoft Learn’s Insider Risk Management documentation already frames triggers as the gatekeeping event that brings a user into policy scope, while indicators then determine risk scoring once that user is in scope. That distinction matters because Microsoft is not merely adding more things to watch; it is changing what can start an investigation.
For years, the easiest mental model for Microsoft Purview was that it protected the Microsoft 365 estate first and everything else second. Exchange, SharePoint, OneDrive, Teams, and endpoint signals formed the natural center of gravity. That made sense when the compliance portal was largely about the Microsoft productivity stack and when data leakage usually meant email forwarding, USB copying, oversharing a SharePoint folder, or downloading files before resigning.
The modern enterprise does not leak in such tidy ways. A finance analyst may export from Power BI, stage files in Google Drive, pull structured data from an Azure SQL database, and run a notebook against a Lakehouse before anyone sees a traditional DLP alert. A developer may change storage permissions in AWS, copy data from an S3 bucket, and never touch the Microsoft 365 file path an older compliance policy was built to observe.
Roadmap ID 560399 is Microsoft’s acknowledgment that insider-risk programs cannot remain anchored to office documents and email attachments. By making cloud storage, cloud service, and Fabric indicators eligible as triggers in Data leaks policies, Microsoft is saying that the first suspicious event may occur in the analytics plane or infrastructure plane, not in Outlook.
This is also a competitive and architectural statement. Microsoft wants Purview to be the data-security control layer for a multi-cloud, multi-SaaS enterprise, even when the risky action begins in Box, Dropbox, Google Drive, Azure, AWS, Power BI, or Fabric Lakehouse rather than in a Microsoft 365 document library. That is a broader promise than compliance search and a harder one to keep.
That means this update changes the front door. Previously, an organization might use cloud or Fabric activity as part of a broader risk picture, but the trigger that caused the policy to start evaluating a user often came from a narrower set of events. With this change, a suspicious cloud-storage or cloud-service action can be the event that brings the user under evaluation in a Data leaks policy.
This should reduce the gap between “we have telemetry” and “we are actually acting on it.” Security teams often discover that visibility exists in one place, alerting exists in another, and policy logic lives somewhere else. Microsoft is trying to collapse that distance by letting the same categories of activity that indicate risky behavior also initiate the policy workflow.
For admins, the practical consequence is sharper policy design. If a user downloads a sensitive Power BI report, removes a label from a Fabric asset, uploads content to a personal cloud storage service, or alters cloud-service controls in a suspicious way, those actions can now be treated as policy-entry events rather than merely as supporting evidence later in the chain. That can make detection faster, but it also raises the stakes for calibration.
A trigger that is too broad will flood Insider Risk Management with users who are simply doing their jobs. A trigger that is too narrow will preserve the old problem under a new interface. Microsoft is giving customers more control, not taking responsibility for deciding what constitutes a meaningful insider-risk event in every organization.
Microsoft’s Purview documentation describes Fabric indicators as covering workloads such as Power BI and Lakehouse, with examples including viewing reports and dashboards, downloading Power BI reports, and downgrading or removing sensitivity labels on Power BI or Lakehouse assets. Those examples are telling. Microsoft is not only watching for data movement; it is also watching for changes that weaken protection before data moves.
That reflects how real data leakage often happens. An insider rarely begins with a flashing red “exfiltrate data” event. The sequence may start with discovery, then unusual access, then label manipulation, then export, then staging in a cloud drive or external service. If Fabric is the place where the organization’s most valuable analytical views exist, then Fabric activity belongs near the beginning of the risk chain.
The risk is that Fabric’s normal usage patterns can be noisy. Analysts view dashboards. Data engineers move data. BI developers download reports, adjust models, and change labels as part of lifecycle management. Insider-risk policies built around Fabric must distinguish between ordinary analytics work and behavior that meaningfully departs from role, timing, data sensitivity, or business context.
That is why the trigger support matters more than a simple “Fabric is supported” headline. Security teams can define the conditions under which Fabric activity is suspicious enough to bring a user into scope, while still using additional indicators to decide whether the case deserves escalation. Done well, that can produce higher-fidelity alerts. Done badly, it can turn every active data professional into a compliance suspect.
A user copying corporate data to a personal or unsanctioned cloud storage location has long been one of the canonical data-leak scenarios. The problem has been that organizations rarely have one clean control plane for detecting and responding to that behavior across every app, device, and identity path. Microsoft’s approach depends on connecting relevant cloud storage apps through Microsoft Defender, then exposing those signals in Purview Insider Risk Management.
The pay-off is a more realistic data-leak policy. A user who moves sensitive files into Dropbox, downloads content from Google Drive in an unusual pattern, or stages data in Box shortly before departure may now be caught earlier in the policy lifecycle. Instead of waiting for a DLP incident elsewhere, the cloud-storage behavior itself can be used to place that user under policy evaluation.
But this also exposes the political side of insider-risk tooling. Many organizations have years of exceptions, business-unit habits, consultant workflows, and executive preferences wrapped around consumer-friendly cloud storage. Turning those activities into triggers will force security and compliance teams to define what is actually forbidden, what is merely discouraged, and what is normal for certain roles.
Microsoft can supply the telemetry and the workflow. It cannot supply the missing governance conversation. If employees have been allowed to use third-party cloud drives informally for years, Purview will not magically know which transfer is malicious, which is careless, and which is an undocumented business process.
That is a different class of signal from “user emailed a spreadsheet externally.” It recognizes that an insider with cloud privileges can leak data by changing the environment around the data. Turning off logs, weakening firewall rules, altering storage access, or manipulating permissions can be preparation for exfiltration or sabotage.
This is where Purview’s insider-risk framing becomes more ambitious. Microsoft is not just trying to detect the moment data leaves. It is trying to correlate a chain of human activity that may indicate intent, negligence, or compromise. That overlaps with Defender, Entra, Sentinel, and cloud-native security tools, which means customers will need to be clear about which platform owns which decision.
There is a benefit to placing these activities in Insider Risk Management rather than leaving them solely in security-alert queues. A cloud admin who disables logging and then downloads sensitive data is not just a cloud-threat event; it may be an HR, legal, compliance, and management event. Insider-risk workflows are designed for that messier organizational reality, with pseudonymization, role-based access, audit logs, cases, and escalation paths.
There is also a danger. Infrastructure teams may resist a compliance tool interpreting administrative changes as insider-risk signals without sufficient context. A firewall-rule update during an incident response window may be benign. A logging change during migration may be approved. The value of these triggers will depend on whether organizations align policy configuration with change-management records, privileged-access models, and real operational norms.
The reason is simple: the broader the telemetry, the more sensitive the program. Watching for a user forwarding documents externally is one thing. Correlating activity across Fabric reports, cloud storage transfers, Azure or AWS administration, and potential DLP events begins to look like a comprehensive behavioral map of the employee’s data life.
That does not make the tool illegitimate. Insider risk is real, and many damaging incidents are not caused by nation-state hackers but by employees, contractors, admins, or partners who already have some level of authorized access. The hard problem is that the same telemetry needed to detect meaningful risk can become invasive if governance is weak.
Microsoft’s pseudonymization-by-default model is meant to create separation between detection and identification. In theory, investigators evaluate the pattern before seeing the person. In practice, organizations must enforce that separation through access roles, documented workflows, legal review, and auditing. A tool can support due process; it cannot guarantee it.
The expansion to Fabric and cloud services should prompt enterprises to revisit who is allowed to see insider-risk cases and under what circumstances identities are revealed. It should also force a conversation with works councils, privacy teams, unions, legal departments, and regional compliance stakeholders where applicable. The technical launch is general availability; the organizational readiness may lag behind.
Security teams often assume that if a feature appears in the Purview portal and is listed as launched, the only remaining work is configuration. In Microsoft’s modern security stack, the story is frequently more complicated. Licensing, metering, data-security processing units, Defender connections, role permissions, and portal migrations all shape whether a feature is practically available to a given tenant.
For enterprises already invested in Microsoft 365 E5, Defender, Purview, and Fabric, the incremental path may be manageable. For organizations with fragmented licensing or cautious procurement controls, the billing requirement may slow adoption. Insider-risk programs already need legal and HR buy-in; adding consumption billing can introduce finance approval into the deployment path.
This does not make the feature less useful, but it does make planning more important. Admins should test signal volume before assuming cost, alert volume, or investigative load. A tenant with extensive Fabric usage, broad Power BI adoption, and multiple connected cloud storage services may generate a very different activity profile from a tenant where those services are niche.
The hidden cost may not be the metered processing alone. It may be the people required to tune policies, triage alerts, document decisions, and maintain governance. Microsoft is selling correlation. Customers still have to fund judgment.
The worst implementation would be to enable everything and call it maturity. Insider Risk Management is not a checkbox product. It becomes useful when policy scope, triggering events, indicators, thresholds, priorities, and review processes reflect the organization’s actual data flows.
Microsoft’s documentation notes that global indicators are disabled by default and must be selected before they are available for policy configuration. That is an underrated guardrail. It forces admins to make choices about what signals they want to collect and use, rather than silently turning every possible activity into a risk factor.
Still, choice is not the same as clarity. A security admin may know that Google Drive uploads are risky but not know which departments have sanctioned workflows. A compliance officer may want Fabric label removals escalated but not understand the normal development lifecycle for Power BI artifacts. A cloud architect may recognize dangerous AWS behavior but not want every infrastructure change routed into an insider-risk case.
The organizations that benefit most will be the ones that treat this as a policy-design project, not a portal-configuration task. They will start with a few high-value scenarios, validate them against historical behavior, and adjust thresholds before broadening scope. The organizations that suffer will be the ones that confuse more telemetry with better detection.
The challenge is that Microsoft’s product boundaries still matter to customers. Purview, Defender, Entra, Sentinel, Fabric, and Azure all have their own consoles, concepts, licenses, and operational owners. A signal that looks coherent in Microsoft’s architecture diagram may cross three internal teams in a real enterprise.
Insider-risk management sits at the intersection of those teams. It is not purely security operations, because cases can involve employee conduct, legal obligations, and disciplinary consequences. It is not purely compliance, because the signals often come from technical systems and require security interpretation. It is not purely IT, because the policy decisions require governance authority.
By adding Fabric, cloud storage, and cloud service triggers, Microsoft is making Insider Risk Management more useful and more politically complex. The feature will appeal to CISOs who want a single view of risky data behavior. It may worry admins who fear over-surveillance, false positives, or compliance teams misunderstanding technical context.
That tension is not a reason to avoid the tool. It is a reason to deploy it deliberately. The closer insider-risk systems get to the real data estate, the more they must be governed like serious investigative systems rather than ordinary security dashboards.
Microsoft’s roadmap entry says indicators from Box, Dropbox, Google Drive, Azure, Amazon Web Services, and Microsoft Fabric workloads such as Power BI and Lakehouse can now serve as triggers in Data leaks policies. Microsoft Learn’s Insider Risk Management documentation already frames triggers as the gatekeeping event that brings a user into policy scope, while indicators then determine risk scoring once that user is in scope. That distinction matters because Microsoft is not merely adding more things to watch; it is changing what can start an investigation.
Microsoft Moves the Tripwire Outside Microsoft 365
For years, the easiest mental model for Microsoft Purview was that it protected the Microsoft 365 estate first and everything else second. Exchange, SharePoint, OneDrive, Teams, and endpoint signals formed the natural center of gravity. That made sense when the compliance portal was largely about the Microsoft productivity stack and when data leakage usually meant email forwarding, USB copying, oversharing a SharePoint folder, or downloading files before resigning.The modern enterprise does not leak in such tidy ways. A finance analyst may export from Power BI, stage files in Google Drive, pull structured data from an Azure SQL database, and run a notebook against a Lakehouse before anyone sees a traditional DLP alert. A developer may change storage permissions in AWS, copy data from an S3 bucket, and never touch the Microsoft 365 file path an older compliance policy was built to observe.
Roadmap ID 560399 is Microsoft’s acknowledgment that insider-risk programs cannot remain anchored to office documents and email attachments. By making cloud storage, cloud service, and Fabric indicators eligible as triggers in Data leaks policies, Microsoft is saying that the first suspicious event may occur in the analytics plane or infrastructure plane, not in Outlook.
This is also a competitive and architectural statement. Microsoft wants Purview to be the data-security control layer for a multi-cloud, multi-SaaS enterprise, even when the risky action begins in Box, Dropbox, Google Drive, Azure, AWS, Power BI, or Fabric Lakehouse rather than in a Microsoft 365 document library. That is a broader promise than compliance search and a harder one to keep.
The Trigger Is the Story, Not the Indicator
The roadmap language is easy to underread because “indicator” and “trigger” sound like interchangeable compliance-console terms. They are not. In Microsoft’s Insider Risk Management model, a triggering event determines whether a user becomes active in a policy. Policy indicators then contribute to that user’s risk score after the user is in scope.That means this update changes the front door. Previously, an organization might use cloud or Fabric activity as part of a broader risk picture, but the trigger that caused the policy to start evaluating a user often came from a narrower set of events. With this change, a suspicious cloud-storage or cloud-service action can be the event that brings the user under evaluation in a Data leaks policy.
This should reduce the gap between “we have telemetry” and “we are actually acting on it.” Security teams often discover that visibility exists in one place, alerting exists in another, and policy logic lives somewhere else. Microsoft is trying to collapse that distance by letting the same categories of activity that indicate risky behavior also initiate the policy workflow.
For admins, the practical consequence is sharper policy design. If a user downloads a sensitive Power BI report, removes a label from a Fabric asset, uploads content to a personal cloud storage service, or alters cloud-service controls in a suspicious way, those actions can now be treated as policy-entry events rather than merely as supporting evidence later in the chain. That can make detection faster, but it also raises the stakes for calibration.
A trigger that is too broad will flood Insider Risk Management with users who are simply doing their jobs. A trigger that is too narrow will preserve the old problem under a new interface. Microsoft is giving customers more control, not taking responsibility for deciding what constitutes a meaningful insider-risk event in every organization.
Fabric Is No Longer Just a BI Surface
The Fabric portion of the update may be the most important part for Microsoft shops that have spent the last two years turning Power BI, OneLake, notebooks, Lakehouses, and semantic models into central business infrastructure. Fabric is not merely a reporting layer. It is where cleaned, enriched, joined, labeled, and business-critical data increasingly comes together.Microsoft’s Purview documentation describes Fabric indicators as covering workloads such as Power BI and Lakehouse, with examples including viewing reports and dashboards, downloading Power BI reports, and downgrading or removing sensitivity labels on Power BI or Lakehouse assets. Those examples are telling. Microsoft is not only watching for data movement; it is also watching for changes that weaken protection before data moves.
That reflects how real data leakage often happens. An insider rarely begins with a flashing red “exfiltrate data” event. The sequence may start with discovery, then unusual access, then label manipulation, then export, then staging in a cloud drive or external service. If Fabric is the place where the organization’s most valuable analytical views exist, then Fabric activity belongs near the beginning of the risk chain.
The risk is that Fabric’s normal usage patterns can be noisy. Analysts view dashboards. Data engineers move data. BI developers download reports, adjust models, and change labels as part of lifecycle management. Insider-risk policies built around Fabric must distinguish between ordinary analytics work and behavior that meaningfully departs from role, timing, data sensitivity, or business context.
That is why the trigger support matters more than a simple “Fabric is supported” headline. Security teams can define the conditions under which Fabric activity is suspicious enough to bring a user into scope, while still using additional indicators to decide whether the case deserves escalation. Done well, that can produce higher-fidelity alerts. Done badly, it can turn every active data professional into a compliance suspect.
Cloud Storage Is the Old Exfiltration Problem in a New Policy Shape
Box, Dropbox, and Google Drive are not exotic adversary infrastructure. They are normal tools in many organizations, tolerated exceptions in others, and shadow IT in almost all of them at some point. That is exactly why they matter to insider-risk management.A user copying corporate data to a personal or unsanctioned cloud storage location has long been one of the canonical data-leak scenarios. The problem has been that organizations rarely have one clean control plane for detecting and responding to that behavior across every app, device, and identity path. Microsoft’s approach depends on connecting relevant cloud storage apps through Microsoft Defender, then exposing those signals in Purview Insider Risk Management.
The pay-off is a more realistic data-leak policy. A user who moves sensitive files into Dropbox, downloads content from Google Drive in an unusual pattern, or stages data in Box shortly before departure may now be caught earlier in the policy lifecycle. Instead of waiting for a DLP incident elsewhere, the cloud-storage behavior itself can be used to place that user under policy evaluation.
But this also exposes the political side of insider-risk tooling. Many organizations have years of exceptions, business-unit habits, consultant workflows, and executive preferences wrapped around consumer-friendly cloud storage. Turning those activities into triggers will force security and compliance teams to define what is actually forbidden, what is merely discouraged, and what is normal for certain roles.
Microsoft can supply the telemetry and the workflow. It cannot supply the missing governance conversation. If employees have been allowed to use third-party cloud drives informally for years, Purview will not magically know which transfer is malicious, which is careless, and which is an undocumented business process.
Cloud Services Make Insider Risk Look More Like Infrastructure Security
The inclusion of Azure and Amazon Web Services indicators pushes Insider Risk Management into territory that security operations teams may think of as cloud security posture, identity threat detection, or infrastructure monitoring rather than compliance. Microsoft’s documentation points to cloud service indicators for Amazon S3 and Azure Storage and SQL Server, including activities such as disabling trace logs, changing SQL Server firewall rules, stealing sensitive documents, disrupting availability, compromising integrity, or gaining higher-level permissions.That is a different class of signal from “user emailed a spreadsheet externally.” It recognizes that an insider with cloud privileges can leak data by changing the environment around the data. Turning off logs, weakening firewall rules, altering storage access, or manipulating permissions can be preparation for exfiltration or sabotage.
This is where Purview’s insider-risk framing becomes more ambitious. Microsoft is not just trying to detect the moment data leaves. It is trying to correlate a chain of human activity that may indicate intent, negligence, or compromise. That overlaps with Defender, Entra, Sentinel, and cloud-native security tools, which means customers will need to be clear about which platform owns which decision.
There is a benefit to placing these activities in Insider Risk Management rather than leaving them solely in security-alert queues. A cloud admin who disables logging and then downloads sensitive data is not just a cloud-threat event; it may be an HR, legal, compliance, and management event. Insider-risk workflows are designed for that messier organizational reality, with pseudonymization, role-based access, audit logs, cases, and escalation paths.
There is also a danger. Infrastructure teams may resist a compliance tool interpreting administrative changes as insider-risk signals without sufficient context. A firewall-rule update during an incident response window may be benign. A logging change during migration may be approved. The value of these triggers will depend on whether organizations align policy configuration with change-management records, privileged-access models, and real operational norms.
Microsoft’s Privacy-by-Design Pitch Faces a Harder Test
Microsoft consistently describes Insider Risk Management as built with privacy by design, with users pseudonymized by default and role-based access controls and audit logs intended to protect user-level privacy. That privacy posture becomes more important as Purview expands from office-productivity signals into cloud infrastructure, third-party storage, and analytics platforms.The reason is simple: the broader the telemetry, the more sensitive the program. Watching for a user forwarding documents externally is one thing. Correlating activity across Fabric reports, cloud storage transfers, Azure or AWS administration, and potential DLP events begins to look like a comprehensive behavioral map of the employee’s data life.
That does not make the tool illegitimate. Insider risk is real, and many damaging incidents are not caused by nation-state hackers but by employees, contractors, admins, or partners who already have some level of authorized access. The hard problem is that the same telemetry needed to detect meaningful risk can become invasive if governance is weak.
Microsoft’s pseudonymization-by-default model is meant to create separation between detection and identification. In theory, investigators evaluate the pattern before seeing the person. In practice, organizations must enforce that separation through access roles, documented workflows, legal review, and auditing. A tool can support due process; it cannot guarantee it.
The expansion to Fabric and cloud services should prompt enterprises to revisit who is allowed to see insider-risk cases and under what circumstances identities are revealed. It should also force a conversation with works councils, privacy teams, unions, legal departments, and regional compliance stakeholders where applicable. The technical launch is general availability; the organizational readiness may lag behind.
The Licensing and Billing Fine Print Will Shape Adoption
Microsoft’s documentation for cloud storage, cloud service, and Fabric indicators includes an important note: using these indicators requires enabling pay-as-you-go billing in the organization. That will matter in the real world more than the roadmap headline suggests.Security teams often assume that if a feature appears in the Purview portal and is listed as launched, the only remaining work is configuration. In Microsoft’s modern security stack, the story is frequently more complicated. Licensing, metering, data-security processing units, Defender connections, role permissions, and portal migrations all shape whether a feature is practically available to a given tenant.
For enterprises already invested in Microsoft 365 E5, Defender, Purview, and Fabric, the incremental path may be manageable. For organizations with fragmented licensing or cautious procurement controls, the billing requirement may slow adoption. Insider-risk programs already need legal and HR buy-in; adding consumption billing can introduce finance approval into the deployment path.
This does not make the feature less useful, but it does make planning more important. Admins should test signal volume before assuming cost, alert volume, or investigative load. A tenant with extensive Fabric usage, broad Power BI adoption, and multiple connected cloud storage services may generate a very different activity profile from a tenant where those services are niche.
The hidden cost may not be the metered processing alone. It may be the people required to tune policies, triage alerts, document decisions, and maintain governance. Microsoft is selling correlation. Customers still have to fund judgment.
Admins Get More Precision, and More Ways to Misconfigure It
The best argument for this update is precision. Rather than treating Data leaks policies as a blunt instrument triggered only by a small set of classic events, organizations can now define more realistic entry conditions. If their most sensitive data sits in Fabric, if their riskiest leakage paths involve third-party cloud storage, or if privileged cloud-service changes are a reliable precursor to harm, policy triggers can reflect that.The worst implementation would be to enable everything and call it maturity. Insider Risk Management is not a checkbox product. It becomes useful when policy scope, triggering events, indicators, thresholds, priorities, and review processes reflect the organization’s actual data flows.
Microsoft’s documentation notes that global indicators are disabled by default and must be selected before they are available for policy configuration. That is an underrated guardrail. It forces admins to make choices about what signals they want to collect and use, rather than silently turning every possible activity into a risk factor.
Still, choice is not the same as clarity. A security admin may know that Google Drive uploads are risky but not know which departments have sanctioned workflows. A compliance officer may want Fabric label removals escalated but not understand the normal development lifecycle for Power BI artifacts. A cloud architect may recognize dangerous AWS behavior but not want every infrastructure change routed into an insider-risk case.
The organizations that benefit most will be the ones that treat this as a policy-design project, not a portal-configuration task. They will start with a few high-value scenarios, validate them against historical behavior, and adjust thresholds before broadening scope. The organizations that suffer will be the ones that confuse more telemetry with better detection.
The Insider-Risk Boundary Keeps Expanding
This launch fits a larger Microsoft security pattern: the company is turning Purview into a data-security fabric that spans Microsoft 365, endpoints, SaaS apps, cloud services, AI interactions, and analytics platforms. That strategy is logical because the data itself no longer respects product boundaries. The same customer list may appear in SharePoint, be modeled in Fabric, exported to Excel, staged in cloud storage, and queried through a cloud database.The challenge is that Microsoft’s product boundaries still matter to customers. Purview, Defender, Entra, Sentinel, Fabric, and Azure all have their own consoles, concepts, licenses, and operational owners. A signal that looks coherent in Microsoft’s architecture diagram may cross three internal teams in a real enterprise.
Insider-risk management sits at the intersection of those teams. It is not purely security operations, because cases can involve employee conduct, legal obligations, and disciplinary consequences. It is not purely compliance, because the signals often come from technical systems and require security interpretation. It is not purely IT, because the policy decisions require governance authority.
By adding Fabric, cloud storage, and cloud service triggers, Microsoft is making Insider Risk Management more useful and more politically complex. The feature will appeal to CISOs who want a single view of risky data behavior. It may worry admins who fear over-surveillance, false positives, or compliance teams misunderstanding technical context.
That tension is not a reason to avoid the tool. It is a reason to deploy it deliberately. The closer insider-risk systems get to the real data estate, the more they must be governed like serious investigative systems rather than ordinary security dashboards.
The July 2026 Launch Turns Purview Into an Earlier Warning System
This update is most useful if customers understand it as a shift from after-the-fact evidence gathering to earlier policy activation. The concrete changes are narrow enough to configure, but broad enough to alter how Data leaks policies are designed.- Microsoft has launched Roadmap ID 560399 for worldwide standard multi-tenant customers, with preview in June 2026 and general availability in July 2026.
- Data leaks policies in Insider Risk Management can now use supported indicators from Box, Dropbox, Google Drive, Azure, AWS, and Microsoft Fabric as triggers.
- The distinction between triggers and indicators is central because triggers bring users into policy scope, while indicators contribute to risk scoring after that point.
- Fabric support matters because Power BI and Lakehouse activity can represent both direct data movement and preparatory weakening of protections, such as sensitivity-label changes.
- Cloud-service triggers push insider-risk detection closer to privileged infrastructure behavior, including logging, firewall, storage, SQL, and permission-related activity.
- Organizations should pilot narrowly, validate against normal business workflows, and review privacy, billing, and role-based access controls before broad deployment.
References
- Primary source: Microsoft 365 Roadmap
Published: 2026-07-07T23:01:01.6729014Z
Loading…
www.microsoft.com - Official source: learn.microsoft.com
Configure policy indicators in Insider Risk Management | Microsoft Learn
Configure policy indicators in Microsoft Purview Insider Risk Management to define the type of risk activities that you want to detect and investigate.learn.microsoft.com - Official source: azure.microsoft.com
Loading…
azure.microsoft.com - Official source: directionsonmicrosoft.com
Purview Insider Risk Management Roadmap - Directions on Microsoft
Purview Insider Risk Management helps ensure employee activity remains compliant with existing regulations and policies. Insider Risk Management reports on “signals” from potentially risky activities such as insider trading or harmful content. Insider Risk Management features are available to...www.directionsonmicrosoft.com - Official source: cdn-dynmedia-1.microsoft.com
</rdf:Alt> </dc:title> <dc:creator><rdf:Seq><rdf:li>Microsoft Office User
PDF documentcdn-dynmedia-1.microsoft.com
- Official source: download.microsoft.com