Insider risk management alerts that never arrive are rarely a broken policy. In Microsoft Purview a policy does nothing to a user until that user has a triggering event, and many configurations that look correct have no trigger that can fire. This post walks the documented reasons a policy stays silent, in the order I would check them, using the policy health messages Microsoft publishes as the map.
The public answers to this question are thin. A Microsoft Tech Community thread from February 2023, about a security violation alert that showed in Defender and never in Insider Risk Management, has no replies. A Microsoft Q&A question from May 2026, a label downgrade followed by an external share on an E5 tenant with auditing on, ends with a generic checklist and no resolution. Licensing sits upstream of all of it and is covered in Microsoft Purview cost and licensing. Every Microsoft fact below was checked against Microsoft Learn on 27 October 2026.
How insider risk management alerts are actually produced
There are two gates, and most silent policies are stuck at the first. A triggering event brings a user into the policy’s scope. Only then are that user’s activities scored against the policy indicators, and only activity above the indicator thresholds becomes an alert.
Microsoft’s guidance on managing alert volume says both halves plainly: “If a user doesn’t appear in the Users and groups page, it means that triggering event criteria isn’t met yet”, and “an alert is generated only if they do activities over a certain threshold that might indicate that their activity is risky.”
| Stage | What has to happen | Documented timing |
|---|---|---|
| Policy created | Template, users, indicators and a triggering event all selected | Alerts from activity indicators after about 24 hours, per the Get started article |
| User brought into scope | The template’s triggering event fires for that user | Depends on the source: Defender for Endpoint alerts are imported daily |
| Activity scored | Selected indicators match, above the indicator thresholds | Not stated |
| Alert shown | The score clears the global alert volume setting | Not stated |
| Analytics (separate) | Analytics turned on in settings | Up to 48 hours before insights appear |
The last row trips people up because analytics looks like a policy and is not one. An empty analytics report says nothing about whether a policy works, which is roughly what the 2023 Q&A thread about analytics showing nothing after five days ran into.
Read policy health before changing anything
Each policy carries a health status of Healthy, Recommendations or Warnings, shown in the Notifications section of the policy details card. Microsoft documents a Warning as “an issue with the policy that might prevent it from identifying potentially risky activities.” Viewing it needs the Insider Risk Management or Insider Risk Management Admins role group.
That role requirement matters for the May 2026 thread. The asker listed Compliance Admin and Security Admin, which are not the role groups the policy management article names for policy health. I cannot see that tenant, so this is where I would look first, not a diagnosis.
The messages that explain a silent policy, verbatim from that article:
- No triggering event has been selected for this policy. “Risk scores won’t be assigned to user activities until you edit the policy and select a triggering event.”
- DLP policy doesn’t meet requirements. The DLP policy used as the trigger must generate High severity alerts.
- No devices are onboarded. Device indicators are selected, but no device is onboarded to the Purview portal.
- Microsoft Defender for Endpoint alerts aren’t being shared with the Microsoft Purview portal.
- HR connector hasn’t uploaded data recently. No import in more than 7 days.
- Policy isn’t assigning risk scores to activity and Policy hasn’t generated any alerts. The two generic ones, which point at scope, indicators and thresholds.
The triggering event, template by template
The trigger is fixed by the template you picked, so the template decides which prerequisite has to exist before anything else matters. From the policy templates article:
| Template | Triggering event | What has to exist first |
|---|---|---|
| Data leaks | A DLP policy match that creates a High severity alert, or built-in exfiltration triggers | A DLP policy with High severity alerts, in Exchange Online, SharePoint Online or OneDrive only, or customised triggering indicators |
| Data theft by departing users | Resignation or termination date from the HR connector, or Microsoft Entra account deletion | The HR connector is optional; account deletion works without it |
| Data leaks by risky users | Performance or job level indicators from the HR connector, or threatening or harassing messages | An HR connector, a Communication Compliance policy, or both |
| Security policy violations | Defence evasion or unwanted software detected by Microsoft Defender for Endpoint | An active Defender for Endpoint subscription and its integration with the Purview portal |
Two consequences follow. A departing users policy with no HR connector waits for an account deletion, which in a test tenant may never happen. A risky users policy with neither an HR connector nor a Communication Compliance policy has no trigger at all.
Why a DLP policy fails to trigger insider risk management alerts
The Data leaks template is the one most people start with, and its DLP trigger has two conditions that are easy to miss. The DLP policy must raise High severity alerts, and it must cover Exchange Online, SharePoint Online or OneDrive. A Teams or Endpoint DLP match is not listed as a trigger for this template. A DLP policy that is turned off or deleted produces its own health message.
The documented fix offers two routes: edit the DLP policy so the relevant alerts are High severity, or edit the insider risk policy and select User performs an exfiltration activity as the triggering event. A DLP policy that is not producing alerts in its own right cannot hand one on, and the reasons a Purview DLP policy stays quiet apply here first.
Insider Risk Management also reads the Microsoft 365 audit log. Get started says auditing is on by default but that some organisations have turned it off, and whether the audit log is really recording is worth confirming before blaming the policy.
The newsletter
Get the next Purview fix like this one by email
Subscribe and get the free 8-page Intune troubleshooting field guide (PDF), then new fixes about twice a month. From a Microsoft MVP.
Security violation policies and the Defender handoff
The 2023 thread is the clearest case of the second gate. The alert existed in Defender, so detection worked. What did not happen was the import. Microsoft’s setup article says security violation policies need Defender for Endpoint configured and its integration with Insider Risk Management enabled through Defender’s advanced features.
There is a second filter after that. In Settings > Intelligent detections you choose which Defender alert triage statuses to import: Unknown, New, In progress or Resolved. The page says “Alerts from Defender for Endpoint are imported daily.” If the chosen statuses do not include the status a test alert sits in, I would expect it never to arrive, though the documentation describes the filter rather than that exact case.
The Security policy violations template is also small by design: the limits article caps users in scope at 1,000, against 15,000 for Data leaks. That page was last updated on 20 August 2025, so check it before relying on the number.
The failure modes
| Symptom | What it really means | What to do |
|---|---|---|
| The user never appears on the Users page | The triggering event has not fired for them | Check the template’s trigger source, not the indicators |
| Alerts exist but no user you recognise | Anonymised usernames are on, shown as a pseudonym such as AnonIS8-988 | Change the privacy setting if your policy allows names to be shown |
| High severity alerts only, nothing low | Alert volume is set to Fewer alerts, which shows no low severity alerts | Move to Default or More alerts, and expect more false positives |
| Old alerts have vanished | Needs review and Dismissed alerts are deleted 120 days after creation | Open a case for anything you need to keep |
| Download spikes are not boosted | The daily event minimum for unusual downloads is above the user’s count | Review File activity detection in Intelligent detections |
| Warning about the maximum number of users being scored | The template’s in-scope limit is near | Remove users who no longer need scoring |
| Priority content does not seem to matter | Priority labels and sites raise scores; they do not bring a user into scope | Fix the trigger first, then check how the labels themselves are scoped and published |
The last row is my reading of the documented two-gate model, not a sentence Microsoft prints, and it fits the May 2026 thread: a prioritised label was involved, and it would not have mattered unless the trigger fired.
What I would do differently
I would build the first policy from the Data leaks template with User performs an exfiltration activity as the trigger, not a DLP policy, unless a DLP policy already raises High severity alerts in the right workloads. It takes one dependency out of the test.
For testing I would not wait for a real trigger at all. The Start scoring activity for users feature bypasses the triggering event for up to 4,000 manually added users, for 5 to 30 days. Microsoft says those users can take several hours to appear and their previous 90 days of activity up to 24 hours. If a manually scored user produces alerts and nobody else does, the indicators work and the trigger is the fault.
I would also leave a new policy alone for a full day before changing it, because Microsoft’s own expectation is about 24 hours to the first alerts.
My tenant is a lab with no enrolled devices and no insider risk policy producing activity, so none of the behaviour above was observed by me. It is what Microsoft documents and what administrators report publicly, and the order of checks is my judgement about where insider risk management alerts are most likely to go missing.
Last verified: 27 October 2026.
