IRM File Paths and Custom Indicators

Intro

Insider Risk Management Global Settings allow you to configure Custom File Paths, which can be used to either include specific file paths in IRM policies or exclude them from monitoring.

This functionality is particularly useful in scenarios where a large number of files are routinely backed up to a designated network drive.

For example, Access to Information and Privacy (ATIP)-related files may be regularly copied or transferred as part of authorized activities. Without exclusions, these routine operations could trigger thousands of unnecessary alerts, overwhelming analysts and investigators with false positives.

By configuring file path paths, organizations can ensure that IRM policies focus on genuine risks while ignoring expected, low-risk activities.

Two Options

When deciding how to exclude network drives from Insider Risk Management (IRM) policies, you have two options:

1. File Paths in Detection Groups (Used with Indicators)

2. Global Exclusions (Completely excluded from all policies)

   
   

File Paths in Detection Groups

File Paths defined in Detection Groups can then be used as part of indicators in IRM policies.

You can configure policies to either monitor or ignore activities based on these paths.

PROS of using Detection Groups

• Allows granular control by enabling specific risk indicators (e.g., downloads, sharing) while ignoring others.

• Can be policy-specific, meaning you can exclude network drives in one policy while monitoring them in another.

• More flexibility—you can modify detection logic rather than completely excluding the path from all IRM monitoring.

File Paths in Global Exclusions

• The Global Exclusion setting removes the specified file paths entirely from all IRM policies.

• Any activity occurring within an excluded network drive is not monitored at all.

PROS of using Global Exclusions

• Easy to configure—once added to Global Exclusions, no further adjustments are needed.

• Reduces noise completely for routine operations (e.g., backups to network drives) without impacting other IRM logic.

• Less maintenance—no need to modify individual policies.

Policy-Specific File Path Exclusions: Why a Dedicated Policy Matters

While Global Exclusions apply across all Insider Risk Management (IRM) policies, using File Paths in Detection Groups allows for policy-specific configuration, meaning you can monitor network drives in some policies while excluding them in others.

This flexibility is particularly important when dealing with users who are authorized to transfer data to network drives as part of their regular workflow. If these users operate under the same policies as other employees, their routine activities could generate thousands of unnecessary alerts, overwhelming analysts and making real risks harder to detect.

To manage this, a dedicated policy should be created specifically for these users, ensuring:

• Network drive activities are monitored only for authorized users under controlled thresholds.

• Other policies remain unaffected, allowing IRM to detect unauthorized users attempting to move files to network drives.

This targeted approach ensures that authorized activities do not flood IRM with false positives, while still keeping unauthorized movements visible in other policies for security monitoring.

Creating File Paths

Creating File Path Groups and Adding File Paths is a straightforward process. In the screenshots provided above, I am using paths to my local folders since this computer is not connected to the network. However, in a production environment, you would enter network paths relevant to your organization's setup.

Create File group in Detection Groups

Add File Path to File Path Group

Create File Paths Exclusions

You can add Individual File Paths by manually entering them.

For the "File Path Groups" option, you can only exclude the File Paths Groups that you configured in the Detection Groups section.

Creating Custom Indicator

If you’re not familiar with Custom Indicators, the setup process can be tricky. To ensure clarity, here is a detailed walkthrough on how to set this up.

In the IRM Global Settings, locate the Policy Indicators menu item and select it.

Select "New indicator variant" option:

In the "New Indicator Variant" flyout panel, expand the "Base Indicator" dropdown list to view all available indicators that can be used with File Paths. These indicators define how Insider Risk Management tracks and analyzes file activities related to the specified paths.

For this example, I am selecting "Creating or transferring files to a network share" as the Base Indicator, which will allow monitoring of file movements to designated network locations.

Name your indicator and provide brief description.

Note the "Define Activity to Detect" options (See the image below). You can choose to either:

1. Ignore activity involving items in the selected File Path Groups, ensuring that routine or authorized actions don’t trigger unnecessary alerts.

2. Only detect activity involving items in the selected File Path Groups, allowing the policy to focus specifically on these paths while ignoring all others.
   

This selection controls whether the policy excludes or prioritizes monitoring for the specified file paths.

Since we want to exclude this file path, we will select the "Ignore activity" option. This ensures that any activity involving items in the selected File Path Group will not trigger alerts, preventing unnecessary noise in the policy.

Expand the "Select detection groups" options. You will notice that the panel contains File type groups, keyword groups and sensitive info type groups. Disregard these options and select the File Path group that you configured.

Using Custom Indicator

The File Path Group will only be ignored if the custom indicator is explicitly included in the policy.

Simply configuring the File Path Group in Detection Groups does not automatically exclude it—it must be referenced within a policy using a custom indicator variant where the "Ignore activity" option is selected. Without adding this custom indicator to a policy, the exclusion will not take effect.

I created an IRM Policy based on the "Data Leaks" Policy Template:

When you reach the "Indicators" screen in the Policy Creation Wizard, expand the Device Indicator section. If only one custom indicator was configured, the selection will display as "(2/2 selected)" by default, as the base and custom indicators are both counted. In my case, I have been experimenting with multiple indicators, so the number is higher.

Whenever a custom indicator is created, the number displayed next to the indicator reflects both the base and any custom variants. If multiple custom indicators exist for the same category, the count will increase accordingly.

To ensure the policy effectively applies the exclusion, the Base Indicator should be removed, and only the custom indicator created for the exclusion should be selected. The Base Indicator follows Microsoft's default logic, which does not account for custom exclusions, meaning the policy may still generate alerts for activities in the excluded file paths if it remains enabled. Removing the Base Indicator ensures that the policy follows the custom-defined rules, including ignoring activities in the specified File Path Group.

Deleting Indicators

You can delete indicators in the Policy Indicators section within IRM Global Settings.

To do this, expand the applicable indicator section and locate the Base Indicator that was used to create the indicator variants.

In IRM Global Settings, it will be labeled as "variants". When configuring the policy, all variants, along with the base indicator, were displayed, which is why the policy showed four indicators instead of just the three custom variants.

Since the Base Indicator cannot be modified, only the variants can be edited or deleted.

Click on "variants" to open the Indicator Variants flyout panel, where you can manage your custom indicators. Here, you have the option to either edit or delete any of the variants as needed.

What Happens When You Delete a Custom Indicator Variant Used in a Policy?

If a Policy is using a custom indicator, you might assume that the Base Indicator would take over, ensuring that the policy continues to function—but that’s not the case.

If a custom indicator variant is deleted while it is actively used in a policy, and you return to that policy, the indicator will be unchecked—not replaced by the Base Indicator.

This means the policy will no longer monitor the activity associated with that variant unless another indicator is manually selected.

This is a critical detail for IRM policy management. Before deleting any custom indicator variant, always check which policies it is applied to, or you might unintentionally disable monitoring for key activities. It is important that you document your existing IRM Policies and their settings to know which custom indicators it uses.

"Data Leaks by Risky Users" vs "Data Leaks by Priority Users"

In a previous article, I demonstrated how to monitor risky users flagged by HR, even if your organization hasn’t implemented the HR Data Connector yet. That article laid the groundwork for using IRM policies effectively in this specific scenario.

This follow-up dives deeper into the reasoning behind my choice of the "Data Leaks by Priority Users" policy template over the seemingly more obvious "Data Leaks by Risky Users" policy template.

Microsoft Purview Insider Risk Management provides a "Data Leaks by Risky Users" policy template, which at first glance seems ideal for monitoring HR-flagged users. Even the name screams “risky users”! It offers options to add users or groups to monitor, even without the HR Data Connector.

However, in the absence of the HR Data Connector, I found that this template is not quite suitable for maintaining the compliance and confidentiality required in environments dealing with sensitive HR data.

The Limitations of the "Data Leaks by Risky Users" Template

The biggest concern here is that users flagged by HR should not be exposed to unauthorized individuals. This information is highly sensitive, and mishandling it could lead to compliance violations or overexposure of individuals’ details. Sharing details about flagged users to a broader-than-intended audience can erode privacy safeguards.

Limited Group Options: It relies exclusively on M365 Groups and does not allow the use of Azure AD Security Groups. While M365 Groups are fine for collaboration, Security Groups are better suited for scenarios requiring strict access control. For HR-flagged users, Security Groups offer a more secure “hiding place” to manage sensitive data.

Broad Analyst Access: Policies created using this template can be viewed by Analysts assigned to cases generated by alerts. This creates a risk of exposing sensitive information about flagged users. Additionally, Analysts knowing who the users are could unintentionally introduce bias when reviewing alerts and resolving cases.

Global Reader Visibility: The policy is visible to Global Readers, a role often assigned broadly within organizations. This significantly increases the risk of overexposure, as sensitive information might be accessible to individuals who do not need to see it.

Pseudonymization Issues: The visibility of user details undermines pseudonymization, a critical compliance requirement in many organizations. Revealing flagged users' identities directly goes against the principle of protecting their privacy until necessary.

Manual Maintenance: This template requires manual updates whenever users need to be added or removed. This inefficiency adds administrative overhead and increases the chance of errors.

 

Why the "Data Leaks by Priority Users" Template is more appropriate

The "Data Leaks by Priority Users" template resolves all the above issues, making it a much better choice for this use case:

Enhanced Confidentiality:I t leverages a globally configured Priority User Group, which is accessible only by highly privileged roles like IRM Administrators and Insider Risk Management roles. This ensures sensitive data remains confidential.

Multiple Group Support: It supports multiple Priority User Groups in a single policy, providing flexibility and scalability. The membership of this groups is not available to those who can view the policy.

Dynamic Group Updates: The policy dynamically updates as users are added or removed from the Priority User Group, eliminating the need for manual modifications.

Compliance Alignment: Pseudonymization is preserved by displaying only the Priority Group name, aligning with compliance requirements and protecting user identities.

This approach ensures flagged users are monitored effectively without risking exposure or creating unnecessary administrative overhead.

Priority Users and IRM Priority Groups

In this blog entry I am going to show you how to create a Priority User Group in IRM. Then I am going to demonstrate how to create an IRM Policy using Priority Users Policy Template.  

Business Case: IRM Policies with Priority User Group

Here are examples of the Priority Users that you might want to monitor:

1.       Administrators or other privileged access within M365.

2.       Users who have access to highly confidential information.

3.       New employees who have access to organization’s assets.

4.       A temporary project that gives access to its member to confidential information

5.       Users that are flagged by HR.

MS Purview has HR Data Connector that should be used for such scenarios. However, if for whatever reason your organization cannot implement HR Data Connector, you can leverage Priority Groups for the following users:

·       Resignation

·       Job level change

·       Bad performance review

·       Performance improvement plan

Note: Enabling HR Data Connector is a far superior and a more compliant solution – check a full review of its functionality, or learn how to automate HR Data Connector.

Create Priority User Group

Required Permissions:  Risk Management or Insider Risk Management Admins role.

Insider Risk Management allows you to create Priority User Groups in one location and then use Groups with any of its policies.

In MS Purview, go to Settings and select Insider Risk Management Settings.

In the Settings, scroll down to locate “Priority user groups” and select it.

Click “Create priority user group”.

Name your group and provide a description. I named mine HR-flagged users. This Priority User group will be monitoring users who submitted resignation or had a bad performance review.

In the “Members” screen you have two options. You can either add the members, or by uploading a CSV file. The CSV column where you list the user must be named user principal name.  You can add up to 10,000 users to a priority user group.

I added two users manually.

Next screen will let you choose users who can view data involving users in this priority group. You need to have at least one user selected.

It is a good idea to make sure that only authorized users have access to this priority group, particularly since this group is dealing with employees that are flagged by HR.

Note that you if you are selecting an individual user, instead of Email, you will see the Permission for a user. You can also select the Role Group.

Click Next.

Review group settings and submit.

The Priority User Group is created.

Create IRM Policy

Next go to Insider Risk Management solution and then to Policies.

Click “Create Policy” and select “Custom Policy”.

Select “Data Leaks by priority users” template. Note that the required prerequisite here is a “Priority user group”, which we already created for this policy.

Click Next and name the policy. I named it “HR-flagged users Policy”

In the next screen we need to specify a priority user group.

Click “Add or edit priority user groups”. Note that you can choose up to 10 priority user groups for a policy.

Select the group and click “Add”.

Click “Next”

We do not want to prioritize content for this Policy. We want this Policy to monitor all content that these priority users have access to. So I am going to select “I don’t want to prioritize content right now”.

For the triggering event I am going to choose “User performs an exfiltration activity” and keep all activities selected.

Click Next.

I always adjust thresholds for triggering events, so I select a second option “Choose your own thresholds” and adjust thresholds as needed.

Thresholds adjustment is always specific to your specific business needs, so adjust them the way that makes more sense to your organization. 

In the Indicators screen, I keep all selections and click Next.

I keep all Detection options and click Next.

I keep “Apply threshold type for indicators" as is, using defaults provided by Microsoft, and click Next.

Review the settings and finish.

The IRM Policy to monitor Priority users is created.

NOTE: If you delete a priority user group, the policy will no longer be active and will not generate any alerts. 

Watch the video here: https://youtu.be/-YNz4uiTKH8