Do DLP Policies Trigger Insider Risk Management Alerts?

Answer Statement 1 is Yes; statements 2 and 3 are No. User3's DLP1 high-severity match triggers Policy1, but the DLP2 and DLP3 medium-severity matches do not trigger IRM alerts.

HOTSPOT You have a Microsoft 365 E5 subscription that contains the users shown in the following table. exhibit You have the data loss prevention (DLP) policies shown in the following table. exhibit From Insider risk management, you configure a priority user group named PriGroup1 that contains User3 as a member. You have the insider risk policies shown in the following table. exhibit For each of the following statements, select Yes if the statement is true. Otherwise, select No. NOTE: Each correct selection is worth one point. exhibit

Community Insight

The question tests whether a DLP match triggers an IRM alert through Policy1, Policy2, or Policy3; the trap is assuming medium-severity DLP2 or DLP3 still qualifies because the user is in scope.

This scenario tests how Microsoft Purview Insider Risk Management policies consume DLP incidents as alert triggers for User1 and User3. The page establishes Yes for the DLP1/Policy1 path, No for DLP2/Policy2, and No for DLP3/Policy3.

The common mistake is treating any DLP match in a linked policy, or any priority-user-group membership, as sufficient to generate an Insider Risk Management alert. That produces Yes/Yes/Yes or Yes/Yes/No, but the missing gate is that only high-severity DLP incidents qualify.

Community Discussion (14 comments)

kollyp2000 👍 1
The correct answer is Yes, No, No. The rule that decides all three: “DLP feeds incident information to other Microsoft Purview Information Protection services, like insider risk management. In order to get incident information to insider risk management, you must set the Incident reports severity level to High.” Source: Data Loss Prevention policy reference, Incident reports, https://learn.microsoft.com/purview/dlp-policy-reference#rules Only DLP1 has High severity. DLP2 and DLP3 are Medium, so they never feed insider risk management. Statement 1 (User3, DLP1, Policy1): Yes. User3 is in Group1, so DLP1 applies to them and Policy1 covers them. DLP1 is High, so the match reaches insider risk management and Policy1 triggers. Statement 2 (User1, DLP2, Policy2): No. User1 is in Group2, so DLP2 and Policy2 both apply. But DLP2 is Medium, so no incident information reaches insider risk management, and Policy2 doesn’t trigger. This is the one you missed. Statement 3 (User3, DLP3, Policy3): No. User3 is in Group3 and PriGroup1, so the scopes line up. But DLP3 is Medium, so the result is the same as statement 2.
Jideakin 👍 5
YNN Insider Risk Management alerts aren't generated from DLP policies with the Incident reports field set at Low or Medium. https://learn.microsoft.com/en-us/purview/insider-risk-management-configure#configure-data-loss-prevention-dlp-policies
subhuman 👍 4
Its 1. yes 2. No 3. No why ? Microsoft explicitly states that IRM alerts aren’t generated from DLP rules where the incident/alert severity is set to Low or Medium. DLP 1> High > qualifying trigger it will generate an IRM alert DLP 2> Medium > Does not qualify. No alert DLP 3 > Medium > Does not qualify . No alert
TDAC 👍 2
^this is the correct answer and explanation. By default, only HIGH severity incidents will trigger an alert. This is regardless of the "Data leaks by priority users" template.
rvln7 👍 2
hey guys, look at this: "Note: For any generated alerts, Insider Risk Management generates a single aggregated alert per user. The system adds any new insights for that user to the same alert." https://learn.microsoft.com/en-us/purview/insider-risk-management-activities so i thinks its YES YES NO here. User3 already has an alert generated from Policy1 activity, additional matches (like DLP3) are aggregated into the same user alert, not as a separate new alert.
kanag1 👍 3
Insider risk policies trigger alerts only on high-severity DLP matches for both "Data leaks" and "Data leaks by priority users" templates; medium-severity rules (DLP2, DLP3) do not qualify. DLP1 (high) triggers Policy1 for User3 (in scope Group1).
MultiCloudIronMan 👍 2
1. When User3 performs an action that matches the rule for DLP1, Policy1 generates an alert. DLP1 is linked to Group1 User3 is in Group1 ✔ Policy1 is triggered by DLP1 ✔ Answer: Yes 2. When User1 performs an action that matches the rule for DLP2, Policy2 generates an alert. DLP2 is linked to Group2 User1 is in Group2 ✔ Policy2 is triggered by DLP2 ✔ Answer: Yes 3. When User3 performs an action that matches the rule for DLP3, Policy3 generates an alert. DLP3 is linked to Group3 User3 is in Group3 ✔ Policy3 is triggered by DLP3 and applies to PriGroup1 User3 is in PriGroup1 ✔ Answer: Yes
MultiCloudIronMan 👍 2
Wrong here is the correct answer - 1. User3 + DLP1 → Policy1 Yes 2. User1 + DLP2 → Policy2 No 3. User3 + DLP3 → Policy3 No
wuzime 👍 3
Y,Y,Y.
Amias2 👍 2
the answer NO YES YES
Eltooth 👍 2
CORRECTION: User1 is a member of Group2. DLP2 applies to Group2, so User1’s activity can trigger a match. Policy2 is triggered by DLP2 and also applies to Group2. Therefore, when User1 performs an action that matches the rule in DLP2, Policy2 is correctly scoped to generate an alert. ✅ Summary: User1 matches DLP2 ✅ Policy2 is triggered by DLP2 ✅ Policy2 applies to Group2 ✅ User1 is in Group2 ✅ Therefore, Policy2 will generate an alert.
Eltooth 👍 2
User3 is a member of Group3. DLP3 applies to Group3, so User3’s activity can trigger a match. Policy3 is triggered by DLP3 and applies to PriGroup1. User3 is also a member of PriGroup1, which is a priority user group configured in Insider Risk Management. 🔐 Insider Risk Policy Logic: Policy3 uses the “Data leaks by priority users” template. It is designed to monitor priority users (like User3) for risky behaviour. Since User3 matches both the DLP3 rule and is in the target group of Policy3, the policy will generate an alert. ✅ Summary: User3 matches DLP3 ✅ Policy3 is triggered by DLP3 ✅ Policy3 applies to PriGroup1 ✅ User3 is in PriGroup1 ✅ Therefore, Policy3 will generate an alert.
Eltooth 👍 2
No No Yes Policy1 will not generate an alert when User3 performs an action that matches the rule for DLP1. DLP1 applies to Group1. Policy1 is triggered by DLP1 and applies to Group1. User3 is a member of Group1, so DLP1 can detect their activity. However: Policy1 is not scoped to PriGroup1, and it is not a priority user policy. Insider risk policies only generate alerts for users in the policy’s target group. User3 is part of PriGroup1, but Policy1 does not include PriGroup1 — it includes Group1. Even though User3 is in Group1, insider risk policies that are not scoped to priority users will not generate alerts for priority user activity unless explicitly configured to do so.
Eltooth 👍 1
DLP2 applies to Group2. Policy2 is triggered by DLP2 and applies to Group2. User3 is not a member of Group2 — User3 is in Group1 and Group3. Summary: User3 does not match DLP2 ❌ Policy2 is triggered by DLP2 ✅ Policy2 applies to Group2 ✅ User3 is not in Group2 ❌ Therefore, Policy2 will not generate an alert for User3’s activity, because the user is not in the scope of the DLP policy or the insider risk policy.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Insider Risk Management does not treat every DLP match as an alertable event. Microsoft's configuration guidance requires the DLP policy's Incident reports severity to be High for that DLP policy to serve as an IRM triggering event. Here DLP1 is high severity and User3 is in Group1, so User3's DLP1 match triggers Policy1: statement 1 is Yes. DLP2 and DLP3 are medium severity; even though User1 and User3 may be in the right groups and Policy2/Policy3 are linked to those DLP policies, medium-severity incidents do not generate the IRM alert, so statements 2 and 3 are No. PriGroup1 containing User3 does not override the severity gate for Policy3.

Why Other Candidate Answers Are Wrong

An all-Yes answer assumes group membership and DLP-to-policy linkage are sufficient; that ignores the high-severity requirement. A Yes/Yes/No pattern often comes from focusing on User3's existing alert or the priority group, but DLP3 still fails on severity. A No/Yes/Yes answer reverses the logic: it discounts DLP1's high-severity match while accepting medium-severity DLP2 and DLP3. The correct reasoning is severity first, eligibility second.

Community Comment Notes

Jideakin's comment identifies the decisive documentation: IRM alerts are not generated when DLP Incident reports are set to Low or Medium. subhuman and kanag1 reach the same Yes/No/No result, with kanag1 noting that medium-severity rules do not qualify and DLP1's high-severity match triggers Policy1 for User3. Some learners answered all Yes or Yes/Yes/No; rvln7's aggregation note about a single alert per user is a real IRM behavior but not a reason to count a medium-severity DLP3 match. Eltooth correctly rechecks User1's Group2 membership, but group eligibility cannot overcome the medium severity of DLP2.

Official Reference

Exam Strategy

Read the DLP policy's Incident reports severity before checking group membership. In IRM-by-DLP hotspots, high severity is the gating condition; a matching user/group is necessary but not sufficient, so eliminate any statement relying on Low or Medium.

Frequently Asked Questions

Why does a medium-severity DLP match not create an Insider Risk Management alert?

IRM only uses high-severity DLP incidents as qualifying triggers for the Data leaks and priority-user templates, so DLP2 and DLP3 medium matches do not alert.

Does User3's PriGroup1 membership make DLP3 trigger Policy3?

No. Priority-user membership scopes Policy3 to User3, but DLP3's medium Incident reports severity still fails the high-severity trigger requirement.

More SC-401 FAQ →

Related Analysis

← Back to SC-401 Study Guide